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

[Christian Hopps <[e-mail]>]

> On Mar 15, 2024, at 13:26, [e-mail] wrote:
> 
> 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 herehttps://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

I disagree with this guidance.

Thanks,
Chris.

>     • 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]> 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]> 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.
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod