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

[Daniel Migault <[e-mail]>]

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

>
>
>
>
> *From:* [e-mail] [mailto:[e-mail]] *On Behalf Of *Daniel
> Migault
> *Sent:* Thursday, September 28, 2017 7:07 AM
> *To:* Jim Schaad <[e-mail]>
> *Cc:* curdle <[e-mail]>
> *Subject:* Re: [Curdle] WGLC draft-schaad-curdle-oid-registry
>
>
>
> 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 <[e-mail]>
> 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.
>
>
>
> [JLS] I would describe the creation before the population.  That is why I
> suggested change the sentence order.
>
<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>


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

>
>    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.
>
>
>
<mglt>thanks for the correction.</mglt>

>
>
>
>
> If you resubmit a new version please could you changethe file name to
> draft-ietf-curdle....
>
>
>
> 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]>
> 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]>
> 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]> wrote:
>
>
>
>
>
> *From:* Curdle [mailto:[e-mail]] *On Behalf Of *Daniel
> Migault
> *Sent:* Thursday, June 8, 2017 12:55 PM
> *To:* Sean Turner <[e-mail]>
> *Cc:* curdle <[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#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]> 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]>
> 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]
> > https://www.ietf.org/mailman/listinfo/curdle
>
> _______________________________________________
> Curdle mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/curdle
>
>
>
>
> _______________________________________________
> Curdle mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/curdle
>
>
>
> _______________________________________________
> Curdle mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/curdle
>
>
>
>
> _______________________________________________
> Curdle mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/curdle
>
>
>
>
> _______________________________________________
> Curdle mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/curdle
>
>
>
> _______________________________________________
> Curdle mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/curdle
>
>