Re: [Curdle] WGLC draft-schaad-curdle-oid-registry

[Russ Housley <[e-mail]>]

Daniel Migault is the document shepherd and Eric Rescorla is the responsible Area. 
s/Area/Area Director/

Some questions do not have answers: (8), (13), (15)

Russ


> On Sep 27, 2017, at 2:56 PM, Daniel Migault <[e-mail]> wrote:
> 
> Hi, 
> 
> Please find the shepherd write up:
> 
> https://datatracker.ietf.org/doc/draft-schaad-curdle-oid-registry/shepherdwriteup/ <https://datatracker.ietf.org/doc/draft-schaad-curdle-oid-registry/shepherdwriteup/>
> 
> Feel free to comment, by the end of the week. 
> 
> Yours, 
> Daniel
> 
> Small comments:
> a)
> [I-D.ietf-curdle-pkix <https://tools.ietf.org/html/draft-schaad-curdle-oid-registry-02#ref-I-D.ietf-curdle-pkix>] should also be added as normative and 
> [I-D.ietf-curdle-pkix <https://tools.ietf.org/html/draft-schaad-curdle-oid-registry-02#ref-I-D.ietf-curdle-pkix>-3] as informational. I think the normative comment is missing
> Maybe a note to the editor should be added. We need to avoid the RFC being in the informational reference ;-)
> b) the draft may be named ietf-curdle-oid-registry to reflect a WG document
> 
> c) title of section 2.1 may be removed and all its content placed in section 2
> 
> d) If that is possible would it be possible to indicate the exact location where the 
> table is expected to be added. Currently my understanding is that it is not possible, 
> but once the table will be added you will be 1) more specific and 2) add a link as an
>  informal reference. 
> 
> 
> On Thu, Jun 8, 2017 at 5:36 PM, Jim Schaad <[e-mail] <mailto:[e-mail]>> wrote:
>  
> 
>  
> 
> From: Curdle [mailto:[e-mail] <mailto:[e-mail]>] On Behalf Of Daniel Migault
> Sent: Thursday, June 8, 2017 12:55 PM
> To: Sean Turner <[e-mail] <mailto:[e-mail]>>
> Cc: curdle <[e-mail] <mailto:[e-mail]>>
> Subject: Re: [Curdle] WGLC draft-schaad-curdle-oid-registry
> 
>  
> 
> Hi,
> 
> Thank you for updating the draft Jim and Rick. While reviewing the draft for the shepherd -write up I came with a few comments/questions.  Please find my comments below.
> 
> Yours,
> 
> Daniel
> 
>  
> 
> COMMENT A)
> 
> The type of the draft is currently "informational". According to RFC 2026 I am more incline to consider that BCP would be more appropriated. Any thoughts on that ?
> 
> The draft does not discuss any technical content. The draft describes the set of OIDs that have been donated. In some ways, it also assigns OIDs that have not been assigned by any other RFCs ( but only version-03 of the pkix draft). It also describes the creation of an IANA registry table, as well as update procedure for adding new entries which includes, parameters to provide, the review process to follow and the way the arc can be extended. 
> 
> In that sense according to RFC2026 the document is essentially documenting IETF operations and so BCP seems the appropriated type.
> 
> [JLS] I am not sure how you would presume that this could be a BCP?  What practices are we recommending that be followed?  I think that this makes far more sense as informational.  There is nothing that says that an informational draft be technical.  Lots of informational drafts are about procedures or about thought processes.  I would keep this where it is.
> 
>  
> 
> COMMENT B) 
> 
> It might my fault as I commented on the earlier version the references [I-D.ietf-curdle-pkix <https://tools.ietf.org/html/draft-schaad-curdle-oid-registry-01#ref-I-D.ietf-curdle-pkix>] for id-EdDSA25516-ph and id-EdDSA448-ph. It looks confusing to have OIDs reserved for a specific Description while not being assigned. As we have the intention to keep these OIDs, I think you opened a better path to have a RFC as a reference than having an old version of a draft. 
> 
> I interpret the the following text as explaining why we ended up with id-EdDSA25516-ph and id-EdDSA448-ph. 
> 
> """
> 
>    After those registrations were
>    done, there were still some unused values that can be used for other
>    security groups, there were still some unused values.
> """
> 
> Placing the current document as the Reference would clarify, in my opinion, the status of these OIDs. It may be useful to add some text that provides more explication with an reference to [I-D.ietf-curdle-pkix <https://tools.ietf.org/html/draft-schaad-curdle-oid-registry-01#ref-I-D.ietf-curdle-pkix>]-03. As the RFC editor will probably replace [I-D.ietf-curdle-pkix <https://tools.ietf.org/html/draft-schaad-curdle-oid-registry-01#ref-I-D.ietf-curdle-pkix>] with the RFC number, It might also be better to have a specific informational reference.   
> 
> [JLS] There is a request in the XML that the RFC editor make sure that this specific reference point to the version of the ID and not the RFC. However, it gets messy if you have [draft] and [draft-3] I the same document as well.  Visually, it is currently a hard thing to do.
> 
> 
> COMMENT C)
> 
> The draft says:
> 
> """
> 
> IANA is asked to create one new registry table.
>  <>2.1 <https://tools.ietf.org/html/draft-schaad-curdle-oid-registry-01#section-2.1>.  "SMI Security for Cryptographic Algorithms" Registry
> 
>  
> Within the SMI-numbers registry, add an "SMI Security for
> Cryptographic Algorithms" table with the three columns:
> """
> 
> Maybe we should also specify that the SMI Security for Cryptographic Algorithm registry is a sub-item of the "SMI Security Codes Registries". 
> 
> 
> I believe it would be useful to have an URL as an informational reference for both the "SMI-numbers registry" as well as for "SMI Security Codes Registries". 
> 
> https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml <https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml>
> https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbers-26 <https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbers-26>
> Although I am not aware of a registration procedure for these tables and the current, I believe it would be useful to specify explicitly all fields associated to the table.
> 
>     - Registration: Procedure Although it can be inferred from the current text. I believe it is helpful to the IANA to have the exact filed value associated to all fields.
> 
>     - Description: The description is usually the arc ID, maybe in our case we should add the range of provided OIDs.
> 
>     - Reference: It seems to me that the current document would be appropriated.
> 
>     - Expert: The Registration Procedure mentions Expert review. I am not sure experts should be listed in the in the RFC RFC5226  appointed by IESG. 
> 
>  
> 
> [JLS] This is really a bit of a mess, because it does not really belong under the SMI Security Codes section if one were being string.  It is not prefixed with the OID defined for that section.  It is unfortunate that Russ had all of the PKIX and S/MIME registries placed below that section.  However using the registry template associated with that would not really be correct.  I may talk to IANA during the process of final registration to see if we can create a new header and move all of the registries into that new header but I don’t want to do that as part of this document as it probably would be messy to state.  This type of decision is normally made on the fly during the registration process and is not normally called out explicitly.
> 
>  
> 
> Experts are normally suggested by the authors, chairs or shepherds of the document during the IESG review process at the request of the AD.
> 
>  
> 
> We will end up with an entry that looks like https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#security-smime-3 <https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#security-smime-3> which provides a template of what is defined here.
> 
>  
> 
> jim
> 
>  
> 
>  
> 
>  
> 
> On Sat, Jun 3, 2017 at 9:48 AM, Sean Turner <[e-mail] <mailto:[e-mail]>> wrote:
> 
> I hadn’t read it before, but it does what it says it’s going to do and it’s pretty darn short and straight forward.  Ship it!
> 
> spt
> 
> 
> > On Jun 2, 2017, at 16:39, Daniel Migault <[e-mail] <mailto:[e-mail]>> wrote:
> >
> > Hi,
> >
> > This email starts a WGLC for draft-schaad-curdle-oid-registry[1]. The draft received significant comments during the WG adoption and is expected to be close to its final version. Please provide your feed backs by June 16.
> >
> > Yours,
> > Rich and Daniel
> >
> > [1] https://datatracker.ietf.org/doc/draft-schaad-curdle-oid-registry/ <https://datatracker.ietf.org/doc/draft-schaad-curdle-oid-registry/>
> > _______________________________________________
> > Curdle mailing list
> > [e-mail] <mailto:[e-mail]>
> > https://www.ietf.org/mailman/listinfo/curdle <https://www.ietf.org/mailman/listinfo/curdle>
> 
> _______________________________________________
> Curdle mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/curdle <https://www.ietf.org/mailman/listinfo/curdle>
>  
> 
> 
> _______________________________________________
> Curdle mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/curdle <https://www.ietf.org/mailman/listinfo/curdle>
> 
> 
> _______________________________________________
> Curdle mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/curdle