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

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

While draft-ietf-dnsext-simple-secure-update-01.txt replaces RFC 2137,
draft-ietf-dnsext-signing-auth-01.txt really just tweaks RFC 2535
which it is an order or magnitude shorter than.  

I suppose 2137 could be declared historic but I'm not sure I see the
point.  People are not supposed to implement obsoleted RFCs and there
are some elements of RFC 2137 in
draft-ietf-dnsext-simple-secure-update-01.txt.  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).  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.

Donald

From:  Thomas Narten <[e-mail]>
Message-Id:  <[e-mail]>
To:  [e-mail]
In-Reply-To:  Message from The IESG <[e-mail]> 
	        of "Fri, 02 Jun 2000 08:34:25 EDT." <[e-mail]> 
Date:  Fri, 02 Jun 2000 11:49:23 -0400
Sender:  [e-mail]
Precedence:  bulk
>The IESG <[e-mail]> writes:
>
>> The IESG has received a request from the DNS Extensions Working Group
>> to consider Simple Secure Domain Name System (DNS) Dynamic Update
>> <draft-ietf-dnsext-simple-secure-update-01.txt> as a Proposed Standard.
>> This will replace/obsolete RFC2137, currently a Proposed Standard.
>
>> The IESG will also consider Domain Name System Security (DNSSEC)
>> Signing Authority <draft-ietf-dnsext-signing-auth-01.txt> as a Proposed
>> Standard, updating RFC2535
>
>Both of these IDs would appear to be significant replacements of their
>corresponding RFCs. Also, when a new RFC replaces on old one, its
>expected to include a "Changes relative to RFC XXX" section in them to
>help implementors understand what has changed. That might not make
>sense here, i.e., is this replacement vs. changing.
>
>Question: should either of the two RFCs actually be reclassified as
>Historic, as opposed to just being obsoleted? If there is little or no
>deployment and the point is to not have anyone implement the old RFCs,
>reclassifying them to historic might be the way to go.
>
>Thomas


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