Reviewing the l2nm module, I made the comments below which are perhaps of a more general application.
Looking at the tree diagram snippet, I see a seamless list of nodes in e.g. section 7.3. In fact, there are four 'uses' tucked away in there, three of them imports from the module vpn-common, so it is some effort to track down the source YANG statements that the tree diagram references I see no way of telling from the tree diagram what is 'native' and what is the result of 'uses'. Second, again using section 7.3 as an exemplar, there is text giving description and usage of key nodes for both native and imported nodes. The imported nodes also have their own description and usage in RFC9181 where vpn-common is defined. It seems to me that the descriptions for the common module in RFC9181 are rather thin so while having a more comprehensive description in the l2vpn I-D may help, it may also confuse if the two are not in line; and of course, the author of another I-D which imports vpn-common may decide to create their own and different descriptions. As ever, I am better at problems than solutions but it seems that when we create a separate RFC for a common module, then the descriptions in the YANG need to be really comprehensive, more so than when the descriptions can be amplified by the text in the RFC in which a module appears, be it common or no. Tom Petch From: OPSAWG <[email protected]> on behalf of tom petch <[email protected]> Sent: 12 May 2022 17:08 This I-D imports and uses a number of YANG grouping from RFC9181, ietf-vpn-common. This fact gets a mention in section 5 but you would not know this from the descriptive section, section 7, where imports and native YANG are seamlessly merged. This I-D contains text on the meaning of the nodes, their usage and such like regardless of where they are defined. Looking at RFC9181 it is rather short, or very short, on such text (e.g. in vpn-profile-cfg, vpn-description). It would seem then that each document that imports RFC9181 will have to incorporate its own, potentially divergent, text on the meaning of the nodes and their usage while if ietf-vpn-common gets updated, the ripples may spread. This seems unfortunate. Tom Petch On 29/04/2022 15:40, The IESG wrote: > > The IESG has received a request from the Operations and Management Area > Working Group WG (opsawg) to consider the following document: - 'A YANG > Network Data Model for Layer 2 VPNs' > <draft-ietf-opsawg-l2nm-15.txt> as Proposed Standard > o _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
