Re: [lamps] IANA Considerations text for OID allocations

[Russ Housley <[e-mail]>]

> On Oct 1, 2022, at 8:06 AM, Michael Richardson <[e-mail]> wrote:
> 
> Signed PGP part
> 
> Russ Housley <[e-mail]> wrote:
>> I do not see the problem with IANA registries.  All of the other name
>> registrations are here:
> 
> I'm not saying the registries are bad, I'm saying that the resulting IANA
> Considerations text in the RFC is poor.
> 
>> https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.8
> 
>> They all begin with 1.3.6.1.5.5.7.8, which is id-on in the ASN.1
>> module.
> 
> yes.
> I'm trying to get the same clearness in the RFC as well.
> see below:
> 
>>> Yes.  RFC8994's IANA section says:
>>> https://datatracker.ietf.org/doc/html/rfc8994#section-12
> 
>    doc} For the otherName / AcpNodeName, IANA has assigned value 10 for id-
>    doc} on-AcpNodeName in the "SMI Security for PKIX Other Name Forms"
>    doc} (1.3.6.1.5.5.7.8) registry.
> 
> What if IANA instead wrote:
> 
> For the otherName / AcpNodeName, IANA has assigned value 10 
> for id-doc on-AcpNodeName in the "SMI Security for PKIX Other Name Forms"
> (1.3.6.1.5.5.7.8) registry, resulting in an OID of 1.3.6.1.5.5.7.8.10.
> 
> 
> I *think* that the paragraph above gets inserted by IANA, and not by the authors.

I believe that bulk of the text gets inserted by the authors, and then the RFC Editor does a minimal edit to reflect the assignment that is made by IANA.

You can confirm this by looking at the last I-D and comparing it to the RFC.

Russ