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

[[e-mail]]

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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> >
> 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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> 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.