Re: [netmod] On prefixes again RE: IETF#119 I-D Status: draft-ietf-netmod-rfc8407bis

[[e-mail]]

Re-,

I’m not sure to agree with your last statement, Andy.

The reality is that the OLD reco is inducing many cycles and waste of time for no obvious technical reason:  see an example here https://mailarchive.ietf.org/arch/msg/teas/eknpfAZIb9gX7GvUN1UoByCf5e4/

Let’s save the authors time with a clear guidance:

  *   Pick ietf- or iana- as a function of the module
  *   Use something meaningful, but preferably not too long

Cheers,
Med

De : Andy Bierman <[e-mail]>
Envoyé : vendredi 15 mars 2024 18:01
À : Jürgen Schönwälder <[e-mail]>; Andy Bierman <[e-mail]>; BOUCADAIR Mohamed INNOV/NET <[e-mail]>; [e-mail]
Objet : Re: [netmod] On prefixes again RE: IETF#119 I-D Status: draft-ietf-netmod-rfc8407bis



On Fri, Mar 15, 2024 at 9:42 AM Jürgen Schönwälder <[e-mail]<mailto:[e-mail]>> wrote:
Yes, for long XPath expressions, one likes to have short prefixes, the
shorter the better. In other contexts, such as type definitions, one
may want to use longer prefixes providing more context. It seems you
can't have both at the same time. Given this inherent conflict, I am
not sure that generally pushing for longer prefixes is a good thing.

For modules with long XPath expressions, an author may consider to go
for one character local prefixes even if they require to lookup their
meaning in the imports (or people have modern editors that can
dynamically show an expansion) because mutli-line XPath expressions
with lots of repetitive substrings are pretty bad for human eyes.

Short is OK if the prefix is familiar to the reader. Like "if".
What if the writer wanted a, b, c, d, etc? Shortt but not meaningful.
It is a judgment call every time, too complex for a guideline.

The guideline only mentions short so the prefix will not conflict and the import-stmt in
other modules will not need a different prefix.  This is only for reader familiarity, since the
YANG compiler does not care which prefix is used.

The naming convention already established is that the SDO prefix (ietf or iana) is not used.
It would not help readers to change it now.



/js

Andy


On Fri, Mar 15, 2024 at 08:22:03AM -0700, Andy Bierman wrote:
> On Fri, Mar 15, 2024 at 7:24 AM Jürgen Schönwälder
> <[e-mail]<mailto:[e-mail]>> wrote:
>
> > I wonder which problem we are solving with adding more little rules.
> > Perhaps a future version of YANG will do away with prefixes but until
> > this happens, I do not think we need to add more rules about how to
> > choose prefixes. The original intend was that they are short to keep
> > YANG snippets concise and easy to read.
> >
> >
>
> This is the IETF Coding Conventions document, not the YANG specification.
> Naming conventions are CLRs but often with some benefits.
>
> What problems?
>
> 1) If there are multiple modules used in imports then the reader must be
> able to
> easily tell the prefixes apart.  If prefixes are too short and not
> meaningful, this task
> gets more difficult.  I find myself constantly going back to the imports to
> make sure
> I am matching the prefix to the correct module.
>
> 2) If there are complex XPath expressions then prefixes that are too long
> make the
> expression unreadable, especially as it is chopped into "string" +
> "string"  format
> to fit into 72 character lines. If prefixes are too short then back to
> problem (1).
>
> 3)  It is becoming more common to have vendor modules import modules from
> multiple SDOs.
> Prefix naming conventions are already the BCP everywhere but the IETF.
>
> Is it too late to start for IETF? There are many modules already with no
> naming consistency,
> so this would only affect new modules. There will never be consistent
> naming of prefixes
> so it may not be worth the change now.
>
>
>
> /js
> >
>
>

--
Jürgen Schönwälder              Constructor University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
____________________________________________________________________________________________________________
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.