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. Regards, Don 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]<mailto:[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]<mailto:[email protected]>> On Behalf Of tom petch Sent: Thursday, March 18, 2021 7:50 AM To: Mahesh Jethanandani <[email protected]<mailto:[email protected]>>; Juergen Schoenwaelder <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]> Subject: Re: [netmod] Use of prefixes in YANG models From: netmod <[email protected]<mailto:[email protected]>> on behalf of Juergen Schoenwaelder <[email protected]<mailto:[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]<mailto:[email protected]> > > > > > > _______________________________________________ > netmod mailing list > [email protected]<mailto:[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]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
