On Wed, Jan 20, 2021 at 8:41 AM tom petch <[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.) 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]> on behalf of [email protected] < > [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]>> 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]> wrote: > > Hi Tom, > >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
