On Tue, Mar 5, 2024 at 1:39 AM Jürgen Schönwälder <jschoenwaelder@constructor.university> wrote:
> Hi Med, > > I believe it is a misconception that text not written in capital letters > is not normative. I also believe we need _guidelines_ on the choice of > identifiers like prefixes and not hard rules. > > Prefixes do not have to be unique. It is nice if they are for widely > used modules, but we are on a slippery path if we think of them as > something that should be unique. Then they get long or clumsy or both > (or worse we encourage a competition to allocate nice short prefixes). > Yes, the original language is vague, on purpose. I guess I miss which > problem is solved by requiring uniqueness that practically can't be > ensured and is technically also not necessary. > > +1 The prefixes are local to the module or submodule. We should not pretend they are global identifiers like the module name. > /js > Andy > > On 05.03.24 09:58, mohamed.boucad...@orange.com wrote: > > Hi Jürgen, > > > > Please see inline. > > > > Cheers, > > Med > > > >> -----Message d'origine----- > >> De : netmod <netmod-boun...@ietf.org> De la part de Jürgen Schönwälder > >> Envoyé : lundi 4 mars 2024 20:44 > >> À : netmod@ietf.org > >> Objet : Re: [netmod] On prefixes RE: Next steps for draft-ietf-netmod- > >> rfc8407bis > >> > >> Hi, > >> > >> the statement "should be selected carefully to be unique" is > >> impossible to implement given an open ended set of YANG modules. > > > > [Med] Hmm, but there is no normative text in that sentence. What > concretely needs to be followed is indicated in the sentence right after > (SHOULD NOT); which is inherited from 8407. > > > > Isn't "selected carefully to be unique" echoing the spirit of this text > from RFC7950? > > > > Developers of YANG modules and submodules are RECOMMENDED to choose > > names for their modules that will have a low probability of colliding > > with standard or other enterprise modules, e.g., by using the > > enterprise or organization name as a prefix for the module name. > > Within a server, all module names MUST be unique. > > > >> If this section only applies to IETF modules (I thought it is more > >> general) and IANA never makes a mistake and we accept that prefixes > >> get longer or cryptic over time, then this may be possible to > >> implement, but I am not sure this is actually desirable. > >> > >> The original wording "likely to be unique" was selected carefully, it > >> conveys the message that prefixes can't be assumed to be unique. > > > > [Med] "SHOULD ...likely" is really ambiguous as a reco if the text does > not explain when it won't be > > > >> Perhaps it should be even further watered down to "likely to be unique > >> in a certain usage context". > > > > [Med] What is a usage context? how that usage context is known? How a > module is concretely bound to it? Etc. IMO, this triggers more questions > that it clarifies the guidance. > > > >> > >> I believe the original wording was good enough and does not need an > >> update. Every update, even if well intended, carries a risk to break > >> something that works. > >> > >> /js > >> > >> On 04.03.24 19:39, Randy Presuhn wrote: > >>> Hi - > >>> > >>> On 2024-03-04 12:51 AM, mohamed.boucad...@orange.com wrote: > >>>> Hi Jan, > >>>> > >>>> I went so far with the following: > >>>> > >>>> OLD: > >>>> > >>>> Prefix values SHOULD be short but are also likely to be unique. > >>>> > >>>> Prefix values SHOULD NOT conflict with known modules that have > >>>> been > >>>> > >>>> previously published. > >>>> > >>>> NEW: > >>>> > >>>> Prefix values should be selected carefully to be unique, and > >>>> ideally > >>>> > >>>> not too long. Specifically, prefix values SHOULD NOT conflict > >>>> with > >>>> > >>>> known modules that have been previously published. > >>>> > >>>> I'm having troubles with the normative language here. If we > >> maintain > >>>> the two sentences, the second SHOULD is sufficient for the > >> uniqueness > >>>> IMO. > >>>> > >>>> Also, as per RFC2119, we should clarify when the SHOULD NOT can be > >>>> safely ignored: > >>>> > >>>> SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean > >>>> that > >>>> > >>>> there may exist valid reasons in particular circumstances when > >>>> the > >>>> > >>>> particular behavior is acceptable or even useful, but the full > >>>> > >>>> implications should be understood and the case carefully > >> weighed > >>>> > >>>> before implementing any behavior described with this label. > >>>> > >>>> An obvious case is an updated version of a published version. > >>> ... > >>> > >>> In dealing with SHOULD statements in RFCs, both as an implementor > >> and > >>> as a specification writer, I find it useful to re-phrase (at least > >> in > >>> my head) a "SHOULD NOT X" as "MUST be able to cope with others doing > >>> X, even if it does not itself do X." > >>> > >>> A "SHOULD NOT X" in a specification does NOT relieve implementations > >>> of the duty to work correctly when X happens, because "SHOULD NOT X" > >>> means that X is indeed permitted, even if discouraged. If X causes > >> a > >>> an implementation pair to violate protocol or miscommunicate (e.g. > >>> referencing the wrong syntax or semantics) at some level, then it > >>> really needs to be a "MUST NOT". > >>> > >>> But this is an old, old argument, and gliding along with "likely > >>> uniqueness" rather than uniqueness has been a longstanding > >> bug/feature > >>> of netmod. I'd just like to see a bit more guidance for > >> implementors > >>> so their products don't crash and burn when they do encounter > >>> "duplicate" prefixes in the wild. > >>> > >>> Randy > >>> > >>> _______________________________________________ > >>> netmod mailing list > >>> netmod@ietf.org > >>> > >> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww%2F&data=05%7C02%7Cjschoenwae%40constructor.university%7C8d19bba074754de88af008dc3cf268cf%7Cf78e973e5c0b4ab8bbd79887c95a8ebd%7C0%7C0%7C638452259052898639%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=kMRfC9Cuik8lhqIMXHI6K4NCZRjHUF1mORjOdUUFAvs%3D&reserved=0 > . > >>> > >> ietf.org%2Fmailman%2Flistinfo%2Fnetmod&data=05%7C02%7Cmohamed.boucadai > >>> > >> r%40orange.com%7C3b125a3e5a83426657e108dc3c8376a4%7C90c7a20af34b40bfbc > >>> > >> 48b9253b6f5d20%7C0%7C0%7C638451782524628913%7CUnknown%7CTWFpbGZsb3d8ey > >>> > >> JWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7 > >>> > >> C%7C%7C&sdata=fkyIdrLqhqIkfdivCbWnetivTNNcpW07OepfdUat3mo%3D&reserved= > >>> 0 > >> > >> -- > >> Jürgen Schönwälder Constructor University Bremen gGmbH > >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > >> > >> _______________________________________________ > >> netmod mailing list > >> netmod@ietf.org > >> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww%2F&data=05%7C02%7Cjschoenwae%40constructor.university%7C8d19bba074754de88af008dc3cf268cf%7Cf78e973e5c0b4ab8bbd79887c95a8ebd%7C0%7C0%7C638452259052906113%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=HZTNCsEkHPGu9IYUwl%2BIYr91dPNDz32KGguybeo9wSg%3D&reserved=0 > . > >> ietf.org%2Fmailman%2Flistinfo%2Fnetmod&data=05%7C02%7Cmohamed.boucadai > >> r%40orange.com%7C3b125a3e5a83426657e108dc3c8376a4%7C90c7a20af34b40bfbc > >> 48b9253b6f5d20%7C0%7C0%7C638451782524636700%7CUnknown%7CTWFpbGZsb3d8ey > >> JWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7 > >> C%7C%7C&sdata=AEiqw14B6zxw14njEnUOEkEEzKdTmOc9%2BOTO5l2u8o8%3D&reserve > >> d=0 > > > ____________________________________________________________________________________________________________ > > 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 Constructor University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
