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

[[e-mail]]

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)

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.

(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.

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

De : netmod <[e-mail]> De la part de Kent Watsen
Envoyé : mercredi 7 février 2024 18:29
À : [e-mail]
Objet : [netmod] rfc8407bis IANA guidance (enums vs identities)

Authors, WG,

Following is a comment on Section 4.30.2.
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc8407bis-06#section-4.30.2

The text says:

====START====
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. For example, [RFC9244] defines an IANA-maintained module that uses enumerations for the following reason:

              "The DOTS telemetry module (Section 10.1) uses "enumerations" rather
              than "identities" to define units, samples, and intervals because
              otherwise the namespace identifier "ietf-dots-telemetry" must be
              included when a telemetry attribute is included (e.g., in a
              mitigation efficacy update).  The use of "identities" is thus
              suboptimal from a message compactness standpoint; one of the key
              requirements for DOTS messages."
====STOP====

I'm wondering if the guidance here cannot be stronger but, first, let me explain how I got here...

The "ssh-client-server" and the "tls-client-server" drafts both register IANA-maintained modules for IANA-registries (for crypto algorithms).  All of these IANA-modules use *identities* (not enums).

As I'm in the process of updating the two drafts to follow this template, I'm struggling with the above quoted text.  The reason for the struggle is because I'm having a hard time justifying these draft's current use of identities (yikes!)

The impetus for using identities in the first place was to enable new identities to be added by future modules (and nothing to do with multiple inheritances).   But when moving to the modules being IANA-maintained, it seems that we're simultaneously saying that new values should NOT be definable any other way.  That is, IETF would NOT publish new algorithms via new RFCs, when IANA is already publishing said algorithms via revisions of the base-module).

Perhaps it is theoretically possible that "proprietary" algorithms could be used in private deployments, but such would not foster the interoperability that IETF seeks.

Thus I am wondering if the guidance in this section should be stronger.  Should it actually say something like "Enumerations SHOULD be used unless the multiple-inheritance property of identities is needed."?

Thoughts?

Kent // contributor





____________________________________________________________________________________________________________
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.