Hi, Thanks for all your input on the question. Based on Martin’s proposal, combining the element modules with their associated options modules, and moving duplicate option definitions into the common module (resulting in 4 modules), here’s some very rough calculations on the resulting amount of overlap:
Ietf-dhcpv6-server (total size including unique option definitions, 809 lines) uses 120 lines from ietf-dhcpv6-common Ietf-dhcpv6-client (562 lines) uses 120 lines from common Ietf-dhcpv6-relay (576 lines) uses 15 lines from common Given this, I would propose following this approach. Does this look reasonable? Point taken about the rfc numbers in naming the modules. I’ll look for a better way of naming them. Thanks, Ian > On 21. Jan 2021, at 13:58, Ladislav Lhotka <[email protected]> wrote: > > 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. > > 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
