Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-session-signal-02.txt

From: Petr Špaček <[email-masked]>
Date: Thu, 10 Aug 2017 13:28:29 +0200

Hello Ted and dnsop,

and sorry for delayed answer (below). Your message forced me to think
more about the draft, this time without focus on the wire format.

Spoiler alert: I still do not like the proposal in its current form.
Please see below.

On 21.7.2017 10:22, Ted Lemon wrote:
> I am hearing from a number of people that this is "a new protocol" and
> hence requires careful thought and perhaps a new working group, along
> with the associated delay.   I do not _entirely_ disagree with this
> position, although it would be really inconvenient from my perspective.
> 
> However, I would like to point out that the objection "it is a new
> protocol" is not a technical objection.  Also, the same objection can
> actually much more justly be raised against several other proposals that
> were brought before the working group.   For example, the multiple
> RRtypes proposal, the multiple responses proposal, and the extended
> error codes proposal.
> 
> All of these define new protocol, in ways that are in, like session
> signaling, backward-compatible with the existing protocol.   The other
> proposals are actually much more significant changes than session
> signaling is, in terms of what they actually do, as opposed to what
> their wire format is.

Okay, I can see what you mean - there surely are various levels of
complexity and protocol changes proposed in the last years for dnsop.

However I disagree that adding session signalling to DNS is less
significant change than e.g. multi-query/repose proposals.

As you said, session signalling is a "control plane for DNS", which is a
very new thing. Keeping (IMHO significant) wire format issues aside,
adding a control plane to DNS is in my eyes a significant new
development and should be treated as such.

> And as for a new DNS wire format, which I also think would be a good
> idea, this is pretty clearly /not /what session signaling is.   How
> would you do a DNS query with session signaling?   In what way would it
> be an improvement over the existing query format?   It's possible that a
> new wire format can be built on top of session signaling, but session
> signaling doesn't build a new wire format, and if we choose to do
> session signaling, that doesn't preclude doing a different wire format
> for queries later.

Maybe one of the problems is that the current draft mixes three
things in a single document:
- The new wire format,
- DNS control plane,
- Session signaling functionality over the control plane.
This is probably making things way harder to explain to non-authors than
necessary.

These really are separate things. I can imagine that control plane
and potentially its wire format can be together in one document (but I'm
still not convinced that the a wire format is necessary), but session
signaling functionality itself should be certainly separate from that.

Let's keep discussion about the wire format for later, there is even
more significant issue ahead of us:

> Session signaling is just a control plane for DNS.   It's useful.   I
> would like to see it done sooner rather than later.   If we are not
> going to do it sooner rather than later, I would like the reason to be
> something more than vague unease about walking backwards into a new wire
> format.

The problem is that current proposal is creating some generic "control
DNS plane" as by-product of session signaling functionality, as we were
discussion during dnsop session.
(References: "Totally flexible format" & "Concerned with embedding DNS
messages in TLVs" in [2].)

I believe that we really should not invent such generic mechanisms as
by-products.

If a WG agrees that a generic DNS control plane is needed, then it needs
to be carefuly designed and described, including problem statement and
analysis related to current and potential new transports. These are
compleretely missing now.

Moreover, the dnsop is specifically chartered to subset of possible
changes [1] to the DNS protocol:

4. Publish documents  to address operational issues with the DNS
    protocols by  extending or performing protocol maintenance
    on them.  Act as  focal-point for operator discussion and provide
    advice to the Ops ADs and other WGs on EDNS0 options,  new
    RRTYPEs, DNSSEC,  record synthesis, or other mechanics of
    extending DNS to support other applications.

5. Serve as a home for drafts that document the problem space
   around existing or new DNS issues.  The group, with the advice
   and consent of the responsible AD in coordination with other areas,
   will then decide whether these  issues belong in DNSOP  under
   the existing charter and, if not,  will work with the authors and
   appropriate ADs to determine the proper place for the work to be
   carried out.

For me, adding control plane is just stretching this definition too far.
If session signaling is covered by this charter then we must admit
that dnsop can do anything it wants to the DNS protocol.

[1] http://mailarchive.ietf.org/arch/msg/dnsop/MOFBFQAaZ2iZUDje3zWNBRn9xKQ

[2] https://datatracker.ietf.org/meeting/99/materials/minutes-99-dnsop

Again:
If there is a need for a "DNS control plane" then it should be enginered
as such and not invented as by-product of something else.

Yes, it is a lot of work. And yes, it should start with problem
statement for control plane (in general) and continue from there.

I hope it explains why I still do not like the current proposal.
Thank you for your attention.

Petr Špaček  @  CZ.NIC

> 
> On Fri, Jul 21, 2017 at 10:02 AM, Petr Špaček <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     On 20.7.2017 19:09, Andrew Sullivan wrote:
>     > On Thu, Jul 20, 2017 at 06:59:42PM +0200, Ondřej Surý wrote:
>     >>> But it's certainly another step along the way to DNSbis by accident.
>     >>
>     >> Would it be useful to make it not "by accident"?
>     >
>     > Yes.  That was basically the point I was trying to make at the
>     > beginning of today's session, about overall analysis.
>     >
>     >  > b) make this draft DNS-SD only, so it can fast forward...
>     >>
>     >
>     > I'm not keen on this.
>     >
>     >
>     >> c) use the changed paradigm to work on DNSbis without the accident part?
> 
>     Yes please!
> 
>     My main opposition comes from fact that current session signaling draft
>     "accidentaly" defines new protocol which is using the old DNS-RFC1035 as
>     "transport".
> 
>     I would welcome DNSbis effort with clear cut. Here please note that
>     clear cut does not mean that RR format and data, for example, has to be
>     incompatible!
> 
>     It is still possible to share big chunks of specifications (like RR
>     definitions, namespace, etc.) but define a DNSbis protocol which is
>     clearly distinguishable from the old DNS.
> 
>     Petr Špaček  @  CZ.NIC
> 
>     > I'm starting to wonder whether a bof is needed.  Maybe the IAB's
>     > workshop will produce some fruit?

---

From: Ted Lemon <[email-masked]>
Date: Thu, 10 Aug 2017 08:43:00 -0400

Petr, forgive me for holding your feet to the fire on this, but you make
several statements along the lines of "for me, ... is stretching the
definition too far," "I disgree that this is less significant," et cetera,
but you don't actually raise any technical objections—you just expressed
uneasy feelings, with which I don't think the working group is competent to
help you.  Your claim that this is a new wire format is incorrect.   What
it would mean for this to be a new wire format is that it is incompatible
with the existing wire format.   Doing something like that is an
interesting job that is potentially worth working on, but would have a very
long deployment window, if it got deployed at all.

What we are proposing here is not a new wire format.  It is compatible
with, and enhances, the existing wire format.

As for whether the working group should in fact undertake some grand design
process for such a format, I don't have a strong opinion, but the first
question I would raise is simply this: do *you* want to undertake such an
effort?   If the answer is yes, can you give me a sense of what your goals
are?  The reason I ask is that IETF working groups are constrained to do
work that participants are willing to do, and thus far we have seen no
evidence that you are interested in working on this document, which has
been a working group document for a year.

As for whether this document is in charter, what we are proposing is
certainly in scope for the working group—it's very clearly an operational
enhancement for DNS in streaming protocols.   It doesn't change the way you
do DNS queries—it just adds some new capabilities for new implementations.
  I think it's very clearly useful—we already have three use cases for it.
  If we were to stop work on this document now, the work that now relies on
it would revert to what had been proposed earlier, which was not as
good—dnssd has been hanging fire waiting for this work to be done because
the working group wanted to cooperate with dnsop in producing something
more generally useful, rather than doing a one-off extension like Apple's
DNS Long-Lived Queries, which was never standardized.

So if there is something missing from the document, or something unclear,
or you wish we'd thought of ???, or think that !!! is not quite right and
have suggestions, I think that would be really helpful.   And of course the
working group chairs are free to agree with your vague feelings of unease
and drop this as a working group document.

But as for any sort of specific request that the authors or the working
group could act on, I am not hearing anything of that sort in what you have
said.   Can you think about this in that context, and see if you can more
clearly articulate what it is that you find lacking in this proposal, so
that the working group can figure out how to fix it?   Can you do it soon?

Thanks!

---

From: Petr Špaček <[email-masked]>
Date: Fri, 18 Aug 2017 17:12:55 +0200

Hello Ted and dnsop,

I'm trying really hard to find out why we do not understand each other
so I dug into to dnsop archives and draft-bellis-dnsop-session-signal-00
to see if my questions were already answered somewhere. Hopefully I have
better understanding and will focus on technical questions.

To be absolutely clear:
There are parts of session signaling I *do like*, especially the idea to
use a new OPCODE to separate "signaling" from "normal traffic". Also, I
do not object to DNS-SD and other features built on top of session
signaling!

On 10.8.2017 14:43, Ted Lemon wrote:
> definition too far," "I disgree that this is less significant," et
> cetera, but you don't actually raise any technical objections—you just
> expressed uneasy feelings, with which I don't think the working group is
> competent to help you.

I will try my best to make the point even clearer, I promise!

My objections are in the end about engineering costs, which was nicely
summarized by Paul Vixie in another thread (about SWILD, but applicable
to session signaling as well):
https://mailarchive.ietf.org/arch/msg/dnsop/xMvOuQqWCWZtql1gqD0UwH354b8

For me the major portion of cost does not come from features (like
session management etc.) but from the *framework* needed to build them.
This cost increase IMHO stems from fact that the framework (SS aka DNS
control plane as you named it) does not build on existing and widely
available components.

I believe that added complexity is one of serious technical parameters
and I was objecting to it 4 months ago already:
https://mailarchive.ietf.org/arch/msg/dnsop/XjbQlz5dPblzfGr0OBrr5afKBEg

> Your claim that this is a new wire format is
> incorrect.   What it would mean for this to be a new wire format is that
> it is incompatible with the existing wire format.   Doing something like
> that is an interesting job that is potentially worth working on, but
> would have a very long deployment window, if it got deployed at all.
> 

Let's not focus on wording but on the meaning.

We can certainly call TLVs "extension" but renaming it does not remove
the fundamental problem:
TLVs are largely incompatible with the code we already have widely
implemented and deployed everywhere in all the DNS implementations and
tools. As a consequence, it is increasing engineering cost for all
involved parties.

Please keep in mind that "involved parties" mean also all the people who
are not interested in support for session signaling but happen to work
on DNS monitoring, testing, etc. This will get worse if SS gets off is
used as "DNS control plane" because at that point everyone will have to
support it, with all its costs.

> As for whether the working group should in fact undertake some grand
> design process for such a format, I don't have a strong opinion, but the
> first question I would raise is simply this: do /you/ want to undertake
> such an effort?   If the answer is yes, can you give me a sense of what
> your goals are?  The reason I ask is that IETF working groups are
> constrained to do work that participants are willing to do, and thus far
> we have seen no evidence that you are interested in working on this
> document, which has been a working group document for a year.

I apologize for taking so long before noticing the draft. To paraphrase:

I tried to ignore this draft for a while, but became alarmed after
reading about some of the recent development, so I went and read the
document.

:-)

> certainly in scope for the working group—it's very clearly an
> operational enhancement for DNS in streaming protocols.   It doesn't
> change the way you do DNS queries—it just adds some new capabilities for
> new implementations.   I think it's very clearly useful—we already have
> three use cases for it.   If we were to stop work on this document now,
> the work that now relies on it would revert to what had been proposed
> earlier, which was not as good—dnssd has been hanging fire waiting for
> this work to be done because the working group wanted to cooperate with
> dnsop in producing something more generally useful, rather than doing a
> one-off extension like Apple's DNS Long-Lived Queries, which was never
> standardized.
> 
> So if there is something missing from the document, or something
> unclear, or you wish we'd thought of ???, or think that !!! is not quite
> right and have suggestions, I think that would be really helpful.   And
> of course the working group chairs are free to agree with your vague
> feelings of unease and drop this as a working group document.
> 
> group could act on, I am not hearing anything of that sort in what you
> have said.   Can you think about this in that context, and see if you
> can more clearly articulate what it is that you find lacking in this
> proposal, so that the working group can figure out how to fix it?   Can
> you do it soon?

Okay, please let me be even more specific. I believe that WG should seek
answers to following questions and add explanatory text to the draft.

Looking at version draft-ietf-dnsop-session-signal-03#section-1:

In general, as far as I can tell, this document gives no clear
justification why it is a good idea to do it this way. What I really
want, on the highest level, is to see a justification why it is a good
idea *to not reuse and extend existing framework* like EDNS. We have not
been told of the practical problems that preclude solutions which are
closer to existing code, e.g. EDNS, which would lower the engineering
costs for the whole ecosystem.

Let me make clear that when I talk about EDNS and other existing stuff,
I still think about variant where e.g. EDNS is used in messages with new
OPCODE, so the separation is still there. This is in no way proposal to
mix SS and non-SS traffic.

To avoid all doubts, here is my list of specific high-level problems
paragraph-by-paragraph:

   The existing EDNS(0) Extension Mechanism for DNS [RFC6891] is
   explicitly defined to only have "per-message" semantics.  Whilst
   EDNS(0) has been used to signal at least one session related
   parameter (the EDNS(0) TCP Keepalive option [RFC7828]) the result is
   less than optimal due to the restrictions imposed by the EDNS(0)
   semantics and the lack of server-initiated signalling.

a) What are technical reasons not to use EDNS similarly to what RFC7828
have done?
Specifically what is "less than optimal"?
What problems of RFC7828 are we trying to avoid?

b) What is the technical reason to invent a new thing instead of solving
"lack of server-initiated signaling" in EDNS instead?

Without justification it seems like we are not reusing code we have and
thus increasing costs unnecessarily.

   This document defines a new Session Signaling OPCODE used to carry
   persistent "per-session" operations, expressed using type-length-
   value (TLV) syntax, and defines an initial set of TLVs used to manage
   session timeouts and termination.

c) What were technical reasons to standardize TLV format over something
else? What technical criteria were used to design the new format?

Again, without justification it seems like we are not reusing code we
have and thus increasing costs unnecessarily.

   With EDNS(0), multiple options may be packed into a single OPT
   pseudo-RR, and there is no generalized mechanism for a client to be
   able to tell whether a server has processed or otherwise acted upon
   each individual option within the combined OPT RR.  The
   specifications for each individual option need to define how each
   different option is to be acknowledged, if necessary.

d) Is it something which is not solved by EDNS capabilities (just an
example)? I really need to see a justification why it is better to start
from scratch instead of improving existing standards and code.

   With Session Signaling, in contrast, there is no compelling
   motivation to pack multiple operations into a single message for
   efficiency reasons.  Each Session Signaling operation is communicated
   in its own separate DNS message, and the transport protocol can take
   care of packing separate DNS messages into a single IP packet if
   appropriate.  For example, TCP can pack multiple small DNS messages
   into a single TCP segment.  The RCODE in each response message
   indicates the success or failure of the operation in question.

e) Technically packing multiple messages into one single TCP segment is
not a property of session signaling but property of the transport. It
would work the same way if we were sending DNS messages with OPT
containing one EDNS option at a time. Current EDNS options define how
server replies to client, so the client gets a reply according to
particular standard. If the option is missing in the answer then it is
not supported by server, i.e. the cost of detecting unsupported options
is the very same as for session signaling with TLV (one round-trip).

In other words, this paragraph does not justify costs for inventing a
new thing because the EDNS already can do the same.

4.1.3.  EDNS(0) and TSIG

   Since the ARCOUNT field MUST be zero, a Session Signaling message
   MUST NOT contain an EDNS(0) option in the additional records section.
   If functionality provided by current or future EDNS(0) options is
   desired for Session Signaling messages, a Session Signaling Operation
   TLV or Modifier TLV needs to be defined to carry the necessary
   information.

   For example, the EDNS(0) Padding Option [RFC7830] used for security
   purposes is not permitted in a Session Signaling message, so if
   message padding is desired for Session Signaling messages, a Session
   Signaling Modifier TLV needs to be defined to perform this function.

   Similarly, a Session Signaling message MUST NOT contain a TSIG
   record.  A TSIG record in a conventional DNS message is added as the
   last record in the additional records section, and carries a
   signature computed over the preceding message content.  Since Session
   Signaling data appears after the additional records section, it would
   not be included in the signature calculation.  If use of signatures
   with Session Signaling messages becomes necessary in the future, an
   explicit Session Signaling Modifier TLV needs to be defined to
   perform this function.
[snip]
   This specification explicitly prohibits use of the EDNS(0) TCP
   Keepalive Option [RFC7828] in _any_ messages sent on a Session
   Signaling session (because it duplicates the functionality provided
   by the Session Signaling Keepalive operation), but messages may
   contain other EDNS(0) options as appropriate.

f) Section 4.1.3. shows the problem in full. Approach envisioned by the
draft duplicates work and thus leads to unnecessary engineering costs
again. Re-inventing things for two incompatible frameworks (EDNS and SS)
will cost everyone a lot of effort.

Are there technical reasons justifying these costs? The document does
not answer this question, which is a significant problem.

Can we work together and find answers to there questions?
I will be happy to participate in the process.

Petr Špaček  @  CZ.NIC

> 
> Thanks!
> 
> On Thu, Aug 10, 2017 at 7:28 AM, Petr Špaček <[email-masked]
>     [1]
>     http://mailarchive.ietf.org/arch/msg/dnsop/MOFBFQAaZ2iZUDje3zWNBRn9xKQ
>     <http://mailarchive.ietf.org/arch/msg/dnsop/MOFBFQAaZ2iZUDje3zWNBRn9xKQ>
> 
>     [2]
>     https://datatracker.ietf.org/meeting/99/materials/minutes-99-dnsop
>     <https://datatracker.ietf.org/meeting/99/materials/minutes-99-dnsop>
> 
> 
>     Again:
>     > On Fri, Jul 21, 2017 at 10:02 AM, Petr Špaček <[email-masked] <mailto:[email-masked]>
>     > <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>     >

---

From: Ted Lemon <[email-masked]>
Date: Fri, 18 Aug 2017 13:39:35 -0400

El 18 ag 2017, a les 11:12, Petr Špaček <[email-masked]> va escriure:
> https://mailarchive.ietf.org/arch/msg/dnsop/xMvOuQqWCWZtql1gqD0UwH354b8 <https://mailarchive.ietf.org/arch/msg/dnsop/xMvOuQqWCWZtql1gqD0UwH354b8>
Paul's arguments aren't at all applicable here.   He's talking about having two different resource records that require detailed special handling; adding a new resource record that accomplishes what is accomplished by existing code in a different way produces a substantial increase in complexity not in the transport part of the DNS protocol, but in the semantics engine of your DNS cache.

> control plane as you named it) does not build on existing and widely

It's true, TLVs are quite innovative, and have never been used elsewhere.   ;-)

> https://mailarchive.ietf.org/arch/msg/dnsop/XjbQlz5dPblzfGr0OBrr5afKBEg <https://mailarchive.ietf.org/arch/msg/dnsop/XjbQlz5dPblzfGr0OBrr5afKBEg>
The problem is that you didn't say then, and you don't say now, why this supposed complexity is an important technical consideration.   And it's hard for me to see what the issue is.   Nobody has to support this; if you support it, it's because you want the features.   If you want the features, the complexity isn't really in the wire format serialization and deserialization—this are trivial.   The complexity is in, for example, implementing DNS Push through a DNS cache if you want to support it in that context.   I admit that this is complex, and I suspect that there will be little enthusiasm for doing it.   That's okay—it's actually not required that any cache implement DNS push in order for us to get the benefit of it.   But this complexity has nothing to do with the wire format.

The wire format itself is dead trivial.   If in fact you need to implement it, for example in wireshark, there is already code in wireshark for unpacking TLVs, so it's a very small update.   In comparison, adding some new EDNS0-style OPT RR actually require special custom code in wireshark, because the fields in the RR are given different meanings just for that one RR.   Of course, wireshark already (I assume) understands EDNS0, but we can't use EDNS0; if we add a new SSIG RR that looks like an OPT RR, we would be creating more work for wireshark hackers than if we just did what the current spec says to do.

> costs for the whole ecosystem.

The most obvious practical problem is that, as I said above, adding another EDNS0-style option is more complex than using TLVs.   In addition, it consumes more packet space.   The actual format of the packet is less sensible.   The decode/encode logic is more complicated.   I don't know if you've written an EDNS0 decoder/encoder; I have.   It's not pretty.

Of course you already have one, and so do I; maybe we could reuse the code.   Doing so would also add complexity.   And the fact remains that it's a needlessly arcane data format.   The DNSIND (I think) working group settled on EDNS0 because they thought, as you did, that using something that looked like a DNS RR would make it more likely that things would work, but that turned out to be true—we had endless nightmares with middleboxes being confused by EDNS0.

The point being, EDNS0 was a design compromise based on assumptions that turned out not to be true.   I think if the working group had it to do over again and could see the future, they would have done something like session signaling, rather than adding the OPT RR.   Of course, that's just my opinion, but the reasoning is as valid now as it would have been then.

The rest of your comments appear to be rehashes of the same basic point, which boils down to "this is harder than that," with no actual technical basis for making such an assertion.

What I meant when I said "do you have any technical objections" was not "could you repeat for me in more detail the points you already made earlier about how if you were designing the enhancement, you would have done it differently."   That's basically what you've done here.   You would have done it differently.  That's fine, we're all reasonable people here, but we won't always agree on matters of taste.

But there's no technical objection here.   You've asked us to justify design decisions we've made (I use "we" loosely here, since I'm an end user of the document, not an author), but not provided any technical objection to those design decisions.   It's not good enough to say "I think that EDNS0 would be more right."  You need to actually say why TLVs are wrong (or, I suppose, why EDNS0 is more right).   You haven't done that.

---

From: Tom Pusateri <[email-masked]>
Date: Fri, 18 Aug 2017 16:46:48 -0400

> On Aug 18, 2017, at 11:12 AM, Petr Špaček <[email-masked]> wrote:
> 

There were two main reasons we chose to use TLVs instead of the EDNS(0) RR format for Session Signaling (soon to be called DNS Stateful Operations) and it was quite intentional:

1. Given the fact that we were using a new Opcode, we had the opportunity to change the packet format for the better (at the suggestion of Mark Andrews). There has been a lot of people in DNSOP saying EDNS(0) OPT RRs were a mistake. To be fair, some people like it or are agnostic but we’ve heard more complaints than support. Using a new Opcode created an unusual and infrequent opportunity to switch to TLVs without a backlash since all the code would be doing new things.

2. Since EDNS(0) is per packet and not per session, and Session Signaling is defined per session over a reliable, ordered transport, we think it will be less confusing and simpler for implementors to have separate code to deal with session semantics over the existing per packet datagram semantics that don’t mean the same thing.

* When I say we, I am saying what I understand to be the consensus of the authors. I don’t mean to speak directly for the other authors and I will let them correct me if there is disagreement that I am not aware of.

Thanks,
Tom

---

From: Petr Špaček <[email-masked]>
Date: Thu, 24 Aug 2017 17:38:06 +0200

Hello Ted and Tom,

I'm going to reply to both of you at once.

First of all, I'm not going to push for wire format change any longer.

Your replies show that there is a lot of thoughts behind the document
*but* these are not captured in the document itself nor dnsop mailing
list. (Maybe I'm just incompetent when it comes to searching archives.)

I believe that our disagreement partially comes from misunderstanding
each other, partially from missing information, and of course there is
some true disagreement, but that is a matter of taste :-)

Here I propose explanatory version of Introduction chapter for your
draft. Goal of the proposal is to document why SS deviates from rest of
DNS protocol so we have something to reference when new proposal for
OPCODE=666 comes up (and thus do not need to go though this again).

The text is based on my understanding to Ted and Tom's comments and
might be wrong, feel free to modify it as needed.

------------------
1.  Introduction

|  The use of transports for DNS other than UDP is being increasingly
|  specified, for example, DNS over TCP [RFC1035][RFC7766] and DNS over
|  TLS [RFC7858].  Such transports can offer persistent, long-lived
|  sessions and therefore when using them for transporting DNS messages
|  it is of benefit to have a mechanism that can establish parameters
|  associated with those sessions, such as timeouts.  In such situations
|  it is also advantageous to support server initiated messages.
|
|  The existing EDNS(0) Extension Mechanism for DNS [RFC6891] is
|  explicitly defined to only have "per-message" semantics.  Whilst
|  EDNS(0) has been used to signal at least one session related
|  parameter (the EDNS(0) TCP Keepalive option [RFC7828]) the result is
|  less than optimal due to the restrictions imposed by the EDNS(0)
|  semantics and the lack of server-initiated signalling.

Extending EDNS(0) with "per-session" semantics is not worth the effort
for several reasons: Most importantly EDNS(0) design is based on
assumption that format similar to ordinary RR would make it more likely
that things would work. Past experience shown us that this assumption is
incorrect and in reality it is causing nightmares with middleboxes being
confused by EDNS(0). Secondly, re-using EDNS(0) for "per-session"
operation would be confusing because current code handling per-message
semantics would have to be extended to deal with session semantics.
Thirdly, adding another EDNS0-style option is deemed to be more complex
than using the new proposed format, it would consume more packet space,
and the actual format of the packet would be less sensible, resulting in
more complex decode/encode logic.

To avoid problems related to EDNS(0) usage, this document defines a new
extension mechanism for the original DNS protocol. The new extension is
based on a new Session Signaling OPCODE used to carry persistent
"per-session" operations, expressed using type-length-value (TLV)
syntax. The new Opcode allows us to change the packet format for the better.

|  It should be noted that the message format for Session Signaling
|  operations (see Section 4.1) differs from the traditional DNS packet
|  format used for standard queries and responses.  The standard twelve-
|  octet header is used, but the four count fields (QDCOUNT, ANCOUNT,
|  NSCOUNT, ARCOUNT) are set to zero and the corresponding sections are
|  not present.  The actual data pertaining to Session Signaling
|  operations is appended to the end of the DNS message header.  When
|  displayed using today's packet analyser tools that have not been
|  updated to recognize the DNS Session Signaling format, this will
|  result in the Session Signaling data being displayed as unknown
|  additional data after the end of the DNS message.

In contrast with EDNS(0), this new extension mechanism has no compelling
motivation to pack multiple operations into a single message for
|  efficiency reasons.  Each Session Signaling operation is communicated
|  in its own separate DNS message, and the transport protocol can take
|  care of packing separate DNS messages into a single IP packet if
|  appropriate.  For example, TCP can pack multiple small DNS messages
|  into a single TCP segment.  The RCODE in each response message
|  indicates the success or failure of the operation in question.

On top of this new extension mechanism, this document defines an initial
set of TLVs used to manage session timeouts and termination.

------------------ End of Introduction ------------------

Can we get something explanatory like this into the document, please?
Thank you!

On 18.8.2017 19:39, Ted Lemon wrote:
> El 18 ag 2017, a les 11:12, Petr Špaček <[email-masked]
> <mailto:[email-masked]>> va escriure:
> Paul's arguments aren't at all applicable here.   He's talking about
> having two different resource records that require detailed special
> handling; adding a new resource record that accomplishes what is
> accomplished by existing code in a different way produces a substantial
> increase in complexity not in the transport part of the DNS protocol,
> but in the semantics engine of your DNS cache.
> 
> The problem is that you didn't say then, and you don't say now, why this
> supposed complexity is an important technical consideration.   And it's

I'm confused. Do you really claim
"complexity is not an important technical consideration"
?

Is https://tools.ietf.org/html/rfc3439 applicable only to IP?
(Feel free to interpret this as rhetorical question.)

> hard for me to see what the issue is.   Nobody has to support this; i> you support it, it's because you want the features.   If you want the
> features, the complexity isn't really in the wire format serialization
> and deserialization—this are trivial.   The complexity is in, for
> example, implementing DNS Push through a DNS cache if you want to
> support it in that context.   I admit that this is complex, and I
> suspect that there will be little enthusiasm for doing it.   That's
> okay—it's actually not required that any cache implement DNS push in
> order for us to get the benefit of it.   But this complexity has nothing
> to do with the wire format.

Of course, if you want features you have to code them, agreed. The thing
is that this proposal pushes complexity to places which do not want any
features at all.

We need to consider existence of DNS software which cares only about DNS
wire format and nothing else. Many of these tools do not actively
participate in DNS query-response protocol, they just observe and
analyze what is going on wire. Another category are test tools etc.

Nevermind. It will be good enough if we (we as in dnsop) at least
document why SS is deemend to be the right way to extend DNS.

-- 
Petr Špaček  @  CZ.NIC