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 <housley@vigilsec.com> 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 <daniel.migault@ericsson.com>
> 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 <ietf@augustcellars.com> wrote:
>
>>
>>
>>
>>
>> *From:* Curdle [mailto:curdle-bounces@ietf.org] *On Behalf Of *Daniel
>> Migault
>> *Sent:* Thursday, June 8, 2017 12:55 PM
>> *To:* Sean Turner <sean@sn3rd.com>
>> *Cc:* curdle <curdle@ietf.org>
>> *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 <sean@sn3rd.com> 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 <daniel.migault@ericsson.com>
>> 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
>> > Curdle@ietf.org
>> > https://www.ietf.org/mailman/listinfo/curdle
>>
>> _______________________________________________
>> Curdle mailing list
>> Curdle@ietf.org
>> https://www.ietf.org/mailman/listinfo/curdle
>>
>>
>>
>> _______________________________________________
>> Curdle mailing list
>> Curdle@ietf.org
>> https://www.ietf.org/mailman/listinfo/curdle
>>
>>
> _______________________________________________
> Curdle mailing list
> Curdle@ietf.org
> https://www.ietf.org/mailman/listinfo/curdle
>
>
>
> _______________________________________________
> Curdle mailing list
> Curdle@ietf.org
> https://www.ietf.org/mailman/listinfo/curdle
>
>