Re: [dnsext] Last Call: <draft-ietf-dnsext-dnssec-registry-fixes-08.txt> (Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm IANA Registry) to Proposed Standard

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Jun 01, 2011 at 03:45:48PM -0400, Edward Lewis wrote:

> >So, the goal here is threefold: (1) to collect all those MUSTs and
> >MUST NOTs into one RFC: anything not defined in that RFC as required
> >is completely optional; (2) to provide a single place where
> >implementers can find out where that advice is located; (3) to make
> >sure that we don't somehow end up with conflicting advice.
> 
> That would be nice, I just think a registry is the wrong place to
> put that - because registries change and old (deployed)
> implementations don't.

> >In this way, the draft is using the registry exactly as it was
> >intended: it is a control point that makes sure a given assignment
> >happens in a co-ordinated way.  In this case, the assignment is "DNS
> >community current best advice about what will be maximally
> >interoperable."  It's not a blessing; it's just another entry that
> >ensures co-ordination on the Internet in a way that ensures
> >interoperability is maximized.
> 
> But the "current best advice" changes.  And old versions of software don't.

Right.  And the RFC to which those old versions of software conforms
doesn't change either.

You cannot claim conformance to the registry, because registries are
not an archival series and because they do change.  We agree on that.
But you don't seem to think that the registry of RRTYPE code points
changing is a bad idea, even though early software didn't have the
RRTYPE for DNAME or DNSKEY.  In the same way, the registry of these
algorithm types might change, and it wouldn't matter.  But nobody is
allowed to put _anything_ into that "Compliance to RFC TBD1" column.
If the WG wants in future to make some shiny new algorithm
"RECOMMENDED TO IMPLEMENT" according to the latest guidance, and wants
that to be reflected in a registry somewhere, then the answer is to
write a new document that obsoletes the draft we're talking about, and
completely replace the typecode registry again, with the new values
(presumably, a new column, called "Compliance to RFC TBD2", and
dropping the analagous column from the current version).

I believe that nothing anywhere in the document suggests that one
ought to guage conformance of software against the registry, and if
you think it says that somewhere, I'd like a pointer to where.  It
would need to be fixed if it said that, but as far as I can tell it
does not.

A

-- 
Andrew Sullivan
ajs@xxxxxxxxxxxxxxxxxx
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]