On Tue, Mar 12, 2024 at 6:58 AM Jan Lindblad <j...@tail-f.com> wrote:
> Jürgen, > > You have been in the YANG circles long enough to remember the basic > tenets. > > YANG values the time and effort of the > readers of models above those of modules writers and YANG tool-chain > developers. > > In this spirit, it's obvious to me that choosing very short prefixes are > making it much harder for newcomers to parse YANG modules. They see "snmp:" > in one module and assumes it means the same as "snmp:" in another. Or > "if:", "mpls:" and a bunch of other convenient, short prefixes that I have > seen clashing in the real world. If we could foster the habit (best > practice) of at least adding a few characters to distinguish the publishing > organizations from each other, a lot would be won. "ietf-if:" and > "vendor-if:" would be a lot clearer. > > Then we have the other thing with RESTCONF where the module names are used > instead, which also causes some (unnecessary) confusion. If NETCONF and > RESTCONF could use the same "prefixes", things would be easier. In the > early days of programming (I mean in the 60's), FORTRAN programmers were > told to choose short function and variable names. This mindset has long > since been abandoned. Why is this still a good practice in YANG prefixes? > > I disagree with any changes to module prefixes. They are not confusing to anybody who bothers to learn a little about YANG. Long prefixes make YANG harder to read, not easier. Best Regards, > /jan > > > Andy > > On 5 Mar 2024, at 10:38, 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. > > /js > > 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 >
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
