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

[Andy Bierman <[e-mail]>]

On Tue, Mar 12, 2024 at 6:58 AM Jan Lindblad <[e-mail]> 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
> <[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] 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%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: [phone]         Campus Ring 1 | 28759 Bremen | Germany
>
> _______________________________________________
> 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%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]
> https://www.ietf.org/mailman/listinfo/netmod
>
>
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod
>