Re-,

I got an offline comment that there is an ambiguity about how to interpret  "If 
the set of values is fixed and" part of 4.11.1. In order to make the guidance 
more explicit, I propose we also add the following:

NEW:
   If the set of the data type contents requires some hierarchy or
   the allocation of the values is distributed, then an "identityref"
   data type SHOULD be used.

The full proposed changes can still be tracked using the same link below.

Cheers,
Med

De : BOUCADAIR Mohamed INNOV/NET
Envoyé : jeudi 8 février 2024 09:37
À : 'Kent Watsen' <kent+i...@watsen.net>; netmod@ietf.org
Objet : RE: [netmod] rfc8407bis IANA guidance (enums vs identities)

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 <netmod-boun...@ietf.org<mailto:netmod-boun...@ietf.org>> De la 
part de Kent Watsen
Envoyé : mercredi 7 février 2024 18:29
À : netmod@ietf.org<mailto:netmod@ietf.org>
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.
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Reply via email to