Re: [Drip] [Ext] Re: Murray Kucherawy's No Objection on draft-ietf-drip-rid-30: (with COMMENT)

[Robert Moskowitz <[e-mail]>]

On 7/14/22 13:54, Amanda Baber wrote:
>
> Hi,
>
> I think IANA has a tendency to say “do we understand this?” and leave 
> it at that, rather than look at whether the section is clear to 
> non-IANA readers. (We generally assume that the meaning of the section 
> is always going to be more readily apparent to other readers, but it 
> sounds like this may not be the right approach.)
>
> So we do assume that in the absence of an explicit reference, the 
> document itself is the reference, and as such we’re comfortable with 
> Section 8.3, as there don’t appear to be any other candidates for that 
> field. This is almost always the case when a sub-section is making a 
> single registration. I can see, though, how Section 8.5 might be 
> unclear. Given that the description field mentions RFC 8080, would the 
> reference also be to RFC 8080? Our understanding (stated in our last 
> call review) is that this document is the reference, but it wouldn’t 
> hurt to make this explicit.
>

Here we go:

    Hierarchical HIT (HHIT) Prefixes:
       Initially, for DET use, one 28-bit prefix should be assigned out
       of the IANA IPv6 Special Purpose Address Block, namely 2001::/23,
       as per [RFC6890].  Future additions to this subregistry are to be
       made through Expert Review (Section 4.5 of [RFC8126]). Entries
       with network-specific prefixes may be present in the registry.

         HHIT Use     Bits  Value    Reference
         DET          28    TBD6 (suggested value 2001:30::/28) [This]


    Hierarchical HIT (HHIT) Suite ID:
       This 8-bit valued subregistry is a superset of the 4/8-bit "HIT
       Suite ID" subregistry of the "Host Identity Protocol (HIP)
       Parameters" registry in [IANA-HIP].  Future additions to this
       subregistry are to be made through IETF Review (Section 4.8 of
       [RFC8126]).  The following HHIT Suite IDs are defined:

         HHIT Suite          Value    Reference
         RESERVED            0
         RSA,DSA/SHA-256     1    [RFC7401]
         ECDSA/SHA-384       2    [RFC7401]
         ECDSA_LOW/SHA-1     3    [RFC7401]
         EdDSA/cSHAKE128     TBD3 (suggested value 5)   [This]
         HDA Private Use 1   TBD4 (suggested value 254)   [This]
         HDA Private Use 2   TBD5 (suggested value 255)   [This]


       The HHIT Suite ID values 1 - 31 are reserved for IDs that MUST be
       replicated as HIT Suite IDs (Section 8.4) as is TBD3 here. Higher
       values (32 - 255) are for those Suite IDs that need not or cannot
       be accommodated as a HIT Suite ID.


8.3.  IANA CGA Registry Update

    This document requests that this document be added to the reference
    field for the "CGA Extension Type Tags" registry [IANA-CGA], where
    IANA registers the following Context ID:

    Context ID:
       The Context ID (Section 3) shares the namespace introduced for CGA
       Type Tags.  Defining new Context IDs follow the rules in Section 8
       of [RFC3972]:

       Context ID :=  0x00B5 A69C 795D F5D5 F008 7F56 843F 2C40 [This]


8.4.  IANA HIP Registry Updates

    This document requests IANA to make the following changes to the IANA
    "Host Identity Protocol (HIP) Parameters" [IANA-HIP] registry:

    Host ID:
       This document defines the new EdDSA Host ID with value TBD1
       (suggested: 13) (Section 3.4.1) in the "HI Algorithm" subregistry
       of the "Host Identity Protocol (HIP) Parameters" registry.

         Algorithm
         profile    Value    Reference

         EdDSA       TBD1 (suggested value 13) [RFC8032]


    EdDSA Curve Label:
       This document specifies a new algorithm-specific subregistry named
       "EdDSA Curve Label".  The values for this subregistry are defined
       in Section 3.4.1.1.  Future additions to this subregistry are to
       be made through IETF Review (Section 4.8 of [RFC8126]).

         Algorithm    Curve            Values    Reference

         EdDSA        RESERVED         0
         EdDSA        EdDSA25519       1    [RFC8032]
         EdDSA        EdDSA25519ph     2    [RFC8032]
         EdDSA        EdDSA448         3    [RFC8032]
         EdDSA        EdDSA448ph       4    [RFC8032]
                                       5-65535 Unassigned

    HIT Suite ID:
       This document defines the new HIT Suite of EdDSA/cSHAKE with value
       TBD3 (suggested: 5) (Section 3.4.2) in the "HIT Suite ID"
       subregistry of the "Host Identity Protocol (HIP) Parameters"
       registry.

         HIT Suite        Value    Reference
         EdDSA/cSHAKE128  TBD3 (suggested value 5)   [This]


       The HIT Suite ID 4-bit values 1 - 15 and 8-bit values 0x00 - 0x0F
       MUST be replicated as HHIT Suite IDs (Section 8.2) as is TBD3
       here.

8.5.  IANA IPSECKEY Registry Update

    This document requests IANA to make the following change to the
    "IPSECKEY Resource Record Parameters" [IANA-IPSECKEY] registry:

    IPSECKEY:
       This document defines the new IPSECKEY value TBD2 (suggested: 4)
       (Section 3.4.1.2) in the "Algorithm Type Field" subregistry of the
       "IPSECKEY Resource Record Parameters" registry.

       Value  Description    Reference

       TBD2 (suggested value 4)   [This]
              An EdDSA key is present, in the format defined in [RFC8080]



> Thanks,
>
> Amanda
>
> *From: *iesg <[e-mail]> on behalf of Robert Moskowitz 
> <[e-mail]>
> *Date: *Thursday, July 14, 2022 at 10:20 AM
> *To: *"Murray S. Kucherawy" <[e-mail]>
> *Cc: *The IESG <[e-mail]>, "[e-mail]" 
> <[e-mail]>, "[e-mail]" 
> <[e-mail]>, "[e-mail]" <[e-mail]>, 
> "[e-mail]" <[e-mail]>, Amanda 
> Baber <[e-mail]>
> *Subject: *[Ext] Re: Murray Kucherawy's No Objection on 
> draft-ietf-drip-rid-30: (with COMMENT)
>
> I added IANA, as this is an IANA issue.
>
> I will address the non-IANA items in a separate email.
>
> On 7/14/22 03:10, Murray S. Kucherawy wrote:
>
>     On Wed, Jul 13, 2022 at 12:58 PM Robert Moskowitz
>     <[e-mail]> wrote:
>
>     > Sections 8.3 and 8.5 should be explicit that the Reference for
>     the new entry is
>
>         > this document.  Even though that's obvious, the instructions
>         should be
>         > complete.  (Note, for example, that they're correctly
>         different in Section 8.4.)
>
>         Please provide text guidance.  I have not done an IANA
>         Considerations in
>         over 10 years and they are a lot more specific now.  I should
>         point out
>         that IANA review has not requested any additions here.
>
>     In your Section 8.3, this is the registry you're updating:
>
>     https://www.iana.org/assignments/cga-message-types/cga-message-types.xhtml
>
>     Note that there's a "Reference" column.  However, in your
>     document, that column is not specified.  What's IANA supposed to
>     put there?
>
>     I realize that the answer is somewhat obvious, but I think it's
>     typical to require that the update be fully specified in the
>     document just so there's no question later.
>
>
> First I want to point out there were there are new registries defined 
> in sec 8, and have values from earlier work, those RFCs are referenced.
>
> But where these are new values in both old and new registries, I have 
> left out referencing something like:
>
> [this RFC]
>
> I have looked and not found any RFC that does this, nor has IANA 
> commented in prior reviews that such text is called for.
>
> Again, I have not done an IANA considerations section for over a 
> decade.  Any more current work I co-authored it was someone else's job 
> for that section.  But I have not found any following this approach.
>
> Amanda,
>
> How does IANA what this handled?
>
> Bob
>
>
>

-- 
Standard Robert Moskowitz
Owner
HTT Consulting
C:248-219-2059
F:248-968-2824
E:[e-mail]

There's no limit to what can be accomplished if it doesn't matter who 
gets the credit