tom petch <[email protected]> wrote: > From: Ladislav Lhotka <[email protected]> > Sent: 21 January 2021 12:58 > > Hi, > > in my YD review 4.5 years ago I actually recommended to use separate > modules: > > https://mailarchive.ietf.org/arch/msg/yang-doctors/GXHkGqZeIidMzpziZmK_ICrKPs4/ > > I think it is a matter of how much the different part overlap. For an > implementer, it seems to be easier to pick just the relevant parts, > provided they are easy to locate and identify. > > <tp> > Thank you for all the responses; I did look at the data tracker to see if > there had been any reviews, thinking that a previous review would be the > right place to start, and it said 'No reviews'! Perhaps these time out. > > I am not comfortable with the seven modules seeing four as better, a common > which is then augmented with server, relay, client, with the common > containing the role(s), whereas at present it is the three role modules that > contain the role which then drives having the three option modules so each > option module only imports one role module, and that is the bit I find most > awkward. > > How best to select the three roles? As I said upthread, I have seen the role > specified with features, with augment/when based on identityref (although not > with the three identity defined in the three role modules), presence > containers and so on (I have probably seen that and more in the history of > this I-D:-).
Is "role" the same as "node-type"? Each of these module define their own copy of a leaf called "dhcpv6-node-type". I am not sure I understand what purpose this leaf serves. It seems to me that it can be removed, but perhaps I am missing something. > > My instinct would be to put the three identity definitions into common with a > dhcpv6 container, which is then augmented by the three role modules, the YANG > 'when' referring to role leaf in the common. Any better ways? Why do augment at all? Why not just have a top-level container in each module; 'dhcpv6-client', 'dhcpv6-server' etc? /martin > > Tom Petch > > Lada > > On 21. 01. 21 13:42, Martin Björklund wrote: > > Hi, > > > > I think it is a matter of taste and perhaps future extensibility if > > this model is done as one or more YANG modules. It can certainly be > > done in one module, with features for client, server and relay, but it > > is also ok to have 3 modules for the different functions. And once > > you have these 3 modules, it is natural to have a "common" module, > > leading to 4 modules. In order to keep the number of modules down, > > perhaps the various -options modules could be merged into the other > > 3, probably with a feature each. > > > > One comment is that it might be wise to avoid having a rfc number in > > the identifier. What happens if/when that RFC is revised for any > > reason? > > > > > > /martin > > > > > > tom petch <[email protected]> wrote: > >> > >> Inline <tp> > >> > >> From: Andy Bierman <[email protected]> > >> Sent: 20 January 2021 18:32 > >> > >> On Wed, Jan 20, 2021 at 8:41 AM tom petch > >> <[email protected]<mailto:[email protected]>> wrote: > >> Juergen, Lada, Martin, Andy > >> > >> I wonder if one of you, or perhaps another on this list, would be willing > >> to give advice on the > >> structuring of the YANG module for DHCP. It has been revised and > >> restructured several times and, to me, is not progressing. > >> > >> It models three roles - client, server, relay - and a dozen optional > >> function which can appear in one or more roles. A node will likely have > >> only one role but may have many options. > >> > >> There are, at present, seven modules > >> server which defines a server identity based on common identity inter alia > >> relay which defines relay identity ditto > >> client which defines client identity ditto > >> server options which has groupings for each option for a server > >> client options which has groupings for each option for a relay > >> relay options which has groupings for each option for a client > >> common which defines the common identity inter alia > >> Since options are common across roles, some groupings are replicated in > >> the three options modules. Three separate option modules were created to > >> avoid problems with imports as Ian explains below. The I-D is > >> draft-ietf-dhc-dhcpv6-yang > >> > >> My take is that one module is best, using 'when' or if-feature to select, > >> which is what I see with OSPF, PCE, TCP, IGMP and almost everything else > >> but am struggling to convince others, especially the author Ian. [IF] in > >> the e-mail extract below > >> > >> I suggested asking a YANG Doctor, NOT to look at the module but rather to > >> advise on a structure given the requirements to which Ian said that he had > >> not had much joy with YANG Doctors. I append our most recent exchange in > >> which he responds to my query as to why there are seven modules; > >> formatting is a bit of a mess I am afraid. The posts are to the DHCWG > >> mail list. > >> > >> Any advice appreciated even if it is that Ian is on just the right track! > >> > >> > >> Either approach is valid so multi-module vs. single module w/ features is > >> more > >> of an overall system maintenance issue. 7 modules seems like a lot for > >> DHCP but > >> I have no objective criteria to back that up. > >> > >> There is some confusion about the import-stmt, which leads to many YANG > >> modules. > >> In compiler terms, importing a module merely makes the symbols available > >> for parsing in the current module. > >> The import-stmt implies no conformance requirements whatsoever. > >> Only statements that use the imported module can do that. > >> (So a server module importing a module that has client groupings is not > >> actually a problem.) > >> > >> <tp> > >> > >> Andy, Juergen, > >> > >> Thank you for the replies. What Ian said about the import is > >> > >>> [IF] The separation of the option modules came at a later stage based on > >>> import dependencies of a single options module. When the options module > >>> imports the client/server/relay modules so it can augment the relevant > >>> module based on identity, an implementation also needs to import these > >>> modules and will declare them in it’s capabilities as available even > >>> though it doesn’t implement them. Dividing the options modules avoids the > >>> need for deviations. > >> > >> <tp> that is, the prefix for dhcpv6-server is defined in the server module, > >> module ietf-dhcpv6-server { > >> ... > >> prefix "dhcpv6-server"; > >> ... > >> identity server { > >> base "dhcpv6-common:dhcpv6-node"; > >> description "DHCPv6 server identity."; } > >> leaf dhcpv6-node-type { > >> type identityref { > >> base "dhcpv6-common:dhcpv6-node"; } > >> description "Type for a DHCPv6 server."; } > >> > >> and the prefix for dhcpv6-relay in the relay module etc so having a single > >> module for options which needs to augment options to the server module > >> needs to import the server module so that the dhcpv6-server prefix is > >> defined, ditto relay and client so the single module for options then > >> imports server and relay and client modules. > >> > >> With three options modules, each only imports one of server, relay, client > >> but the groupings are then replicated across the three options modules. > >> > >> Logical if you agree with the initial premise (which I do not!). > >> > >> The seven YANG modules are all in the one I-D of 56pp with the tree > >> diagrams 12pp. > >> > >> Tom Petch > >> (on European time:-( > >> > >> YANG Conformance for a single module is better defined than for multiple > >> related modules. > >> The YANG Packages work could fix that someday. > >> > >> Tom Petch > >> > >> > >> Andy > >> > >> > >> On 19/01/2021 11:25, tom petch wrote: > >>> ________________________________________ > >>> From: dhcwg <[email protected]<mailto:[email protected]>> on > >>> behalf of [email protected]<mailto:[email protected]> > >>> <[email protected]<mailto:[email protected]>> > >>> Sent: 19 January 2021 07:37 > >>> > >>> Thanks for your comments. Please see inline below. > >>> > >>> Ian > >>> > >>> On 14. Jan 2021, at 13:40, t petch > >>> <[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>> > >>> wrote: > >>> > >>> Ian > >>> > >>> I do not understand this I-D; I have tracked it for a number of years and > >>> my understanding of it is diminishing. > >>> > >>> Currently, it is seven YANG modules: why? > >>> > >>> [if - The separation into client/server/relay, and DHCP options has been > >>> in the draft since -05 and the changes were presented and discussed at > >>> IETF101 - I’ve described the reasoning for this split in the next answer. > >>> Beyond that, the common module was added to avoid (well reduce as you > >>> point out below) duplication. > >>> > >>> The separation of the option modules came at a later stage based on > >>> import dependencies of a single options module. When the options module > >>> imports the client/server/relay modules so it can augment the relevant > >>> module based on identity, an implementation also needs to import these > >>> modules and will declare them in it’s capabilities as available even > >>> though it doesn’t implement them. Dividing the options modules avoids the > >>> need for deviations. > >>> > >>> Even though there are 7 modules defined here, the likely hood is that an > >>> element implementation would require 3 modules to be implemented (e.g. > >>> client, common and client options).] > >>> > >>> [tp] Other WG have models with multiple roles and many options and have a > >>> single YANG module, using the features of YANG to tailor the module to > >>> different configurations. > >>> > >>> [if - It’s not really tailoring the module to different configurations, > >>> they are for the most part separate functional elements in the network > >>> with any device only implementing one of the client, relay or server > >>> functions. > >>> > >>> However, even in the case that a device is both a server and a client > >>> (e.g. a home gateway with a client on the WAN and a server on the LAN), > >>> the likelihood is that these will be done using different software > >>> implementations, so having separate modules for server and client offers > >>> implementation flexibility. > >>> > >>> In the case of a monolithic module with the relevant client/relay/server > >>> functionality enabled by features, the module would do nothing unless one > >>> or more of the features was enabled, and Is unlikely that you’d ever > >>> enable more than one. Is this approach used by other WGs? Could you point > >>> me to some some examples as I've only seen features been used as > >>> relatively small optional extensions used when the bulk of the nodes are > >>> common?] > >> > >> [tp] > >> Ian > >> > >> Almost all the YANG models I know of are single module. For example, > >> draft-ietf-ospf-yang supports two versions modelled as identity and 28 > >> options modelled as features. > >> > >> draft-ietf-tcpm-yang supports client and server as containers with > >> if-feature and has other features as well > >> > >> draft-ietf-pim-igmp-mld-yang supports five versions of two protocol > >> using identity > >> > >> draft-pce-pcep-yang offers the roles of pcc or pce or both using typedef. > >> > >> And so on and so on. if-feature, when and suchlike provide the > >> necessary customisation. > >> > >> I think that your problems with options are because the identity are > >> defined in the wrong place. The base, the common module (or part of the > >> one and only module) should define what is common, what everyone needs; > >> if there are three roles and a dozen options, than that is where they > >> need to be defined. > >> > >> Then there can be an object which is configured with the roles of a > >> particular box, client or server or relay, or if required, a combination > >> of the there - simpler if that is out of scope as you suggest. > >> > >> My starting point would be a dhc container with a leaf for a role and then > >> containers for client, relay, server, added by augment and controlled by > >> when pointing at the role. > >> > >> I will post something to the netmod WG list - there are lots of people > >> there with greater exposure than mine who can give better guidance than I. > >> > >> Tom Petch > >> > >>> Here you have modelled the options as YANG grouping. The intent of a > >>> grouping is to provide a block of statements that can be reused so > >>> avoiding duplication with the attendant problems. Here you have the same > >>> grouping in triplicate in three different YANG modules which seems to me > >>> to be the antithesis of a grouping. > >>> > >>> [If - We could move the option definitions for "status-code-option-group” > >>> (client, server, relay) and “rapid-commit-option-group, > >>> vendor-specific-information-option-group; > >>> reconfigure-accept-option-group” (client, server) into the common module > >>> to resolve the duplication. I didn’t do this previously as the intention > >>> was to keep options definitions in the options modules for consistency, > >>> but it would be simple to change. ] > >>> > >>> [tp] Likewise I find the specification of server v client v relay unusual. > >>> > >>> [If - A similar approach for separated client/server modules is also used > >>> in RFC8676, where the client and server have discrete function, as with > >>> DHCP.] > >>> > >>> [tp]I wonder if it is worth consulting a YANG doctor, NOT to show them > >>> the YANG and invite comments, rather outline in an abstract way what it > >>> is you want to model and see what they suggest; that might well be a > >>> single YANG module. > >>> > >>> [if - Yes, I’d be happy to. Is there someone that you have in mind (I’ve > >>> not had much luck with getting YANG doctor input outside of the formal > >>> review process in the past)?. I’m not opposed to changing the way that > >>> the modules are structured on principal, I do however, think that the > >>> separation by functional element is logical and simpler for implementers, > >>> and I would like to know what the benefits of a single module (or other > >>> structure) might be.] > >>> > >>> [tp]I do have quite a number of detailed comments but do not think them > >>> worth making until the I-D seems to me more stable. > >>> > >>> [if - It’d be great if you could supply them as well so I can start going > >>> though them and fixing what’s currently fixable in parallel to the > >>> discussion above.] > >>> > >>> Tom Petch > >>> > >>> On 07/01/2021 16:10, > >>> [email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>> > >>> wrote: > >>> Hi Tom, > >>> > > -- > Ladislav Lhotka > Head, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
