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

From: Daniel Migault <[email-masked]>
Date: Wed, 27 Sep 2017 14:56:52 -0400

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

>
>
>
>
> *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.
>
> """
>
>    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#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 <[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
>
>
> > On Jun 2, 2017, at 16:39, 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/
>
> > _______________________________________________
> > Curdle mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/curdle
>
> _______________________________________________
> Curdle mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/curdle
>
>
>
> _______________________________________________
> Curdle mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/curdle
>
>

---

From: Russ Housley <[email-masked]>
Date: Wed, 27 Sep 2017 15:01:24 -0400

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 <[email-masked]> wrote:
> 
> Hi, 
> 
> https://datatracker.ietf.org/doc/draft-schaad-curdle-oid-registry/shepherdwriteup/ <https://datatracker.ietf.org/doc/draft-schaad-curdle-oid-registry/shepherdwriteup/>
> 
> [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 ;-)
> 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 <[email-masked] <mailto:[email-masked]>> wrote:
>  
> 
>  
> 
> From: Curdle [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Daniel Migault
> Sent: Thursday, June 8, 2017 12:55 PM
> To: Sean Turner <[email-masked] <mailto:[email-masked]>>
> Cc: curdle <[email-masked] <mailto:[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:
> 
> """
> 
>  <>2.1 <https://tools.ietf.org/html/draft-schaad-curdle-oid-registry-01#section-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". 
> 
> 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 <[email-masked] <mailto:[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
> 
> 
> > On Jun 2, 2017, at 16:39, Daniel Migault <[email-masked] <mailto:[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/>
> > [email-masked] <mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/curdle <https://www.ietf.org/mailman/listinfo/curdle>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/curdle <https://www.ietf.org/mailman/listinfo/curdle>
>  
> 
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/curdle <https://www.ietf.org/mailman/listinfo/curdle>
> 
>

---

From: Daniel Migault <[email-masked]>
Date: Wed, 27 Sep 2017 15:08:08 -0400

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

>> In that sense according to RFC2026 the document is essentially
>> documenting IETF operations and so BCP seems the appropriated type.
>>
>> https://www.iana.org/assignments/smi-numbers/smi-numbers.
>> xhtml#smi-numbers-26
>>
>>     - 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.
>>
>> 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
>>
>>
>>
>>
>>
>>
>>

---

From: Jim Schaad <[email-masked]>
Date: Wed, 27 Sep 2017 18:25:35 -0700

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: [email-masked] [mailto:[email-masked]] On Behalf Of Daniel Migault
Sent: Wednesday, September 27, 2017 12:08 PM
To: Russ Housley <[email-masked]>
Cc: Jim Schaad <[email-masked]>; curdle <[email-masked]>; Sean Turner <[email-masked]>
Subject: Re: [Curdle] WGLC draft-schaad-curdle-oid-registry

Yours, 

Daniel

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

s/Area/Area Director/

Russ

On Sep 27, 2017, at 2:56 PM, Daniel Migault <[email-masked] <mailto:[email-masked]> > wrote:

Hi, 

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

From: Curdle [mailto:[email-masked] <mailto:[email-masked]> ] On Behalf Of Daniel Migault
Sent: Thursday, June 8, 2017 12:55 PM
To: Sean Turner <[email-masked] <mailto:[email-masked]> >
Cc: curdle <[email-masked] <mailto:[email-masked]> >
Subject: Re: [Curdle] WGLC draft-schaad-curdle-oid-registry

Hi, 

Yours, 

Daniel

COMMENT A) 

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. 

"""

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:

"""

 <https://tools.ietf.org/html/draft-schaad-curdle-oid-registry-01#section-2.1> 2.1.  "SMI Security for Cryptographic Algorithms" Registry

"""

https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml
https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbers-26

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,
>

---

From: Daniel Migault <[email-masked]>
Date: Thu, 28 Sep 2017 10:06:37 -0400

Hi Jim,

Thanks for the feed backs. Please find my response in line.

Yours,
Daniel

On Wed, Sep 27, 2017 at 9:25 PM, Jim Schaad <[email-masked]> wrote:

>
>    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.
>
> Correct. "In some ways" resulted from a bad copy/ paste. I not sure I
really get the sentence numbers. The current paragraph is as below. Ar eyou
ok with it.
The draft does not discuss any technical content. The draft describes
the set of OIDs that have been donated. 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. 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.

>    1.
>    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.
>
>  The comment on the XML specifies the version of the CURDLE draft is
version 3. The reference is in the informational reference.My understanding
is that the final to become RFC will also be needed and that the v3 will
not be the only reference used. I think this reference is missing in the
normative reference.

>
>
>    1. This registry does require Expert review per section 4.6 of RFC
>    8126.
>
> I think that was the sense of my response to question 18. Is the text
clearer ?

Future allocation does not require Expert review, instead it uses
"specification required".

If you resubmit a new version please could you changethe file name to
draft-ietf-curdle....

>
>
> Jim
>
>
>
>
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of *Daniel
> Migault
> *Sent:* Wednesday, September 27, 2017 12:08 PM
> *To:* Russ Housley <[email-masked]>
> *Cc:* Jim Schaad <[email-masked]>; curdle <[email-masked]>; Sean
> Turner <[email-masked]>
>

---

From: Jim Schaad <[email-masked]>
Date: Thu, 28 Sep 2017 07:36:45 -0700

From: [email-masked] [mailto:[email-masked]] On Behalf Of Daniel Migault
Sent: Thursday, September 28, 2017 7:07 AM
To: Jim Schaad <[email-masked]>
Cc: curdle <[email-masked]>
Subject: Re: [Curdle] WGLC draft-schaad-curdle-oid-registry

Hi Jim, 

Yours, 

Daniel

On Wed, Sep 27, 2017 at 9:25 PM, Jim Schaad <[email-masked] <mailto:[email-masked]> > wrote:

Correct. "In some ways" resulted from a bad copy/ paste. I not sure I really get the sentence numbers. The current paragraph is as below. Ar eyou ok with it. 

[JLS] I would describe the creation before the population.  That is why I suggested change the sentence order.

1.	 

 The comment on the XML specifies the version of the CURDLE draft is version 3. The reference is in the informational reference.My understanding is that the final to become RFC will also be needed and that the v3 will not be the only reference used. I think this reference is missing in the normative reference.  

[JLS]  Currently both of those references are informational.  I think this is correct as one does not need to understand the content there in order to understand what is happening in this draft.  If you really want them to be normative that is a problem because of the down ref to -03.  I think they should both be at the same level.

1.	This registry does require Expert review per section 4.6 of RFC 8126.

I think that was the sense of my response to question 18. Is the text clearer ?

Future allocation does not require Expert review, instead it uses "specification required". 

[JLS] RFC 8126 says “For the Specification Required policy, review and approval by a designated expert (see Section 5 <https://tools.ietf.org/html/rfc8126#section-5> ) is required”  This text says that an expert review is required even if the policy is specification required.

If you resubmit a new version please could you changethe file name to draft-ietf-curdle.... 

Jim

From: [email-masked] <mailto:[email-masked]>  [mailto:[email-masked] <mailto:[email-masked]> ] On Behalf Of Daniel Migault
Sent: Wednesday, September 27, 2017 12:08 PM
To: Russ Housley <[email-masked] <mailto:[email-masked]> >
Cc: Jim Schaad <[email-masked] <mailto:[email-masked]> >; curdle <[email-masked] <mailto:[email-masked]> >; Sean Turner <[email-masked] <mailto:[email-masked]> >

Yours, 

Daniel

s/Area/Area Director/

Russ

Hi, 

Yours, 

Daniel

Small comments:

a)

 

Hi, 

Yours, 

Daniel

COMMENT A) 

COMMENT B) 

"""

COMMENT C)

The draft says:

"""

"""

jim

spt

---

From: Daniel Migault <[email-masked]>
Date: Thu, 28 Sep 2017 13:35:32 -0400

Hi Jim,

I think the current write-up address your comment. Let me know if that is
fine to you, so I can press the button.

Yours,
Daniel

On Thu, Sep 28, 2017 at 10:36 AM, Jim Schaad <[email-masked]> wrote:

> *Sent:* Thursday, September 28, 2017 7:07 AM
> *To:* Jim Schaad <[email-masked]>
<mglt>
The current text is:
The draft does not discuss any technical content. The draft describes
the set of OIDs that have been donated.  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. 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.

I think that address your comment.
</mglt>

> [JLS]  Currently both of those references are informational.  I think this
> is correct as one does not need to understand the content there in order to
> understand what is happening in this draft.  If you really want them to be
> normative that is a problem because of the down ref to -03.  I think they
> should both be at the same level.
>
> <mglt>Actually, I expected RFC to be normative and -03 to be
informational, I even did not thought of having the RFC as informational...
As this is intentional, I will describe this in the shepherd write up and
let the AD come back if he prefer otherwise. At least I understand your
position now. Thanks. </mglt>

> [JLS] RFC 8126 says “For the Specification Required policy, review and approval by a designated expert (see Section 5 <https://tools.ietf.org/html/rfc8126#section-5>) is required”  This text says that an expert review is required even if the policy is specification required.
>
>
>
<mglt>thanks for the correction.</mglt>

---

From: Jim Schaad <[email-masked]>
Date: Thu, 28 Sep 2017 11:18:07 -0700

Looks fine to me.

Yours, 

Daniel

s/Area/Area Director/

Russ

Hi, 

Yours, 

Daniel

Small comments:

a)

 

Hi, 

Yours, 

Daniel

COMMENT A) 

COMMENT B) 

"""

COMMENT C)

The draft says:

"""

"""

jim

spt