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

[[e-mail]]

Hi Kent,

Please see inline.

Cheers,
Med

De : Kent Watsen <[e-mail]>
Envoyé : jeudi 8 février 2024 16:55
À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>
Cc : [e-mail]
Objet : Re: [netmod] rfc8407bis IANA guidance (enums vs identities)

Hi Mohamad,

Thanks for the response.
Some thoughts below.

K



On Feb 8, 2024, at 3:36 AM, [e-mail]<mailto:[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?

[Med] No. These are examples of the use of enums or identitirefs.

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.

[Med] Works for me. Updated. Thanks.


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.
[Med] There is no normative language in this text. I do still think this text is useful as it to provide an example of a specific context.

 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.

[Med] I merged this change with the other comment I received offline and went for the following:

NEW:

   If distributed extensibility or hierarchical organization of
   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

____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.