Re: [netmod] Structuring a DHCP module
Ian Agree mostly. One follow-up in-line under Tom Petch From: ianfar...@gmx.com Sent: 25 January 2021 15:04 Hi Tom, Please see inline. Ian > On 22. Jan 2021, at 11:06, tom petch wrote: > > From: ianfar...@gmx.com > Sent: 22 January 2021 07:33 > > I’m planning to restructure so that the common module is imported by client, > server and relay, which means that the identity/role is no longer needed for > this. (I need to look at whether the identities are needed for other reasons, > such as how the modules will be extended with additional option definitions > etc.). This seems simpler to me and avoids the common module needing to > import all 3 of the other modules with the dependency problems that > introduces. > > > Sounds like a good idea to me. > > Does this address Martin's comment about not understanding the purpose of > a leaf called "dhcpv6-node-type"? > > For me. if identities are needed, they belong in the common module so all > node types have access to them (my instinct would be to specify them even if > they are not needed at present on the grounds that they likely will be). > Likewise, if there is a need to know the node type, I see that also as part > of a common module but then, as I said before, I am more used to, more > comfortable with, a single module. I have great respect for Lada's > recommendations so if he sees three modules as best, I will take that on > board. (You will have seen the comments up-thread from others about the > support from tools offering somewhat more with a single module). [if - I’ve spent some time with the restructure that’s being discussed, and the identities will no longer be needed.] > > Another point where different models take different views is whether or not > there should be a leaf to enable the function, be it server, relay, client or > some combination thereof; some do, others just say that if the module is > implemented on a node then of course it is enabled! [If - I think in this case is it would be useful. I’ll add in the next update. For the client and relay modules, it would also make sense to have an enable node for each relay/client interface.] > Another thought, if a node only implements the relay module, say, and there > is no leaf for node type, can you test for that in a module which wants to > augment the common module only if relay is implemented and/or enabled? A > presence container would do it, probably other ways as well, but I cannot > recall seeing that done. [if - Wouldn’t you just augment the relay module directly in this case?] Weelll I was positing that it was something that was a better fit for the common module because that is where other related definitions are but that at the moment it is for relay only. Purely hypothetical so leave it for now. Tom Petch > > Tom Petch >> > > > Ian > >> On 21. Jan 2021, at 18:48, tom petch wrote: >> >> From: Martin Björklund >> Sent: 21 January 2021 17:07 >> >> tom petch wrote: >>> From: Ladislav Lhotka >>> 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. >>> >>> >>> 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. >> >> >> >> Me too. I am assuming that it is intended to define the role but I could be >> quite wrong. Need input from Ian on this. >> >>> My instinct would be to put the three identity definitions into common with >>> a dhcpv6 container, which is then augmented by the three
Re: [netmod] Structuring a DHCP module
Hi Tom, Please see inline. Ian > On 22. Jan 2021, at 11:06, tom petch wrote: > > From: ianfar...@gmx.com > Sent: 22 January 2021 07:33 > > I’m planning to restructure so that the common module is imported by client, > server and relay, which means that the identity/role is no longer needed for > this. (I need to look at whether the identities are needed for other reasons, > such as how the modules will be extended with additional option definitions > etc.). This seems simpler to me and avoids the common module needing to > import all 3 of the other modules with the dependency problems that > introduces. > > > Sounds like a good idea to me. > > Does this address Martin's comment about not understanding the purpose of > a leaf called "dhcpv6-node-type"? > > For me. if identities are needed, they belong in the common module so all > node types have access to them (my instinct would be to specify them even if > they are not needed at present on the grounds that they likely will be). > Likewise, if there is a need to know the node type, I see that also as part > of a common module but then, as I said before, I am more used to, more > comfortable with, a single module. I have great respect for Lada's > recommendations so if he sees three modules as best, I will take that on > board. (You will have seen the comments up-thread from others about the > support from tools offering somewhat more with a single module). [if - I’ve spent some time with the restructure that’s being discussed, and the identities will no longer be needed.] > > Another point where different models take different views is whether or not > there should be a leaf to enable the function, be it server, relay, client or > some combination thereof; some do, others just say that if the module is > implemented on a node then of course it is enabled! [If - I think in this case is it would be useful. I’ll add in the next update. For the client and relay modules, it would also make sense to have an enable node for each relay/client interface.] > > Another thought, if a node only implements the relay module, say, and there > is no leaf for node type, can you test for that in a module which wants to > augment the common module only if relay is implemented and/or enabled? A > presence container would do it, probably other ways as well, but I cannot > recall seeing that done. [if - Wouldn’t you just augment the relay module directly in this case?] > > Tom Petch >> > > > Ian > >> On 21. Jan 2021, at 18:48, tom petch wrote: >> >> From: Martin Björklund >> Sent: 21 January 2021 17:07 >> >> tom petch wrote: >>> From: Ladislav Lhotka >>> 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. >>> >>> >>> 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. >> >> >> >> Me too. I am assuming that it is intended to define the role but I could be >> quite wrong. Need input from Ian on this. >> >>> 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? >> >> >> Yes, I am just lifting the structure of another I-D probably for no good >> engineering
Re: [netmod] Structuring a DHCP module
From: ianfar...@gmx.com Sent: 22 January 2021 07:33 I’m planning to restructure so that the common module is imported by client, server and relay, which means that the identity/role is no longer needed for this. (I need to look at whether the identities are needed for other reasons, such as how the modules will be extended with additional option definitions etc.). This seems simpler to me and avoids the common module needing to import all 3 of the other modules with the dependency problems that introduces. Sounds like a good idea to me. Does this address Martin's comment about not understanding the purpose of a leaf called "dhcpv6-node-type"? For me. if identities are needed, they belong in the common module so all node types have access to them (my instinct would be to specify them even if they are not needed at present on the grounds that they likely will be). Likewise, if there is a need to know the node type, I see that also as part of a common module but then, as I said before, I am more used to, more comfortable with, a single module. I have great respect for Lada's recommendations so if he sees three modules as best, I will take that on board. (You will have seen the comments up-thread from others about the support from tools offering somewhat more with a single module). Another point where different models take different views is whether or not there should be a leaf to enable the function, be it server, relay, client or some combination thereof; some do, others just say that if the module is implemented on a node then of course it is enabled! Another thought, if a node only implements the relay module, say, and there is no leaf for node type, can you test for that in a module which wants to augment the common module only if relay is implemented and/or enabled? A presence container would do it, probably other ways as well, but I cannot recall seeing that done. Tom Petch > Ian > On 21. Jan 2021, at 18:48, tom petch wrote: > > From: Martin Björklund > Sent: 21 January 2021 17:07 > > tom petch wrote: >> From: Ladislav Lhotka >> 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. >> >> >> 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. > > > > Me too. I am assuming that it is intended to define the role but I could be > quite wrong. Need input from Ian on this. > >> 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? > > > Yes, I am just lifting the structure of another I-D probably for no good > engineering reason:-(. > > Tom Petch > > /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,
Re: [netmod] Structuring a DHCP module
I’m planning to restructure so that the common module is imported by client, server and relay, which means that the identity/role is no longer needed for this. (I need to look at whether the identities are needed for other reasons, such as how the modules will be extended with additional option definitions etc.). This seems simpler to me and avoids the common module needing to import all 3 of the other modules with the dependency problems that introduces. Ian > On 21. Jan 2021, at 18:48, tom petch wrote: > > From: Martin Björklund > Sent: 21 January 2021 17:07 > > tom petch wrote: >> From: Ladislav Lhotka >> 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. >> >> >> 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. > > > > Me too. I am assuming that it is intended to define the role but I could be > quite wrong. Need input from Ian on this. > >> 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? > > > Yes, I am just lifting the structure of another I-D probably for no good > engineering reason:-(. > > Tom Petch > > /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 wrote: Inline From: Andy Bierman Sent: 20 January 2021 18:32 On Wed, Jan 20, 2021 at 8:41 AM tom petch mailto:ie...@btconnect.com>> 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
Re: [netmod] Structuring a DHCP module
From: Martin Björklund Sent: 21 January 2021 17:07 tom petch wrote: > From: Ladislav Lhotka > 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. > > > 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. Me too. I am assuming that it is intended to define the role but I could be quite wrong. Need input from Ian on this. > 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? Yes, I am just lifting the structure of another I-D probably for no good engineering reason:-(. Tom Petch /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 wrote: > >> > >> Inline > >> > >> From: Andy Bierman > >> Sent: 20 January 2021 18:32 > >> > >> On Wed, Jan 20, 2021 at 8:41 AM tom petch > >> mailto:ie...@btconnect.com>> 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
Re: [netmod] Structuring a DHCP module
tom petch wrote: > From: Ladislav Lhotka > 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. > > > 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 wrote: > >> > >> Inline > >> > >> From: Andy Bierman > >> Sent: 20 January 2021 18:32 > >> > >> On Wed, Jan 20, 2021 at 8:41 AM tom petch > >> mailto:ie...@btconnect.com>> 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
Re: [netmod] Structuring a DHCP module
From: Ladislav Lhotka 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. 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:-). 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? 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 wrote: >> >> Inline >> >> From: Andy Bierman >> Sent: 20 January 2021 18:32 >> >> On Wed, Jan 20, 2021 at 8:41 AM tom petch >> mailto:ie...@btconnect.com>> 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
Re: [netmod] Structuring a DHCP module
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 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 wrote: >>> >>> Inline >>> >>> From: Andy Bierman >>> Sent: 20 January 2021 18:32 >>> >>> On Wed, Jan 20, 2021 at 8:41 AM tom petch >>> mailto:ie...@btconnect.com>> 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.) >>> >>> >>> >>> 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
Re: [netmod] Structuring a DHCP module
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 wrote:
>>
>> Inline
>>
>> From: Andy Bierman
>> Sent: 20 January 2021 18:32
>>
>> On Wed, Jan 20, 2021 at 8:41 AM tom petch
>> mailto:ie...@btconnect.com>> 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.)
>>
>>
>>
>> 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.
>>
>> 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
Re: [netmod] Structuring a DHCP module
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 wrote:
>
> Inline
>
> From: Andy Bierman
> Sent: 20 January 2021 18:32
>
> On Wed, Jan 20, 2021 at 8:41 AM tom petch
> mailto:ie...@btconnect.com>> 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.)
>
>
>
> 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.
>
> 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
Re: [netmod] Structuring a DHCP module
Inline
From: Andy Bierman
Sent: 20 January 2021 18:32
On Wed, Jan 20, 2021 at 8:41 AM tom petch
mailto:ie...@btconnect.com>> 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.)
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.
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 mailto:dhcwg-boun...@ietf.org>> on behalf
> of ianfar...@gmx.com
> mailto:ianfar...@gmx.com>>
> Sent: 19 January 2021 07:37
>
> Thanks for your comments. Please see inline below.
>
> Ian
>
> On 14. Jan 2021, at 13:40, t petch
> mailto:ie...@btconnect.com>>>
> 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
Re: [netmod] Structuring a DHCP module
On Wed, Jan 20, 2021 at 8:41 AM tom petch 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 on behalf of ianfar...@gmx.com < > ianfar...@gmx.com> > > Sent: 19 January 2021 07:37 > > > > Thanks for your comments. Please see inline below. > > > > Ian > > > > On 14. Jan 2021, at 13:40, t petch ie...@btconnect.com>> 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
[netmod] Structuring a DHCP module
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! Tom Petch On 19/01/2021 11:25, tom petch wrote: > > From: dhcwg on behalf of ianfar...@gmx.com > > Sent: 19 January 2021 07:37 > > Thanks for your comments. Please see inline below. > > Ian > > On 14. Jan 2021, at 13:40, t petch > mailto:ie...@btconnect.com>> 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
