> On Mar 15, 2024, at 13:26, mohamed.boucad...@orange.com 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 <a...@yumaworks.com> > Envoyé : vendredi 15 mars 2024 18:01 > À : Jürgen Schönwälder <jschoenwaelder@constructor.university>; Andy Bierman > <a...@yumaworks.com>; BOUCADAIR Mohamed INNOV/NET > <mohamed.boucad...@orange.com>; netmod@ietf.org > 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 > <jschoenwaelder@constructor.university> 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 > > <jschoenwaelder@constructor.university> 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: +49 421 200 3587 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 > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
