Re: [dane] DANE operational requirements

[Lawrence Conroy <[e-mail]>]

Hi there,
 a data point:
In ENUM, the version 2.0 specs were RFC3261 and RFCs 3401-3405. These were "non-trivial" to implement fully.
[This whole area also had informational RFCs making 2116 statements, had a few odd interactions with other specs, and so on -- fun].

=> Rather than just produce narrow errata against the specs, we created an "ENUM Experiences" slide deck deck (and then an I-D) to capture the way in which folks had misunderstood the ENUM spec[s] and where there were options that didn't work as easily as originally planned**
The output of this I-D became a WG doc, and that was eventually released as a BCP (RFC5483).


As this BCP showed that there was genuine confusion over how to implement this stuff, we rolled the lessons learn into an update of the ENUM spec (RFC6116).

This needed people willing to do the work, some honest implementors to explain what c*ck-u*s they had had made, and a great deal of patience; it took years.

Was it worth it? Yes, IMHO.
Was it easy/quick? Nope.

I might add that it did teach me that producing the one true scheme that combined two different ways of thinking (URIs and URNs) made for a b*st*rd to implement system. This and other DANE threads show how much fun the different use cases are, and how they require implementors to get their heads in quite different orientations to make the whole thing work. ... but that's just me.

Going for an "Implementation Experiences" capture document may well defuse the "errata or change request or dispepsia" discussions.
The RFC exists, and if it leaves scope for people to shoot themselves in the foot (or for the server owners to shoot the clients in the foot), it's much better to produce an improved doc set (as "experiences" and then an osoletes/updates spec), IMHHO.

=> Who is going to do the work, and capture the DANE experiences? -- it's a non-trivial effort, but crucial to duffers who might want to use this stuff.

=> Is there enough energy **and goodwill** in the WG to take this forward, rather than argue the toss over whether or not this particular use case or that is the spawn of satan?

all the best,
  Lawrence

** [That Experiences work DID require a promise in blood that those who talked to the authors would not be identified, nor laughed at too loudly]


On 20 Apr 2013, at 18:02, Paul Hoffman wrote:
> On Apr 20, 2013, at 9:41 AM, Viktor Dukhovni <[e-mail]> wrote:
>> Would these all be one draft?  Are there are other implementors on this
>> list, and do they have additional material to contribute?
> 
> If this is a WG document, that decision is ultimately made by the WG. Note that, when a motivated document editor puts additional important considerations in a document, the WG rarely removes them. (Although the WG might significantly change them, often for the better, as we saw in this very WG.)
> 
> If this is an individual submission, the author is the sole decider of what goes in or not. Things might be removed during IETF Last Call, but that is rare; the most common outcomes are minor additions and changes.
> 
> Having said all that:
> 
>>   - A description of an implementation of DANE with no changes to
>>     OpenSSL, just a verification callback.
> 
> RFCs rarely have such descriptions. However, this sounds quite useful, and I would hope that an appendix that has this would be allowed to remain.
> 
> --Paul Hoffman