Re: [dnsext] CORRECTED Protocol Action: 'Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm Implementation Status' to Proposed Standard (draft-ietf-dnsext-dnssec-algo-imp-status-04.txt)

[Lynne Bartholomew <[e-mail]>]

Dear IESG, Andrew, Ralph, and Brian,

We have updated our database record for this document.  It is now listed as Proposed Standard.

Thank you.

RFC Editor/lb

> From: Brian Haberman <[e-mail]>
> Date: March 14, 2013 7:20:24 AM PDT
> To: Ralph Droms <[e-mail]>
> Cc: Andrew Sullivan <[e-mail]>, The IESG <[e-mail]>, [e-mail], [e-mail], [e-mail]
> Subject: Re: [dnsext] Protocol Action: 'Applicability Statement: DNS Security (DNSSEC)	DNSKEY Algorithm Implementation Status' to Best Current Practice (draft-ietf-dnsext-dnssec-algo-imp-status-04.txt)
> 
> Ugh.  So, the header boilerplate indicates Standards Track, which is good.  I suspect that the announcement text was not updated after that change (and that led to the mis-worded announcement).
> 
> Since this was a BCP->PS change, I think we can ask the secretariat to withdraw the announcement and the shepherding AD can re-generate the text and re-send the announcement.
> 
> Brian
> 
> On 3/14/13 9:45 AM, Ralph Droms wrote:
>> Good catch.  I think it should be standards track, but Ted and Brian are technically in charge now.
>> 
>> - Ralph
>> 
>> On Mar 14, 2013, at 9:42 AM 3/14/13, Andrew Sullivan <[e-mail]> wrote:
>> 
>>> Oh, heck.  One of the things Pete insisted on in his DISCUSS was that
>>> this not be published as BCP but on the standards track, because it's
>>> an applicability statement.
>>> 
>>> I missed the BCP part of this announcement yesterday.
>>> 
>>> Is this a Bad Thing?  Is there something to be done about it?  The
>>> Draft currently says the Intended status is standards track.
>>> 
>>> A


On Mar 14, 2013, at 7:58 AM, The IESG wrote:

> The IESG has approved the following document:
> - 'Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm
>   Implementation Status'
>  (draft-ietf-dnsext-dnssec-algo-imp-status-04.txt) as Proposed Standard
> 
> This document is the product of the DNS Extensions Working Group.
> 
> The IESG contact person is Ralph Droms.
> 
> A URL of this Internet Draft is:
> http://datatracker.ietf.org/doc/draft-ietf-dnsext-dnssec-algo-imp-status/
> 
> 
> 
> 
> Technical Summary 
> 
>  The DNS Security Extensions (DNSSEC) requires the use of 
>  cryptographic algorithm suites for generating digital signatures 
>  over DNS data.  There is currently an IANA registry for these 
>  algorithms that it lacks the recommended implementation status of 
>  each algorithm.  This document provides an applicability statement 
>  on algorithm implementation status for DNSSEC component software. 
>  This document lists each algorithm's status based on the current 
>  reference.  In the case that an algorithm is specified without an 
>  implementation status, this document assigns one.  The document 
>  updates RFCs 2536, 2539, 3110, 4034, 4398, 5155, 5702, and 5933. 
> 
> Working Group Summary 
> 
>    The intended effect of this draft was originally captured in 
>    draft-ietf-dnsext-dnssec-registry-fixes-08, which made a novel and 
>    controversial use of the IANA registry.  That approach was too 
>    controversial, and so the WG split the document into two parts. 
>    This draft is one of them. 
> 
>    The present approach was far less controversial than the previous 
>    one, and nobody has raised any objection to the current text. 
> 
> Document Quality 
> 
>    The draft does not specify a protocol of any kind, but it does 
>    make a recommendation in favour of some algorithms that are so far 
>    not widely deployed.  
> 
>    The discussion of dnssec-registry-fixes led to the approach 
>    instantiated in this draft.  
> 
> Personnel 
> 
>    Andrew Sullivan is the Document Shepherd, and Ralph Droms is the 
>    Responsible Area Director. 
> 
> 
> RFC Editor Note
> 
> Please make the following two changes:
> 
> In section 2.2:
> 
> OLD:
> 
> 2.2.  Algorithm Implementation Status Assignment Rationale
> 
>   The status of RSASHA1-NSEC3-SHA1 is set to Recommended to Implement
>   as many deployments use NSEC3.  The status of RSA/SHA-256 and RSA/
> 
> NEW:
> 
> 2.2.  Algorithm Implementation Status Assignment Rationale
> 
>   RSASHA1 has an implementation status of Must Implement, consistent
>   with [RFC4034].  RSAMD5 has an implementation status of Must Not
>   Implement because of known weaknesses in MD5.
> 
>   The status of RSASHA1-NSEC3-SHA1 is set to Recommended to Implement
>   as many deployments use NSEC3.  The status of RSA/SHA-256 and RSA/
> 
> END
> 
> In the IANA considerations:
> 
> OLD:
> 
>   Because this document establishes the implementation status of every
>   algorithm, it should be listed as a reference for the entire
>   registry.
> 
> NEW:
> 
>  Because this document establishes the implementation
>  status of every algorithm, it should be listed as a reference for
>  the registry itself (leaving in place the individual entries for the
>  algorithms referring to the documents that specify them).
> 
> END
> 
>