Re: [netmod] rfc8407bis IANA guidance (enums vs identities)

[Kent Watsen <[e-mail]>]

Hi Mohamad,

Thanks for the response.
Some thoughts below.

K


> On Feb 8, 2024, at 3:36 AM, [e-mail] wrote:
> 
> Hi Kent, all,
>  
> Let’s me also provide some background and explain why we are not using any normative language for enum vs identities. We used to have this text in early versions:
>  
>    This recommendation takes precedence over the behavior in
>    Section 4.11.1 of [RFC8407] for IANA-maintained modules because the
>    extensibility concern is not applicable for such modules.
>  
> The reco that the text refers to is the following one (RFC8407):
>  
>    If extensibility of enumerated values is required, then the
>    "identityref" data type SHOULD be used instead of an enumeration or
>    other built-in type.
>  
> However, Juergen convinced me that we don’t need an update as we do already have the following:
>  
>    If the set of values is fixed and the data type contents are
>    controlled by a single naming authority, then an enumeration data
>    type SHOULD be used.
>  
> I think that we need to better convey this in the draft, while avoiding redundant normative language.

+1


> (1)
>  
> OLD:
>    If the set of values is fixed and the data type contents are
>    controlled by a single naming authority, then an enumeration data
>    type SHOULD be used.
>  
> NEW:
>    If the set of values is fixed and the data type contents are
>    controlled by a single naming authority (e.g., IANA), then an enumeration data
>    type SHOULD be used.

Good.


> (2)
>  
> OLD:
>    An IANA-maintained module may use identities (e.g., [RFC8675]) or
>    enumerations (e.g., [RFC9108]).  The decision about which type to use
>    is left to the module designers and should be made based upon
>    specifics related to the intended use of the IANA-maintained module.
>    For example, identities are useful if the registry entries are
>    organized hierarchically, possibly including multiple inheritances.
>    It is RECOMMENDED that the reasoning for the design choice is
>    documented in the companion specification that registers an IANA-
>    maintained module.
>  
> NEW:
>    An IANA-maintained module may use the "identityref" data type (e.g.,
>    [RFC8675]) or an enumeration data type (e.g., [RFC9108]).  Consistent
>    with Section 4.11.1, the default recommendation is to use an
>    enumeration data type.  The decision about which type to use is left
>    to the module designers and should be made based upon specifics
>    related to the intended use of the IANA-maintained module.  For
>    example, identities are useful if the registry entries are organized
>    hierarchically, possibly including multiple inheritances.  It is
>    RECOMMENDED that the reasoning for the design choice is documented in
>    the companion specification that registers an IANA-maintained module.

Should both the RFC8675 and RFC9108 refs point to sections in RFC 7950?


Regarding new text:

   Consistent with Section 4.11.1, the default recommendation
   is to use an enumeration data type.

Might it be better to say something like the following?

   Please see Section 4.11.1 for guidance on which data type to use.



Regarding existing text:

   The decision about which type to use is left
   to the module designers and should be made based upon specifics
   related to the intended use of the IANA-maintained module.  For
   example, identities are useful if the registry entries are organized
   hierarchically, possibly including multiple inheritances.

I think that this introduces redundant normative language.  I believe that this text can be removed, if the following change is made to Section 4.11.1:

OLD:
   If extensibility of enumerated values is required, then the
   "identityref" data type SHOULD be used instead of an enumeration or
   other built-in type.

NEW:
   If extensibility or hierarchical organization of the enumerated values is required, then the
   "identityref" data type SHOULD be used instead of an enumeration or
   other built-in type.



>  
> The full changes can be better tracker here: https://author-tools.ietf.org/api/iddiff?url_1=https://boucadair.github.io/rfc8407bis/draft-ietf-netmod-rfc8407bis.txt&url_2=https://boucadair.github.io/rfc8407bis/enum-vs-identities/draft-ietf-netmod-rfc8407bis.txt
>  
>  
> Cheers,
> Med


Thanks,
Kent