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

[Ted Lemon <[e-mail]>]

El 18 ag 2017, a les 11:12, Petr Špaček <[e-mail]> va escriure:
> 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 <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.

> 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.

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

> 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 <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.

> 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.

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.