Re: Last Call: Simple Secure Domain Name System (DNS) Dynamic Update to Proposed Standard

[Thomas Narten <[e-mail]>]

> "Domain Name System Security Signing Authority" is a minor update to
> RFC2535 it restricts the set of keys that can sign DNS data to zone
> keys at APEX.  This is a great simplification that is only possible
> as RFC2137 is obsoleted by the other draft.  RFC2137 requires that
> other keys can sign data.

Having now dug deeper (as I should have done before sending my first
note!), I agree that 2535 is just updated.

> I thought Historic status is reserved for documents that are not replaced by
> any other document. But in this case the protocol change is significant 
> enough to warrant moving RFC2137 to historic and consider the new one a 
> new protocol ?

Take a look at 2026 for guidelines. The paragraph I find most
compelling here is:

> 6.4  Retiring a Standard
> 
>    As the technology changes and matures, it is possible for a new
>    Standard specification to be so clearly superior technically that one
>    or more existing standards track specifications for the same function
>    should be retired.  In this case, or when it is felt for some other
>    reason that an existing standards track specification should be
>    retired, the IESG shall approve a change of status of the old
>    specification(s) to Historic.  This recommendation shall be issued
>    with the same Last-Call and notification procedures used for any
>    other standards action.  A request to retire an existing standard can
>    originate from a Working Group, an Area Director or some other
>    interested party.

If the message we want to send is "don't implement 2137",
reclassifying it as historic would seem stronger.

"Donald E. Eastlake 3rd" <[e-mail]> writes:

> I think of Historic as being for a protocol that has fallen from use
> or been replaced by a completely new protocol, not for a stage in
> the evolution of the same protocol (although such judgements are no
> doubt in the eye of the beholder).

Reclassifying a document historic is also done to send a
message. I.e., RIP version 1 was reclassified to historic despite
widespread use precisely because RIP version 2 was what we wanted
folks to implement.

> I think someone reading
> draft-ietf-dnsext-simple-secure-update-01.txt should have RFC 2137
> for comparison rather than having RFC 2137 already on the trash
> heap, although I have no doubt that almsot all will still prefer the
> new draft.

What I'm hearing from these messages is that we don't want to give
implementors a choice as to which to implement. We want them to
implement the new ID. Reclassifying the document historic doesn't
prevent people from reading it.

Thomas


to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.