Subject: Re: [DNSOP] raising the bar: requiring implementations

From: Petr Špaček <[email-masked]>
Date: Wed, 4 Apr 2018 11:22:33 +0200

On 29.3.2018 22:05, Mukund Sivaraman wrote:
> On Thu, Mar 29, 2018 at 03:18:45PM -0400, Suzanne Woolf wrote:
>>
>> On Mar 28, 2018, at 11:19 AM, Mukund Sivaraman <[email-masked]> wrote:
>>
>>> On Wed, Mar 28, 2018 at 10:55:13AM -0400, tjw ietf wrote:
>>>> I would say that most things we have adopted in the past few years do have
>>>> some implementations to reference.
>>>> Not when drafts are adopted, but generally before we head to WGLC I've
>>>> always wanted to see someone
>>>> who implemented the option in some manner.
>>>>
>>>> But yes, agree.
>>>
>>> I'd raise the bar even higher, to see complete implementation in a major
>>> open source DNS implementation when it applies. Sometimes implementation
>>> problems are very revealing (client-subnet should have gone through
>>> this).
>>
>> This is actually quite a good example of another problem:
>> Client-subnet was documented for Informational purposes; it was
>> already in wide use in the public internet and had an EDNS opt code
>> codepoint allocated from the IANA registry.
>>
>> Nothing that happened in DNSOP or the IETF changed that, and I
>> strongly suspect nothing that happened in DNSOP or the IETF could have
>> changed it.
> 
> We found issues in the client-subnet description (in the draft stages)
> that were corrected before it became RFC - this involved some behavioral
> changes. However, the opportunity was not given to address fundamental
> design issues, so what's in the RFC largely documents the
> implementations preceding it and still has issues. I didn't think
> client-subnet was in wide use when it came to dnsop. Even today it
> doesn't look like it's in wide use.
> 
> You have asked an interesting question, because what happens if
> something is already being used and there's no chance to update/correct
> problems because that would make it a different protocol?
> 
> IMO, we should not put anything through dnsop that does not allow
> reviewing and correcting problems. It is pointless for dnsop to shepherd
> a draft to RFC when there's no possibility to influence it.
> 
> During later stages of the draft via dnsop, we implemented client-subnet
> (resolver side) and found various problems. Some of these were addressed
> in the draft, but it was revealing how poor the state of the
> design/draft was. This is why I strongly suggest: A code contribution of
> a _complete implementation_ of everything described in the draft to one
> of the open source DNS implementations should come sometime during
> adoption, so that
> 
> (a) issues in production implementation are revealed
> 
> (b) it can be tried in the real world to understand how it behaves.
> 
> As you're a co-chair:
> 
> When Bert did that Camel presentation, I felt hooray, here's one of us
> who's talking about what the steady churn of ideas and RFCs is doing to
> DNS implementations. We finish implementing one draft and at almost
> breathless pace, a few more drafts queue up. It's not sustainable,
> esp. as all the existing features also need to be maintained for years.
> 
> Introducing a new RR type that doesn't involve additional processing is
> relatively trivial and nobody objects about it.
> 
> Introducing something like TCP pipelining, or rather, out-of-order query
> processing, may seem trivial when describing the change, but
> implementing it may need fundamental restructuring of the
> implementation. Proper implementation of client-subnet needs change
> everywhere within a nameserver from the client message parsing code to
> the data structures used for cache, and how cache lifetime is managed.
> 
> Implementations are being stretched and bent 5 different ways to adapt
> to the length and breadth of all these newfangled DNS items that
> literally are showing up at an alarming pace.
> 
> Bert really hit the spot at the right time. Something needs to be done
> to check what becomes an RFC. A good way is to require an open source
> implementation. If draft authors cannot supply that or convince an open
> source implementation to write support for it, it can go back to where
> it came from.

I tend to agree with Mukund. What's the point of doing standards, if
there is nothing to test against?

Let's imagine that e.g. Cisco and Google propose a brand new feature of
DNS protocol, but its implementation is available only for their
enterprise customers. Why should The Internet bother?

DNS is/was mostly open-source place, and I have a feeling that RFCs are
in the end closely followed only by open-source implementations anyway,
and that rest of the DNS players do whatever they want.
Examples:
- Empty non-terminals vs. Akamai
- EDNS vs. Cisco middleboxes
- EDNS ignorance (auth side) vs. Google
- <do not force me to copy&paste dns-violations here>

So, why should we (as dnsop) bother "ratifying" something for the big
folks who simply do not care enough to follow what we already published?

I can see parallel with TLS group where "big guys" continually submit
various drafts to accommodate their needs while not paying attention to
impact on the rest of ecosystem. TLS WG resists, we as dnsop should
resist as well.

-- 
Petr Špaček  @  CZ.NIC

---

From: Petr Špaček <[email-masked]>
Date: Wed, 4 Apr 2018 11:29:27 +0200

On 29.3.2018 22:59, Phillip Hallam-Baker wrote:
> On Thu, Mar 29, 2018 at 3:18 PM, Suzanne Woolf <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
> 
>     Should we refuse to document such things because they’re not in
>     well-known open source codebases, or have otherwise not passed tests
>     of goodness?
> 
>     It’s not a rhetorical question. Given that people are extending the
>     protocol outside of the IETF or any other formal process, in order
>     to solve their own technical and business problems, it makes sense
>     to ask ourselves periodically whether we should be encouraging them,
>     trying to stop them, or something in between.
> 
> 
> ​There are in fact precedents for doing something of the sort. But not
> ones that I think we should follow.
> 
> DNSSEC would have been implemented as part of the VeriSign ATLAS roll
> out. The reason it was not was it simply could not be deployed using the
> tech available with the spec as it was at the time without a major
> increase in cost and complexity.
> 
> A blanket requirement for open source implementations may well have the
> same effect.
> 
> Operating systems at Internet scale is vastly more complex than running
> systems at network scale. It is not just the genius of the original
> Internet designers that has allowed the Internet to scale from 100 nodes
> to 10 billion. There is a vast amount of unseen engineering work that is
> equally heroic and some of that infrastructure comes with some very
> specific constraints.
> 
> Some of the most useful work in IETF is making closed systems more open.
> Often those projects require some extra slots to carry information that
> is needed for some legacy system. I see no value to saying folk can't
> have a smooth transition path from proprietary to open.

I do not see a problem. First there needs to be running code and RFC
will follow. It IMHO does not make much sense the other way around, and
we will suffer for next decade because we did not follow this rule in
the past.

-- 
Petr Špaček  @  CZ.NIC

---

From: 神明達哉 <[email-masked]>
Date: Thu, 5 Apr 2018 10:39:58 -0700

At Wed, 4 Apr 2018 11:22:33 +0200,

> > doesn't look like it's in wide use.

[...]

> there is nothing to test against?

I also agree here.  Especially in the case of client-subnet, I
observed another (IMO) bad practice that seems to be abused quite
often recently: use the word of "informational" as an excuse for
dismissing suggestions.  The commonly seen logic is "this is just
intended to be an information document, just describing an existing
deployment in case that may be useful for others (and so any
significant changes should be rejected)".  But in actuality such a
spec is often used as a standard protocol spec that should be
interoperable among various different implementations.  And, IMO, that
was actually the case for ECS.

Another rhetoric often (ab)used in such a case is to say "a more
complete full standard will follow this informational document; we can
make significant changes at that point."  But in reality such a
followup task often doesn't even start.  Again, that's also the case
for ECS after nearly two years since the publication of RFC7871.

In the context of the camel discussion, I think we should use this
lesson for rejecting this kind of abusing the "informational" status.
We should not pretend it's really just for information when we
actually expect it will be used a "de facto" standard that is likely
to be implemented by various vendors.

--
JINMEI, Tatuya

---

From: tjw ietf <[email-masked]>
Date: Thu, 5 Apr 2018 13:46:29 -0400

What is work: An "informational" document being used as standard is people
taking a submitted (expired) draft as "standard"?

Tim

On Thu, Apr 5, 2018 at 1:39 PM, 神明達哉 <[email-masked]> wrote:

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: 神明達哉 <[email-masked]>
Date: Thu, 5 Apr 2018 13:31:37 -0700

At Thu, 5 Apr 2018 13:46:29 -0400,

> taking a submitted (expired) draft as "standard"?

I'm not sure how to interpret it (not even sure if it's a question to
me)...but I guess what I think is the most important point of my
previous message is "for future dnsop documents, we shouldn't use the
intended informational status as an excuse to casually dismiss serious
questions/suggestions from implementers".

--
JINMEI, Tatuya

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 5 Apr 2018 17:16:30 -0400

On Wed, Mar 28, 2018 at 05:24:33PM +0200, bert hubert wrote:
> allow the one remaining closed source DNS implementation

!!!!

Really?  I'm so pleased we have not only candidate censors of what is
going to be published by the WG but also census-takers who have
determined then number and types of DNS implemntations in the
universe.

In case it isn't clear from the above, I am deeply uncomfortable with
the entire DNS-police-cum-government latent in this thread.  I think
interoperability is important and valuable.  I do not think that
creating a clubhouse of kool kids who decide what "is" a DNS
implementation is wise, however.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Evan Hunt <[email-masked]>
Date: Fri, 6 Apr 2018 04:35:44 +0000

On Thu, Apr 05, 2018 at 01:31:37PM -0700, 神明達哉 wrote:
> me)...

I suspect Tim meant to type "What is worse: An 'informational' document
being used as standard, or people taking a submitted (expired) draft as
'standard'?"

To answer, I think which of those is worse depends on the implementation
status. I don't have any problem with an informational document to explain
the details of something that's already widely deployed, but which for
whatever reason can't go through the standards process.

Consider RPZ, for example: it's been implemented several times, there's
lots and lots of real-world deployment experience. I'd be happy to see an
informational RFC describing it; I'd be confident in its stability.
Relying on old expired drafts would be disappointing.

ECS, though, was published before it was fully cooked, and continuing to
iterate and update the drafts would've been better.

-- 
Evan Hunt -- [email-masked]
Internet Systems Consortium, Inc.

---

From: 神明達哉 <[email-masked]>
Date: Mon, 9 Apr 2018 11:07:30 -0700

At Fri, 6 Apr 2018 04:35:44 +0000,

> being used as standard, or people taking a submitted (expired) draft as

Ah, okay, it makes sense, thanks.  (Correcting this was far beyond my
ability of dealing with the language of English:-).  I still don't
know if it was meant to be a counter argument to my previous message
or an unrelated followup, but in any case that's a different topic

> iterate and update the drafts would've been better.

and, at least in retrospect, my observation was that the intended
informational status was (ab)used to have this result, and IMO we
should be careful not to repeat it.

--
JINMEI, Tatuya