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

From: Daniel Migault <[email-masked]>
Date: Fri, 2 Jun 2017 16:39:43 -0400

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/

---

From: Russ Housley <[email-masked]>
Date: Fri, 2 Jun 2017 16:41:49 -0400

The comments that I made have been addressed, and I think the document is ready for publication.

Russ

> On Jun 2, 2017, at 4:39 PM, Daniel Migault <[email-masked]> 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/>
>

---

From: "Mark D. Baushke" <[email-masked]>
Date: Fri, 2 Jun 2017 15:18:39 -0700

The comments that I made for draft-schaad-curdle-oid-registry have been
addressed, and I think the document is ready for publication.

	-- Mark

---

From: Sean Turner <[email-masked]>
Date: Sat, 3 Jun 2017 09:48:37 -0400

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 <[email-masked]> wrote:
> 
> Hi, 
> 
> _______________________________________________
> Curdle mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/curdle

---

From: Daniel Migault <[email-masked]>
Date: Thu, 8 Jun 2017 15:55:15 -0400

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.

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.

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#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.

On Sat, Jun 3, 2017 at 9:48 AM, Sean Turner <[email-masked]> 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
>
> > 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
> >

---

From: Jim Schaad <[email-masked]>
Date: Thu, 8 Jun 2017 14:36:39 -0700

From: Curdle [mailto:[email-masked]] On Behalf Of Daniel Migault
Sent: Thursday, June 8, 2017 12:55 PM
To: Sean Turner <[email-masked]>
Cc: curdle <[email-masked]>
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. 

"""

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

"""

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". 

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 <[email-masked] <mailto:[email-masked]> > wrote:

spt

> On Jun 2, 2017, at 16:39, Daniel Migault <[email-masked] <mailto:[email-masked]> > wrote:
>
> Hi,
>

> [email-masked] <mailto:[email-masked]> 

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