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
