On Thu, Mar 18, 2021 at 10:41 AM Don Fedyk <[email protected]> wrote: > So you are saying I should beat up on the tool chain people that have not > followed the spec. I tried that already 😊 , but since I can redefine the > prefixes locally as a workaround, and I couldn’t convince them it was an > issue, it fell by the wayside with one tool so far. > > > > If the spec was more precise it would settle the arguments. >
I think it is unfortunate that the IETF wanted so many clever little rules for the creation of YANG modules. Also unfortunate that RFC 2119 terms in the style guide get confused with similar terms in the YANG RFC. RFC 8407 is normative for IETF YANG module authors. RFC 7950 is for YANG module tool-makers. People should know the difference, especially since 8407 only applies to the IETF, not other organizations. Regards, > > Don > Andy > > > *From:* Andy Bierman <[email protected]> > *Sent:* Thursday, March 18, 2021 1:23 PM > *To:* Don Fedyk <[email protected]> > *Cc:* tom petch <[email protected]>; Mahesh Jethanandani < > [email protected]>; Juergen Schoenwaelder < > [email protected]>; [email protected] > *Subject:* Re: [netmod] Use of prefixes in YANG models > > > > > > > > On Thu, Mar 18, 2021 at 10:07 AM Don Fedyk <[email protected]> wrote: > > Clarity and consistency would help. > > Many of the supporting tool chains are picky about prefixes. IE they must > be the same as in the definition file. I have a case where yanglint wants > "local prefixes or derived-from(-or-self) construct" for an local identity > in an xpath statement. (either remedy seems to work.) I argued for the > prefixes in but others argue they are not necessary but I cannot validate > without them. > > > > > > The tool makers should understand that YANG prefixes are not required to > be unique. > > It is understood that short character sequences have a high probability of > duplication. > > So what if the server wants to support 2 modules with the same prefix > defined in the YANG module? > > Is it not clear that the ENTIRE point of having the prefix-stmt in the > import-stmt is > > because the imported modules may have prefixes that collide? > > > > > > > > Andy > > > > "not(derived-from(../../bridge-type,'two-port-mac-relay-bridge'))" works > (prefix/no prefix) > But "../../bridge-type != 'dot1q:two-port-mac-relay-bridge' works too. > > Thanks > Don > > > > -----Original Message----- > From: netmod <[email protected]> On Behalf Of tom petch > Sent: Thursday, March 18, 2021 7:50 AM > To: Mahesh Jethanandani <[email protected]>; Juergen Schoenwaelder < > [email protected]> > Cc: [email protected] > Subject: Re: [netmod] Use of prefixes in YANG models > > From: netmod <[email protected]> on behalf of Juergen Schoenwaelder > <[email protected]> > Sent: 18 March 2021 08:05 > > We often do not do a good job in distinguishing technical requirements > from usage guidelines. (And RFC 2119 keywords make things worse.) > > As far as I recall, the intent of the RFC 8407 text was to say that it is > helpful for _humans_ to always use 'if:name' when you refer to the leaf > 'name' defined in 'ietf-interfaces' or 'yang:date-and-time' when you refer > to 'date-and-time' defined in 'ietf-yang-types'. > > I believe we agreed that module authors assigning a prefix different from > the default prefix during an import should have either technical reasons > for doing so (resolving prefixes clashes) or some other good reason to > depart from the general guideline aiming to reduce human confusion. > > <tp> > To make an abstract concept concrete, draft-ietf-babel-yang-model imports > yang types from RFC6991 and gives it the prefix yt: as in yt:date-and-time > or yt:counter32. An early YANG Doctor review by Radek did not comment on > this aspect of the I-D. More recently, I have. > > Tom Petch > > > > /js (who stopped believing that RFC 2119 keywords are helpful years ago) > > On Wed, Mar 17, 2021 at 05:03:11PM -0700, Mahesh Jethanandani wrote: > > I have seen the debate on the use of prefixes in YANG models, specially > as it relates to their use when importing a model. I think it would nice to > be clear on what is required, what is nice, and what is not ok to do. I do > not want to confuse this discussion with the length of the prefix, which I > believe is somewhat related but not the same discussion. > > > > RFC 7950 says: > > > > All prefixes, including the prefix for the module itself, MUST be > > unique within the module or submodule. > > > > This is a requirement, as is clear by the MUST. > > > > Then RFC 7950 says: > > > > To > > improve readability of YANG modules, the prefix defined by a module > > SHOULD be used when the module is imported, unless there is a > > conflict. > > > > It also says: > > > > When used inside the "import" statement, the "prefix" statement > > defines the prefix to be used when accessing definitions inside the > > imported module. > > > > Clearly, the scope of the "prefix" statement used with an "import" > statement is limited to the module where it is imported and does not impact > the imported module. As such, and because it is a SHOULD and not a MUST, > this is a "nice to have" without conflicts, but one would not be wrong > using a different prefix from the one defined in the imported module. Add > to this, most tools, e.g. pyang or yanglint do not complain if you do > define a different prefix when there are no conflicts. I have not seen a > problem in the implementation of the module when the prefix is different. > > > > RFC 8407 confuses this whole situation by saying: > > > > The proper module prefix MUST be used for all identifiers imported > > from other modules. > > > > which as written is true for identifiers (but not for other types of > imports??). Besides, it does not define what is "proper module prefix". In > the absence of a proper definition, one should follow what RFC 7950 says. > > > > Comments? > > > > Mahesh Jethanandani > > [email protected] > > > > > > > > > > > > > _______________________________________________ > > netmod mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/netmod > > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 <https://www.jacobs-university.de/> > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod > >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
