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

[Petr Špaček <[e-mail]>]

On 11.7.2017 13:23, Ted Lemon wrote:
> On Jul 11, 2017, at 3:17 AM, Petr Špaček <[e-mail]
> <mailto:[e-mail]>> wrote:
>> I feel that implications from switch to non-RR format are underestimated
>> and following e-mail attempts to explain why I believe it is a bad idea.
>> Please accept my apology for such long e-mail.
> 
> Petr, with all due respect, I did not see a counter-proposal here, and
> your comments seem to reflect a misunderstanding of what
> session-signaling is.
> 
> In fact, the opposite of what you said is true: if this were done as a
> normal query with EDNS0-like encapsulation, _then_ we would see
> problems, because session signaling messages would look more like DNS
> queries, and less like control messages.  This is not a desirable quality.
> 
> It's true that, for example, the DNS packet compression format would
> have to deal with this specially, but that would also be true if this
> were done EDNS0-style.   It's true that packet dumpers would have to
> deal with this specially, but that's also true if it's done EDNS0-style.
>   Etc.

Let me clarify that I'm not insisting specifically on EDNS0. From my
perspective anything which does not deviate from current wire format is
okay.


> It may be that there is a good point in your argument somewhere, but at
> the moment, I don't see one.   E.g., in your python example, yes, if
> this were an RR, not being able to plop it into your RR-handling switch
> would suck.   But it's not an RR, doesn't have the semantics of an RR,
> and if you plop it into your RR-handling switch, you're probably getting
> the semantics wrong.

This might be key to the the misunderstanding:

I'm not talking about semantics at all. What I object to is the proposed
wire format, not the semantics. The fact that bytes are stored in format
compatible with RR (RFC 1035 section 4.1.3) is not related to its semantics.


> So if you want to make this case, I think you need to be more specific
> about why this is a problem: when I think about how to implement this
> (which I have done, because I'm using it for dnssd), what you are
> advocating seems harder, not easier, than what is currently being proposed.
I'm trying to explain that deviance from RR format (RFC 1035 section
4.1.3) will force parties in the DNS ecosystem to implement support for
the new wire format even though they are not interested in session
signaling at all.

For a lot of cases it would be sufficient if SS data could be treated as
one of many "unknown RR types" (RFC 3597). For example tools for
statistics would work, the capture formats would not need special
extensions for SS, etc.

We can discuss this in depth during dnsop session today.

-- 
Petr Špaček  @  CZ.NIC