Re: [netmod] On prefixes RE: Next steps for draft-ietf-netmod-rfc8407bis

[Jan Lindblad <[e-mail]>]

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?

Best Regards,
/jan



> On 5 Mar 2024, at 10:38, Jürgen Schönwälder <[e-mail]> 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, [e-mail] <mailto:[e-mail]> wrote:
>> Hi Jürgen,
>> Please see inline.
>> Cheers,
>> Med
>>> -----Message d'origine-----
>>> De : netmod <[e-mail]> De la part de Jürgen Schönwälder
>>> Envoyé : lundi 4 mars 2024 20:44
>>> À : [e-mail]
>>> 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, [e-mail] 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
>>>> [e-mail]
>>>> 
>>> 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 <http://ietf.org/>%2Fmailman%2Flistinfo%2Fnetmod&data=05%7C02%7Cmohamed.boucadai
>>>> 
>>> r%40orange.com <http://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: [phone]         Campus Ring 1 | 28759 Bremen | Germany
>>> 
>>> _______________________________________________
>>> netmod mailing list
>>> [e-mail] <mailto:[e-mail]>
>>> 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: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> 
> _______________________________________________
> netmod mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/netmod