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

[Andy Bierman <[e-mail]>]

On Tue, Mar 5, 2024 at 1:39 AM 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.
>
>
+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, [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
>