I guess I still fail to understand what the issue is. I do not understand what needs changes and why or why "ownership" by IANA would change any guidelines.
/js On Fri, Mar 25, 2022 at 08:40:30AM +0000, mohamed.boucad...@orange.com wrote: > Re-, > > Please see inline. > > Cheers, > Med > > > -----Message d'origine----- > > De : Jürgen Schönwälder <j.schoenwael...@jacobs-university.de> > > Envoyé : vendredi 25 mars 2022 09:01 > > À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com> > > Cc : Qin Wu <bill...@huawei.com>; netmod@ietf.org > > Objet : Re: [netmod] TR: New Version Notification for draft-boucadair- > > netmod-iana-registries-00.txt > > > > On Fri, Mar 25, 2022 at 07:49:42AM +0000, mohamed.boucad...@orange.com > > wrote: > > > > > > Anyway, my main point is that I do not see that the extensibility > > > > implications of enumerations and identities change just because a > > > > module is owned by IANA. Allocating a new enum requires an update of > > > > the module defining the enum, i.e., allocation is centralized. > > > > > > [Med] The point is that adding a new enum is possible. The > > extensibility concern with enums we used to have for non IANA-maintained > > modules does not apply. I agree that identities are more flexible. > > That’s why the suggested text requires a justification text to motivate > > the design choice. > > > > > > > Adding an enum is always possible, regardless who "owns" the module. > > Yes, it is process wise easier to add an enum to an IANA maintained > > module than an IETF maintained module. > > [Med] Glad to see that we agree on this. This is even important here as we > are trying to keep IANA as the authoritative source for modules that echo an > existing registry + generalize the use of yang as another "Available Format" > for the registries. > > But this has nothing to do with > > the text in the RFC you believe needs an update. > > [Med] I trust what you are saying but I'm still not sure everyone has this > interpretation. > > We may get rid of the update if we also think this falls under this text: > > 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. > > but "and" is problematic. "or" would better fit what we are discussing here. > > > > > /js > > > > -- > > Jürgen Schönwälder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 <https://www.jacobs-university.de/> > > _________________________________________________________________________________________________________________________ > > 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. > -- Jürgen Schönwälder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <https://www.jacobs-university.de/> _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
