Subject: Re: [dnsext] WGLC: draft-ietf-dnsext-dnssec-registry-fixes-06

From: "Rose, Scott W." <[email-masked]>
Date: Wed, 1 Dec 2010 10:26:34 -0500

Will fix the DSA-NSEC3-SHA1 discrepancy.  

As for the other blanks - those were semi-intentional.  I was thinking of asking the WG for status, but other things took over.  However, the -07 will only list the status if it is not OPTIONAL - so all blank entries will be OPTIONAL.  The text will be updated to state this.

Scott

On Nov 26, 2010, at 7:17 AM, Ben Niven-Jenkins wrote:

> Andrew,
> 
> I gave the draft a quick read.
> 
> Section 2.1 states:
> 
>   The status of RSASHA1-NSEC3-SHA1 and DSA-NSEC3-SHA1 are set to
>   RECOMMENDED and OPTIONAL respectively.
> 
> However, the status column for DSA-NSEC3-SHA1 in the table in section 2.2 is blank.
> 
> Also the status column for some other algorithms (Diffie-Hellman, DSA/SHA-1, GOST R) are also blank and the document does not provide any advice on how a blank status column entry should be interpreted.
> 
> Ben
> 
> On 25 Nov 2010, at 17:30, Andrew Sullivan wrote:
> 
>> Dear colleagues,
>> 
>> We noted in our report from the chairs around the time of IETF 79 that
>> we'd soon start a Working Group Last Call for
>> draft-ietf-dnsext-dnssec-registry-fixes-06.  Only 8 days late, this
>> message is in fact initiating that LC.
>> 
>> We hereby commence a Working Group Last Call on
>> draft-ietf-dnsext-dnssec-registry-fixes-06 ending 2011-12-03 at 22:00
>> UTC.  Please review the document for correctness and clarity, and send
>> to the list any comments you might have.  If you have no comments but
>> support the document being published, we ask that you also send that
>> information to the list.  Finally, if you read the document and do not
>> support its publication, that is also information we would appreciate
>> receiving on list.
>> 
>> There is one nit in the document you may overlook in your review:
>> there is a reference to ietf-dnsext-dnssec-alg-allocation, but that is
>> now available as RFC 6014.  The reference will be updated in the next
>> revision.
>> 
>> Under the conventions adopted by DNSEXT, the document needs at least
>> five reviewers to say that they have read the document, and that they
>> support its publication.  This is a short document that, in my
>> personal view, makes the IANA registry for Domain Name System Security
>> (DNSSEC) Algorithm Numbers more useful to the Internet protocols
>> community.  I urge participants in the working group to review the
>> document so that we can proceed with the next steps in its
>> publication.  If you are a new participant here and are looking for
>> something with which to get your feet wet, this is an excellent
>> document to start with.
>> 
>> Best regards,
>> 
>> Andrew (document shepherd)
>> 
>> -- 
>> Andrew Sullivan
>> [email-masked]
>> Shinkuro, Inc.
>> _______________________________________________
>> dnsext mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/dnsext
> 
> _______________________________________________
> dnsext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsext

===================================
Scott Rose
NIST
[email-masked]
+1 301-975-8439
Google Voice: +1 571-249-3671
http://www.dnsops.gov/
===================================

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 1 Dec 2010 10:45:20 -0500

> As for the other blanks - those were semi-intentional.  I was thinking of asking the WG for status, but other things took over.  However, the -07 will only list the status if it is not OPTIONAL - s…

The text does need to be updated to state that, but let's just explain
for a moment why the column is blank instead of saying "optional".

The document specifies a rule for the registry that says that if the
column in question has an entry that is changed, then the entire
registry needs to be respecified by whatever document is so changing
the column.

But, new entries can be added to the registry under the process
established by RFC 6014.  Such additions don't need to produce a
completely new registry every time.

Remember that the goal here is to have the registry reflect (loosely
speaking) an interoperability "requirement" level for algorithms, to
expect new allocations most of which are not really required for
interoperability among implementations, that registries cannot be
normative, and that it is impossible for any given RFC to change the
facts of the matter about a previous RFC.  So a non-entry for
"optional" algorithms is a little process trick by which we can
constrain later changes to the registry that specify a "required
algorithm" while yet satisfying the above requirements.  Really, for
the registry to say that an algorithm is "required" is to say that, to
conform with such-and-thus RFC, you need to implement such-and-thus
algorithm.  So we just don't have an entry for anything that will come
in under normal circumstances, and for those things where the WG wants
to say, "Really implement this," we have to do more work.  (Sorry to
be so process-wonky about this, but we really do have to work within
the strictures of the RFC series.)

I think another participant may be going to post a suggestion about
the table layout to make the above even clearer, so I'll wait for
that.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 1 Dec 2010 10:50:07 -0500

> the table layout to make the above even clearer, so I'll wait for

Oops, I see Paul Hoffman already did this.  Please see his message on the topic.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 1 Dec 2010 09:30:39 -0800

>the strictures of the RFC series.)

A different (and shorter) way to say this is "A blank entry for the conformance requirement to RFC TBD1 means that there is no conformance requirement for RFC TDB1." This RFC does not make implementing something optional: it is already optional.

--Paul Hoffman, Director
--VPN Consortium

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Mon, 6 Dec 2010 06:57:30 +0000

Paul,

One question for clarification which also relates to the table you posted in a previous mail.

> A different (and shorter) way to say this is "A blank entry for the conformance requirement to RFC TBD1 means that there is no conformance requirement for RFC TDB1." This RFC does not make implemen…

RFC TBD1 == the RFC number eventually allocated to draft-ietf-dnsext-dnssec-registry-fixes, right?

Ben

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 6 Dec 2010 06:58:43 -0800

>RFC TBD1 == the RFC number eventually allocated to draft-ietf-dnsext-dnssec-registry-fixes, right?

Exactly right. And, if the table is later replaced (as is described in the RFC), that column header would be updated with the new RFC.

--Paul Hoffman, Director
--VPN Consortium

---

From: "Rose, Scott W." <[email-masked]>
Date: Tue, 7 Dec 2010 14:40:23 -0500

FWIW, the current, working version of Section 2.2:

2.2.  Domain Name System (DNS) Security Algorithm Number Registry Table

   The Domain Name System (DNS) Security Algorithm Number registry is
   hereby specified as follows:

                                       Trans-
                                 Zone  action  Compliance to
Number  Description    Mnemonic   Sign  Sign     this memo     Reference
------  -----------     ------    ----  -----  ------------   ---------
 0      Reserved                                             [RFC4398]
 1      RSA/MD5         RSAMD5     N     Y    MUST NOT       [RFC2537]
                                              IMPLEMENT
 2      Diffie-Hellman  DH         N     Y                   [RFC2539]
 3      DSA/SHA-1       DSASHA1    Y     Y                   [RFC2536]
 4      Reserved until
        2020
 5      RSA/SHA-1       RSASHA1    Y     Y    MUST           [RFC3110]
                                              IMPLEMENT
 6      DSA-NSEC3-SHA1  DSA-NSEC3  Y     Y                   [RFC5155]
                        -SHA1
 7      RSASHA1-NSEC3   RSASHA1-   Y     Y    RECOMMENDED    [RFC5155]
        -SHA1           NSEC3-                TO IMPLEMENT
                        SHA1
 8      RSA/SHA-256     RSASHA256  Y     *    RECOMMENDED    [RFC5702]
                                              TO IMPLEMENT
 9      Reserved until
        2020
 10      RSA/SHA-512     RSASHA512  Y     *    RECOMMENDED    [RFC5702]
                                              TO IMPLEMENT
 11      Reserved until
        2020
 12      GOST R          GOST-ECC   Y     *                   [RFC5933]
        34.10-2001
13-251   Unassigned
 252     Reserved for    INDIRECT   N     N                   [RFC4034]
        Indirect keys
 253     private         PRIVATE    Y     Y                   [RFC4034]
        algorithm
 254     private         PRIVATEOID Y     Y                   [RFC4034]
        algorithm OID
 255     Reserved

   Table rows where the compliance column is not filled in are left to
   the discretion of implementors and are NOT REQUIRED for compliance to
   this document.

/end

Not posted, still tinkering with the wording and still have to make a minor change to the IANA Considerations section to reflect the necessary edits they need to do.  

Scott

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Wed, 8 Dec 2010 17:59:21 +0000

Andrew,

Thanks. Your explanation of some of the history and requirement for process finessing was most helpful (for my understanding at least).

I think the new table Scott proposed in his e-mail yesterday along with the additional sentence that a blank compliance field are NOT REQUIRED[1] address my LC comment.

Ben

[1] Although if my memory serves me right the idnits tools will complain that NOT REQUIRED is not specified in RFC2119.

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 8 Dec 2010 13:10:41 -0500

Hi,

One nit.

> Number  Description    Mnemonic   Sign  Sign     this memo     Reference

The title "Compliance to this memo" won't work for the registry,
because in the registry there's no memo for it to refer to.  I think
Paul Hoffman suggested TBD1, with an RFC Editor note saying "please
replace TBD1 with the RFC number if the document is published as an
RFC."  If you have the same note, except using "this memo", that's
also ok, I guess, though "this memo" is sometimes used in text without
the full spelling out of the RFC's series number.

Thanks,

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: "Rose, Scott W." <[email-masked]>
Date: Wed, 8 Dec 2010 13:28:53 -0500

I was going to change the IANA Considerations section to replace the whole "this memo" with "RFC XXXX", but RFC TBD1 is probably more straightforward.  

As per the comment from Ben Niven-Jenkins:  "NOT REQUIRED" is not a keyword in RFC 2119 (yet "REQUIRED" is).  Probably will change text at the bottom of the table to read:

"Table rows where the compliance column is not filled in are left to
  the discretion of implementors and their implementation (or lack thereof) MUST NOT be 
  included when judging compliance to this document."

Too strong?  "SHOULD NOT" instead?

Scott

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 8 Dec 2010 10:45:58 -0800

>I was going to change the IANA Considerations section to replace the whole "this memo" with "RFC XXXX", but RFC TBD1 is probably more straightforward.

I think so. The last thing we want is IANA misunderstanding this and "this memo" appears in the registry.

>Too strong?  "SHOULD NOT" instead?

Both are too strong, given the first clause of the sentence. I propose "... discretion of implementors and their implementation (or lack thereof) therefore cannot be ..."

--Paul Hoffman, Director
--VPN Consortium