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

[Jim Schaad <[e-mail]>]

1.	I would not use the phrase “In some ways”.  “It uses the assignments made by the document draft-ietf-curdle-pkix to prepopulate the table, including a pair of assignments made during discussions that did not make the final draft.”    Delete sentence 2, put this in as a new sentence 3.
2.	As noted before, the instructions to deal with the reference to the -03 draft are in the XML as a request to the RFC editor.
3.	This registry does require Expert review per section 4.6 of RFC 8126.

 

Jim

 

 

From: [e-mail] [mailto:[e-mail]] On Behalf Of Daniel Migault
Sent: Wednesday, September 27, 2017 12:08 PM
To: Russ Housley <[e-mail]>
Cc: Jim Schaad <[e-mail]>; curdle <[e-mail]>; Sean Turner <[e-mail]>
Subject: Re: [Curdle] WGLC draft-schaad-curdle-oid-registry

 

Thanks. It is better to be explicit and complete.These have been addressed.

Yours, 

Daniel

 

 

On Wed, Sep 27, 2017 at 3:01 PM, Russ Housley <[e-mail] <mailto:[e-mail]> > wrote:

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] <mailto:[e-mail]> > wrote:

 

Hi, 

Please find the shepherd write up:

 

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.

 <https://tools.ietf.org/html/draft-schaad-curdle-oid-registry-01#section-2.1> 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#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 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/

> _______________________________________________
> Curdle mailing list
> [e-mail] <mailto:[e-mail]> 
> https://www.ietf.org/mailman/listinfo/curdle

_______________________________________________
Curdle mailing list
[e-mail] <mailto:[e-mail]> 
https://www.ietf.org/mailman/listinfo/curdle

 


_______________________________________________
Curdle mailing list
[e-mail] <mailto:[e-mail]> 
https://www.ietf.org/mailman/listinfo/curdle

 

_______________________________________________
Curdle mailing list
[e-mail] <mailto:[e-mail]> 
https://www.ietf.org/mailman/listinfo/curdle

 


_______________________________________________
Curdle mailing list
[e-mail] <mailto:[e-mail]> 
https://www.ietf.org/mailman/listinfo/curdle