Hi Acee, all, Andy clarified the intent.
FYI, as you can see at [1], we also considered the following to avoid the ambiguity in that sentence: OLD: .. fixed ** and ** the data type contents NEW: … fixed ** or ** the data type contents But I was convinced by the WG that we don’t need so [2]. Cheers, Med (no AD Fez) [1] https://mailarchive.ietf.org/arch/msg/netmod/CJCt9OSRDoETGCGL9MbDcXpuKFU/ [2] https://mailarchive.ietf.org/arch/msg/netmod/NsMMTesk8CGH9RAG95_Vlug9PQQ/ De : Andy Bierman <[email protected]> Envoyé : jeudi 16 avril 2026 22:43 À : Acee Lindem <[email protected]> Cc : BOUCADAIR Mohamed INNOV/NET <[email protected]>; YANG Doctors <[email protected]>; NetMod WG <[email protected]> Objet : Re: [yang-doctors] IANA Maintained Modules - Usage Enumerations vs Identities On Thu, Apr 16, 2026 at 1:34 PM Acee Lindem <[email protected]<mailto:[email protected]>> wrote: Hi Med, YANG Doctors, Section 4.30.2 "Guidelines for IANA-Maintained YANG Modules" references section 4.11.1 to determine whether to use enumerations or identities. The guidance in section 4.11.1 of RFC 9907 is somewhat contradictory (at least to me) for enumerations vs identifies. 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. If "the set of values is fixed", why would you have an IANA registry for a set of values that can't be changed? It makes no sense to have an IANA registry if the set of values isn't extensible. Hence, it seems to me that identities are the only viable option. Also, this is the only choice that is backward compatible based on RFC 7950. For an enumeration, a new revision of the YANG module defining it is required to add values. For identities, any module can add new values (in the registry or not). So the set of values is fixed for that revision. New values can be added in new revisions. Thanks, Acee Andy _______________________________________________ yang-doctors mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]> ____________________________________________________________________________________________________________ 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 -- [email protected] To unsubscribe send an email to [email protected]
