Subject: [yang-doctors] Small modules discussion from LSR [Fwd: [Lsr] When to augment LSR base YANG modules...]

From: Christian Hopps <[email-masked]>
Date: Mon, 1 Apr 2019 08:39:46 -0400

Hi YANG Doctors,

So I started a thread on the LSR mailing list (included below) about including small modules to augment the base protocol modules inline with the small feature drafts that modify the protocol (typically adding TLVs and some config). We probably publish 1-4 of these per year. An opposing opinion was expressed that we should batch these features into meta-modules to avoid creating "too many" modules. I don't know what too many is, and I pointed out that to a client there's really no difference between N modules and 1 module with N optional features (they all show up as capabilities).

So to quote Acee here:

	"Let's have a discussion on YANG doctors list on the merits of a small module per feature vs an aggregate model with features."

There are process issues that are outside the scope of YANG (e.g., will it cause too many authors on a document, delays caused by batching etc).. but we're curious if there are any reasons particular to YANG to do or avoid one or the other.

Thanks,
Chris.

> Begin forwarded message:
> 
> From: "Acee Lindem (acee)" <[email-masked]>
> Subject: Re: [Lsr] When to augment LSR base YANG modules...
> Date: March 31, 2019 at 5:09:32 PM EDT
> To: Christian Hopps <[email-masked]>, Yingzhen Qu <[email-masked]>
> Cc: Susan Hares <[email-masked]>, Rob Shakir <[email-masked]>, "[email-masked]" <[email-masked]>, Tony Li <[email-masked]>
> 
> Hi Chris, Yingzhen,
> 
> Let's have a discussion on YANG doctors list on the merits of a small module per feature vs an aggregate model with features.
> 
> We can try this as an experiment. Perhaps, we can get a permanent dispensation to the 5 author rule if every draft needs someone YANG fluent and familiar with the base OSPF and ISIS models.
> 
> Thanks,
> Acee
> 
> On 3/31/19, 3:41 PM, "Christian Hopps" <[email-masked]> wrote:
> 
> 
> 
>> On Mar 31, 2019, at 1:31 PM, Yingzhen Qu <[email-masked]> wrote:
>> 
>> There are many small feature drafts in LSR, for example: https://datatracker.ietf.org/doc/draft-ietf-ospf-ospfv2-hbit/  it only adds H-bit to router-lsa.
>> 
>> For sure we want models to be modular, but not too many tiny pieces. Maybe we should combine a few small features like H-Bit into one module?
> 
>    But why?
> 
>    Delaying the publication of the management definition until some (so far as I can tell) arbitrary number of features has been collected negatively impacts users. What do they gain in return?
> 
>    Thanks,
>    Chris.
> 
>> 
>> Thanks,
>> Yingzhen
>> 
>> From: Lsr <[email-masked]> on behalf of Susan Hares <[email-masked]>
>> Date: Sunday, March 31, 2019 at 7:15 AM
>> To: 'Rob Shakir' <[email-masked]>, "'Acee Lindem (acee)'" <[email-masked]>
>> Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, 'Christian Hopps' <[email-masked]>
>> Subject: Re: [Lsr] When to augment LSR base YANG modules...
>> 
>> Rob and Acee:
>> 
>> I agree that with Rob that it is a generic problem that you must have a robust way to version and revise the Yang models.   This is true for configuration, operational data, and dynamic data stores.   The netmod modeling is focusing on configuration at this time.
>> 
>> It is critical to determine how the base models yang models prepare for augmentations.  OSPF, ISIS, BGP, FIB/RIB, and policy are key models.   Since our protocols are augmented based on capabilities, augmentation based on the same capabilities for models makes the most sense.   We can review info/data, and code functionality based on the key senses.
>> 
>> If we have good versioning of the base model, can revise both the data model and the capability independently.   If we utilize the grouping of data models based on the versioning, automatic deployment of this work can occur.
>> 
>> Acee and Chris has been actively participating on the versioning discussion in netmod’s work on versioning.   I’m sure they can report if they feel the support his there for this type of version.
>> 
>> BGP and rtgwg can integrate this type of version prior to the upcoming WG LC.
>> 
>> Sue
>> 
>> 
>> From: Lsr [mailto:[email-masked]] On Behalf Of Rob Shakir
>> Sent: Saturday, March 30, 2019 2:00 PM
>> To: Acee Lindem (acee)
>> Cc: [email-masked]; [email-masked]; Christian Hopps
>> Subject: Re: [Lsr] When to augment LSR base YANG modules...
>> 
>> I think this is a generic challenge that has to be solved across all protocols -- and relies on a robust way to version and revise YANG modules in the IETF.
>> 
>> In OpenConfig, as we're very lightweight for pushing a new revision, since we're just specifying new versions of modules, adding new features to an existing module is pretty trivial. They can be done as a minor revision if there's no backwards incompatible changes.  It seems better, to me, to ensure that there is common logic for how one splits up modules, to make things actually usable for developers trying to consume them, rather than needing to understand when and where in the IETF a feature was developed.
>> 
>> That being said -- this means one should probably expect each LSR base module to be revised with most new LSR RFCs. With the current agility of the review and publication process -- I'm not sure that is realistic either.
>> 
>> r.
>> 
>> On Sat, 30 Mar 2019 at 09:15, Acee Lindem (acee) <[email-masked]> wrote:
>> Speaking as WG member:
>> 
>> For many of the new LSR WG documents, we are already included both OSPF and IS-IS encodings in a single document. Now, we have agreed that documents requiring simple BGP-LS changes will also include the BGP-LS encoding. Given this, I don't want to add another requirement for publication of a WG document. This would also add additional reviews to the document. You've all heard the expression "divide and conquer", while let me introduce the corollary, "consolidate and stagnate".
>> 
>> Additionally, I agree with Yingzhen's comment that it is not clear that we want a separate YANG module for every OSPF/IS-IS feature.
>> 
>> Thanks,
>> Acee
>> 
>> On 3/29/19, 4:33 AM, "Lsr on behalf of [email-masked]" <[email-masked] on behalf of [email-masked]> wrote:
>> 
>> 
>>    Chris,
>> 
>>    One concern is simply one of scale: doing this will increase the size of the document.  At what point do things become sufficiently awkward that we want to have a separate, concurrent document.
>> 
>>    In other words, if the requirement is for concurrent delivery, is co-location really a requirement?
>> 
>>    Regards,
>>    Tony
>> 
>> 
>>> On Mar 29, 2019, at 9:17 AM, Christian Hopps <[email-masked]> wrote:
>>> 
>>> 
>>> The base YANG modules for IS-IS and OSPF both include operational state to describe TLV data. During the discussion about OSPFv3's version of this data, I brought up the issue of when and how the base modules should be augmented to add new TLV types to the model, suggesting it be done inline and with the RFC that adds the new feature/functionality to the protocol.
>>> 
>>> I'll go farther here and say this should apply to all the YANG required for management of the new feature, and it should all be added inline with the feature (i.e., in the same draft). In other words new features/functionality should include the YANG augment required to manage said features/functionality.
>>> 
>>> This has been suggested/tried previously with SNMP with varying (low) levels of success. The difference here is 1) YANG additions (a new module perhaps just augmenting the base) is easy, whereas SNMP wasn't. Additionally, operators weren't using SNMP to fully manage functionality (e.g., not doing configuration) so a requirement for extra work was harder to justify. Operators *do* want to fully manage their networks/servers with YANG though.
>>> 
>>> The argument against this during the meeting was that it would create many small modules. I don't find this compelling (i.e., "so"? :)
>>> 
>>> Assume I'm an operator -- the actual consumer of this management stuff:
>>> 
>>> - If I'm going to use this new feature X, I need to be able to manage it. So I need it YANG for it. Not only do I need any new TLV data in the operational state, but I need the configuration and any other operational state right along with it. Otherwise each vendor has to add new YANG to their vendor modules, or the feature is useless to me. I can't use something if I can't turn it on.
>>> 
>>> - I don't care about having many smaller modules that augment the base module -- at all. Quite the opposite actually, when new functionality is accompanied by it's own module it provides me a simple way to see if that functionality is present as the module will be present in the YANG capabilities announced by the device.
>>> 
>>> I'd be interested in hearing reasons we (as a WG) shouldn't just expect a YANG module (even if it's small) to be included with drafts that add new functionality.
>>> 
>>> Thanks,
>>> Chris.
>>> _______________________________________________
>>> Lsr mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/lsr
>> 
>>    _______________________________________________
>>    Lsr mailing list
>>    [email-masked]
>>    https://www.ietf.org/mailman/listinfo/lsr
>> 
>> 
>> _______________________________________________
>> Lsr mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/lsr
>> _______________________________________________
>> Lsr mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/lsr
> 
> 
>

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 02 Apr 2019 10:24:59 +0200 (CEST)

Hi,

There is some overhead attached to a module.  In the extreme case,
each module could have a single node, this is clearly problematic.  It
is harder to know where to find the node you're looking for, and it is
harder to get node path right if every node may have a new
namespace/module-name.

Rather than collecting 1-4 "things" in a batch, which would introduce
delays, would it be possible to simply re-publish a single module with
all these augmentations?

A variant of this could be to have a single main module that just
includes a bunch of sub-modules (one per augmentation), and let each
new document add a new submodule and at the same time re-publish the
main module with a new include statement.  Perhaps even have IANA
maintain the main module?

/martin

Christian Hopps <[email-masked]> wrote:
> Hi YANG Doctors,
> 
> So I started a thread on the LSR mailing list (included below) about
> including small modules to augment the base protocol modules inline
> with the small feature drafts that modify the protocol (typically
> adding TLVs and some config). We probably publish 1-4 of these per
> year. An opposing opinion was expressed that we should batch these
> features into meta-modules to avoid creating "too many" modules. I
> don't know what too many is, and I pointed out that to a client
> there's really no difference between N modules and 1 module with N
> optional features (they all show up as capabilities).
> 
> So to quote Acee here:
> 
> 	"Let's have a discussion on YANG doctors list on the merits of a small
> 	module per feature vs an aggregate model with features."
> 
> There are process issues that are outside the scope of YANG (e.g.,
> will it cause too many authors on a document, delays caused by
> batching etc).. but we're curious if there are any reasons particular
> to YANG to do or avoid one or the other.
> 
> Thanks,
> Chris.
> 
> > Begin forwarded message:
> > 
> > Cc: Susan Hares <[email-masked]>, Rob Shakir <[email-masked]>,
> > "[email-masked]" <[email-masked]>, Tony Li <[email-masked]>
> > 
> > Hi Chris, Yingzhen,
> > 
> > Let's have a discussion on YANG doctors list on the merits of a small
> > module per feature vs an aggregate model with features.
> > 
> > We can try this as an experiment. Perhaps, we can get a permanent
> > dispensation to the 5 author rule if every draft needs someone YANG
> > fluent and familiar with the base OSPF and ISIS models.
> > 
> > Thanks,
> > Acee
> > 
> >> There are many small feature drafts in LSR, for example:
> >> https://datatracker.ietf.org/doc/draft-ietf-ospf-ospfv2-hbit/ it only
> >> adds H-bit to router-lsa.
> >> 
> >> For sure we want models to be modular, but not too many tiny
> >> pieces. Maybe we should combine a few small features like H-Bit into
> >> one module?
> > 
> >    But why?
> > 
> >    Delaying the publication of the management definition until some (so
> >    far as I can tell) arbitrary number of features has been collected
> >    negatively impacts users. What do they gain in return?
> > 
> >    Thanks,
> >    Chris.
> > 
> >> 
> >> Thanks,
> >> Yingzhen
> >> 
> >> Cc: "[email-masked]" <[email-masked]>, "[email-masked]"
> >> <[email-masked]>, 'Christian Hopps' <[email-masked]>
> >> I agree that with Rob that it is a generic problem that you must have
> >> a robust way to version and revise the Yang models.  This is true for
> >> configuration, operational data, and dynamic data stores.  The netmod
> >> modeling is focusing on configuration at this time.
> >> 
> >> It is critical to determine how the base models yang models prepare
> >> for augmentations.  OSPF, ISIS, BGP, FIB/RIB, and policy are key
> >> models.  Since our protocols are augmented based on capabilities,
> >> augmentation based on the same capabilities for models makes the most
> >> sense.  We can review info/data, and code functionality based on the
> >> key senses.
> >> 
> >> If we have good versioning of the base model, can revise both the data
> >> model and the capability independently.  If we utilize the grouping of
> >> data models based on the versioning, automatic deployment of this work
> >> can occur.
> >> 
> >> Acee and Chris has been actively participating on the versioning
> >> discussion in netmod’s work on versioning.  I’m sure they can report
> >> if they feel the support his there for this type of version.
> >> 
> >> I think this is a generic challenge that has to be solved across all
> >> protocols -- and relies on a robust way to version and revise YANG
> >> modules in the IETF.
> >> 
> >> In OpenConfig, as we're very lightweight for pushing a new revision,
> >> since we're just specifying new versions of modules, adding new
> >> features to an existing module is pretty trivial. They can be done as
> >> a minor revision if there's no backwards incompatible changes.  It
> >> seems better, to me, to ensure that there is common logic for how one
> >> splits up modules, to make things actually usable for developers
> >> trying to consume them, rather than needing to understand when and
> >> where in the IETF a feature was developed.
> >> 
> >> That being said -- this means one should probably expect each LSR base
> >> module to be revised with most new LSR RFCs. With the current agility
> >> of the review and publication process -- I'm not sure that is
> >> realistic either.
> >> 
> >> r.
> >> 
> >> For many of the new LSR WG documents, we are already included both
> >> OSPF and IS-IS encodings in a single document. Now, we have agreed
> >> that documents requiring simple BGP-LS changes will also include the
> >> BGP-LS encoding. Given this, I don't want to add another requirement
> >> for publication of a WG document. This would also add additional
> >> reviews to the document. You've all heard the expression "divide and
> >> conquer", while let me introduce the corollary, "consolidate and
> >> stagnate".
> >> 
> >> Additionally, I agree with Yingzhen's comment that it is not clear
> >> that we want a separate YANG module for every OSPF/IS-IS feature.
> >> 
> >> Thanks,
> >> Acee
> >> 
> >> On 3/29/19, 4:33 AM, "Lsr on behalf of [email-masked]"
> >> <[email-masked] on behalf of [email-masked]> wrote:
> >> 
> >> 
> >>    Chris,
> >> 
> >>    One concern is simply one of scale: doing this will increase the size
> >>    of the document.  At what point do things become sufficiently awkward
> >>    that we want to have a separate, concurrent document.
> >> 
> >>> The base YANG modules for IS-IS and OSPF both include operational
> >>> state to describe TLV data. During the discussion about OSPFv3's
> >>> version of this data, I brought up the issue of when and how the base
> >>> modules should be augmented to add new TLV types to the model,
> >>> suggesting it be done inline and with the RFC that adds the new
> >>> feature/functionality to the protocol.
> >>> 
> >>> I'll go farther here and say this should apply to all the YANG
> >>> required for management of the new feature, and it should all be added
> >>> inline with the feature (i.e., in the same draft). In other words new
> >>> features/functionality should include the YANG augment required to
> >>> manage said features/functionality.
> >>> 
> >>> This has been suggested/tried previously with SNMP with varying (low)
> >>> levels of success. The difference here is 1) YANG additions (a new
> >>> module perhaps just augmenting the base) is easy, whereas SNMP
> >>> wasn't. Additionally, operators weren't using SNMP to fully manage
> >>> functionality (e.g., not doing configuration) so a requirement for
> >>> extra work was harder to justify. Operators *do* want to fully manage
> >>> their networks/servers with YANG though.
> >>> 
> >>> The argument against this during the meeting was that it would create
> >>> many small modules. I don't find this compelling (i.e., "so"? :)
> >>> 
> >>> - If I'm going to use this new feature X, I need to be able to manage
> >>> - it. So I need it YANG for it. Not only do I need any new TLV data in
> >>> - the operational state, but I need the configuration and any other
> >>> - operational state right along with it. Otherwise each vendor has to
> >>> - add new YANG to their vendor modules, or the feature is useless to
> >>> - me. I can't use something if I can't turn it on.
> >>> 
> >>> - I don't care about having many smaller modules that augment the base
> >>> - module -- at all. Quite the opposite actually, when new functionality
> >>> - is accompanied by it's own module it provides me a simple way to see
> >>> - if that functionality is present as the module will be present in the
> >>> - YANG capabilities announced by the device.
> >>> 
> >>> I'd be interested in hearing reasons we (as a WG) shouldn't just
> >>> expect a YANG module (even if it's small) to be included with drafts
> >>> that add new functionality.
> >>> 
> >>> Thanks,
> >>> Chris.

---

From: Christian Hopps <[email-masked]>
Date: Tue, 2 Apr 2019 05:11:13 -0400

So I published a module for IS-IS reverse metric to use as context for this discussion:

  https://tools.ietf.org/html/draft-hopps-lsr-yang-isis-reverse-metric-00

This is adding management for the functionality defined in RFC8500 <https://tools.ietf.org/html/rfc8500>

My thinking is that it would be better (at least for users wanting to use the feature) to define and include this module directly in the functionality draft, rather than outside or as a feature in a delayed "batch" module. I really don't know much about sub-modules, but was under the impression they came with their own set of issues.

Thanks,
Chris.

> On Apr 2, 2019, at 4:24 AM, Martin Bjorklund <[email-masked]> wrote:
> 
> Hi,
>

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Tue, 2 Apr 2019 09:52:35 +0000

Hi Chris,

I don’t think that there is a one size fits all answer here.

If the enhancement is small, and is likely to be reasonably widely used then my view is that adding it as an optional feature to the base module is a better choice in the long term.

If the feature is larger, or esoteric, and perhaps won’t be widely deployed then I would think that putting it into a separate module might be a better choice.

I actually think that it is the IETF process that is perhaps the difficult thing here.  I.e. I think that you want to republish a new revision of the base module, but in a way that gets processed more quickly by the IESG.  E.g. request that they only review/comment on the diffs between the current revision and the previous one.  Or somehow publish an updated revision of the module on github without assigning it a new RFC number every time.

Thanks,
Rob

From: yang-doctors <[email-masked]> On Behalf Of Christian Hopps
Sent: 01 April 2019 13:40
To: YANG Doctors <[email-masked]>
Cc: Yingzhen Qu <[email-masked]>
Subject: [yang-doctors] Small modules discussion from LSR [Fwd: [Lsr] When to augment LSR base YANG modules...]

Hi YANG Doctors,

So to quote Acee here:

Thanks,
Chris.

Begin forwarded message:

From: "Acee Lindem (acee)" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Lsr] When to augment LSR base YANG modules...
Date: March 31, 2019 at 5:09:32 PM EDT
To: Christian Hopps <[email-masked]<mailto:[email-masked]>>, Yingzhen Qu <[email-masked]<mailto:[email-masked]>>
Cc: Susan Hares <[email-masked]<mailto:[email-masked]>>, Rob Shakir <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Tony Li <[email-masked]<mailto:[email-masked]>>

Hi Chris, Yingzhen,

Thanks,
Acee

On 3/31/19, 3:41 PM, "Christian Hopps" <[email-masked]<mailto:[email-masked]>> wrote:

On Mar 31, 2019, at 1:31 PM, Yingzhen Qu <[email-masked]<mailto:[email-masked]>> wrote:

   But why?

   Thanks,
   Chris.

Thanks,
Yingzhen

From: Lsr <[email-masked]<mailto:[email-masked]>> on behalf of Susan Hares <[email-masked]<mailto:[email-masked]>>
Date: Sunday, March 31, 2019 at 7:15 AM
To: 'Rob Shakir' <[email-masked]<mailto:[email-masked]>>, "'Acee Lindem (acee)'" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, 'Christian Hopps' <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Lsr] When to augment LSR base YANG modules...

Rob and Acee:

Sue

From: Lsr [mailto:[email-masked]] On Behalf Of Rob Shakir
Sent: Saturday, March 30, 2019 2:00 PM
To: Acee Lindem (acee)
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Christian Hopps
Subject: Re: [Lsr] When to augment LSR base YANG modules...

r.

On Sat, 30 Mar 2019 at 09:15, Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>> wrote:
Speaking as WG member:

Thanks,
Acee

On 3/29/19, 4:33 AM, "Lsr on behalf of [email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

   Chris,

   Regards,
   Tony

On Mar 29, 2019, at 9:17 AM, Christian Hopps <[email-masked]<mailto:[email-masked]>> wrote:

Thanks,
Chris.
_______________________________________________
Lsr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lsr

   _______________________________________________
   Lsr mailing list
   [email-masked]<mailto:[email-masked]>
   https://www.ietf.org/mailman/listinfo/lsr

_______________________________________________
Lsr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________
Lsr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/lsr

---

From: Christian Hopps <[email-masked]>
Date: Tue, 2 Apr 2019 06:31:20 -0400

> On Apr 2, 2019, at 5:52 AM, Rob Wilton (rwilton) <[email-masked]> wrote:
> 
> Hi Chris,
> 

Yes, although I'm trying to do a couple things:

- Get YANG management support added at the same time as the functionality, not as an after thought maybe someday, maybe never.
- Reduce the cost of adding the YANG support. A stand-alone document is very expensive time and effort wise, separate IESG reviews, directorate reviews, last-calls.

I had wondered if we could use errata on the base vs doing a brand new bis version of the base module; however, this seems to be trading too much process overhead with perhaps not quite enough.

To the first goal, I wrote that reverse metric module a couple days ago as an example. I have to wonder when or even if it would have gotten written (or the equivalent feature added) otherwise. Instead I suspect it would just get added into N vendors models as people move on to other things in the WG.

In a perfect world I would add a YANG section to my functionality RFC that updated (not augment) the base module, but with augment style definition (i.e., so the entire huge base module doesn't need to be re-represented in the document). This would then cause the base document to get reissued with the changes. Sort of like IANA sections are capable of updating a registry.

So maybe your github idea is like this, we create a module definition registry where the most up-to-date module definitions go, and then RFCs can update that using something like (or exactly like) augment to document the changes to the module in the individual RFCs.

Thanks,
Chris.

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Tue, 2 Apr 2019 11:16:32 +0000

> -----Original Message-----
> From: Christian Hopps <[email-masked]>
> Sent: 02 April 2019 11:31
> To: Rob Wilton (rwilton) <[email-masked]>
> Cc: Christian Hopps <[email-masked]>; YANG Doctors <yang-
> [email-masked]>; Yingzhen Qu <[email-masked]>
> Subject: Re: [yang-doctors] Small modules discussion from LSR [Fwd: [Lsr]
> When to augment LSR base YANG modules...]
> 
> 
> > If the enhancement is small, and is likely to be reasonably widely used then
> my view is that adding it as an optional feature to the base module is a better
> choice in the long term.
> >
> > If the feature is larger, or esoteric, and perhaps won’t be widely deployed
> then I would think that putting it into a separate module might be a better
> choice.
> >
> > I actually think that it is the IETF process that is perhaps the difficult thing
> here.  I.e. I think that you want to republish a new revision of the base
> module, but in a way that gets processed more quickly by the IESG.  E.g.
> request that they only review/comment on the diffs between the current
> revision and the previous one.  Or somehow publish an updated revision of
> the module on github without assigning it a new RFC number every time.
> 
> - Get YANG management support added at the same time as the
> functionality, not as an after thought maybe someday, maybe never.

I agree that this is definitely the right thing to do.

> - Reduce the cost of adding the YANG support. A stand-alone document is
> very expensive time and effort wise, separate IESG reviews, directorate
> reviews, last-calls.

I agree.  And rev'ing the base ISIS YANG model is likely to be just as expensive.

> 
> I had wondered if we could use errata on the base vs doing a brand new bis
> version of the base module; however, this seems to be trading too much
> process overhead with perhaps not quite enough.
> 
> To the first goal, I wrote that reverse metric module a couple days ago as an
> example. I have to wonder when or even if it would have gotten written (or
> the equivalent feature added) otherwise. Instead I suspect it would just get
> added into N vendors models as people move on to other things in the WG.
> 
> In a perfect world I would add a YANG section to my functionality RFC that
> updated (not augment) the base module, but with augment style definition
> (i.e., so the entire huge base module doesn't need to be re-represented in
> the document). This would then cause the base document to get reissued
> with the changes. Sort of like IANA sections are capable of updating a
> registry.

We almost want to just include a diff/patch to the base model into the document.  This is actually a little bit like how IEEE 802 update their documents, and then they periodically roll their updates into the base model.

> 
> So maybe your github idea is like this, we create a module definition registry
> where the most up-to-date module definitions go, and then RFCs can update
> that using something like (or exactly like) augment to document the changes
> to the module in the individual RFCs.

Yes.  We want the review to only focus on the stuff that is new/added rather than reviewing the whole module every time.

Martin's suggestion of using submodules is another way to achieve this.  E.g. the actual module definition is split over multiple RFCs, but I'm not that keen on submodules and I suspect that this will make them hard to read in future.

I think that the real answer here is that YANG modules should not be published in RFCs.  Yes, they should go through a similar formal review process for changes to the modules but without the overhead of reviewing every change as a new document.

Thanks,
Rob

> > Subject: [yang-doctors] Small modules discussion from LSR [Fwd: [Lsr]
> When to augment LSR base YANG modules...]
> >
> > Hi YANG Doctors,
> >
> including small modules to augment the base protocol modules inline with
> the small feature drafts that modify the protocol (typically adding TLVs and
> some config). We probably publish 1-4 of these per year. An opposing
> opinion was expressed that we should batch these features into meta-
> modules to avoid creating "too many" modules. I don't know what too many
> is, and I pointed out that to a client there's really no difference between N
> modules and 1 module with N optional features (they all show up as
> capabilities).
> >
> > So to quote Acee here:
> >
> > There are process issues that are outside the scope of YANG (e.g., will it
> cause too many authors on a document, delays caused by batching etc).. but
> we're curious if there are any reasons particular to YANG to do or avoid one
> or the other.
> >
> > Thanks,
> > Chris.
> >
> > Begin forwarded message:
> >
> dispensation to the 5 author rule if every draft needs someone YANG fluent
> and familiar with the base OSPF and ISIS models.
> >
> > Thanks,
> > Acee
> >
> https://datatracker.ietf.org/doc/draft-ietf-ospf-ospfv2-hbit/  it only adds H-
> bit to router-lsa.
> >
> > For sure we want models to be modular, but not too many tiny pieces.
> Maybe we should combine a few small features like H-Bit into one module?
> >
> >    But why?
> >
> >    Delaying the publication of the management definition until some (so far
> as I can tell) arbitrary number of features has been collected negatively
> impacts users. What do they gain in return?
> >
> >    Thanks,
> >    Chris.
> >
> >
> >
> > Thanks,
> > Yingzhen
> >
> > I agree that with Rob that it is a generic problem that you must have a
> robust way to version and revise the Yang models.   This is true for
> > It is critical to determine how the base models yang models prepare for
> augmentations.  OSPF, ISIS, BGP, FIB/RIB, and policy are key models.   Since
> our protocols are augmented based on capabilities, augmentation based on
> the same capabilities for models makes the most sense.   We can review
> info/data, and code functionality based on the key senses.
> >
> model and the capability independently.   If we utilize the grouping of data
> models based on the versioning, automatic deployment of this work can
> occur.
> >
> > Acee and Chris has been actively participating on the versioning discussion
> in netmod’s work on versioning.   I’m sure they can report if they feel the
> support his there for this type of version.
> >
> > I think this is a generic challenge that has to be solved across all protocols --
> and relies on a robust way to version and revise YANG modules in the IETF.
> >
> > In OpenConfig, as we're very lightweight for pushing a new revision, since
> we're just specifying new versions of modules, adding new features to an
> existing module is pretty trivial. They can be done as a minor revision if
> there's no backwards incompatible changes.  It seems better, to me, to
> ensure that there is common logic for how one splits up modules, to make
> things actually usable for developers trying to consume them, rather than
> needing to understand when and where in the IETF a feature was developed.
> >
> module to be revised with most new LSR RFCs. With the current agility of the
> review and publication process -- I'm not sure that is realistic either.
> >
> > r.
> >
> OSPF and IS-IS encodings in a single document. Now, we have agreed that
> documents requiring simple BGP-LS changes will also include the BGP-LS
> encoding. Given this, I don't want to add another requirement for
> publication of a WG document. This would also add additional reviews to the
> document. You've all heard the expression "divide and conquer", while let
> me introduce the corollary, "consolidate and stagnate".
> >
> > Additionally, I agree with Yingzhen's comment that it is not clear that we
> want a separate YANG module for every OSPF/IS-IS feature.
> >
> > Thanks,
> > Acee
> >
> > On 3/29/19, 4:33 AM, "Lsr on behalf of [email-masked]" <lsr-
> [email-masked] on behalf of [email-masked]> wrote:
> >
> >
> >    Chris,
> >
> >    One concern is simply one of scale: doing this will increase the size of the
> document.  At what point do things become sufficiently awkward that we
> want to have a separate, concurrent document.
> >
> > The base YANG modules for IS-IS and OSPF both include operational state
> to describe TLV data. During the discussion about OSPFv3's version of this
> data, I brought up the issue of when and how the base modules should be
> augmented to add new TLV types to the model, suggesting it be done inline
> and with the RFC that adds the new feature/functionality to the protocol.
> >
> > I'll go farther here and say this should apply to all the YANG required for
> management of the new feature, and it should all be added inline with the
> feature (i.e., in the same draft). In other words new features/functionality
> should include the YANG augment required to manage said
> features/functionality.
> >
> levels of success. The difference here is 1) YANG additions (a new module
> perhaps just augmenting the base) is easy, whereas SNMP wasn't.
> Additionally, operators weren't using SNMP to fully manage functionality
> (e.g., not doing configuration) so a requirement for extra work was harder to
> justify. Operators *do* want to fully manage their networks/servers with
> YANG though.
> >
> > - If I'm going to use this new feature X, I need to be able to manage it. So I
> need it YANG for it. Not only do I need any new TLV data in the operational
> state, but I need the configuration and any other operational state right
> along with it. Otherwise each vendor has to add new YANG to their vendor
> modules, or the feature is useless to me. I can't use something if I can't turn
> it on.
> >
> module -- at all. Quite the opposite actually, when new functionality is
> accompanied by it's own module it provides me a simple way to see if that
> functionality is present as the module will be present in the YANG capabilities
> announced by the device.
> >
> > I'd be interested in hearing reasons we (as a WG) shouldn't just expect a
> YANG module (even if it's small) to be included with drafts that add new
> functionality.
> >
> > Thanks,
> > Chris.

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 02 Apr 2019 13:29:04 +0200 (CEST)

> I agree.  And rev'ing the base ISIS YANG model is likely to be just as

My suggestion was not to rev the base model, but have _one_ model with
these "optional features", and rev that every time.

> We almost want to just include a diff/patch to the base model into the
> document.  This is actually a little bit like how IEEE 802 update
> their documents, and then they periodically roll their updates into
> the base model.
> 
> 
> > 
> Yes.  We want the review to only focus on the stuff that is new/added
> rather than reviewing the whole module every time.
> 
> Martin's suggestion of using submodules is another way to achieve
> this.  E.g. the actual module definition is split over multiple RFCs,
> but I'm not that keen on submodules and I suspect that this will make
> them hard to read in future.

Note that we can "gc" the submodules and fold their contents into the
main module, or perhaps a "top" submodule, when you have N submodules.

> I think that the real answer here is that YANG modules should not be
> published in RFCs.  Yes, they should go through a similar formal
> review process for changes to the modules but without the overhead of
> reviewing every change as a new document.

Right.  This is longer term though, since it requires a process
update!

/martin

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 2 Apr 2019 12:05:57 +0000

Hi Rob,

Given the existing IETF process and size of the base OSPF and IS-IS models, we don’t want to have to revise these very often. If we come up with an alternate process, this may become a viable option.

Thanks,
Acee

From: yang-doctors <[email-masked]> on behalf of "Rob Wilton (rwilton)" <[email-masked]>
Date: Tuesday, April 2, 2019 at 5:53 AM
To: Christian Hopps <[email-masked]>, YANG Doctors <[email-masked]>
Cc: Yingzhen Qu <[email-masked]>
Subject: Re: [yang-doctors] Small modules discussion from LSR [Fwd: [Lsr] When to augment LSR base YANG modules...]

Hi Chris,

Thanks,
Rob

Hi YANG Doctors,

So to quote Acee here:

Thanks,
Chris.

Begin forwarded message:

Hi Chris, Yingzhen,

Thanks,
Acee

   But why?

   Thanks,
   Chris.

Thanks,
Yingzhen

Rob and Acee:

Sue

r.

Thanks,
Acee

   Chris,

   Regards,
   Tony

Thanks,
Chris.

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Tue, 2 Apr 2019 12:08:16 +0000

> From: Martin Bjorklund <[email-masked]>
> Sent: 02 April 2019 12:29
> Cc: [email-masked]; [email-masked]; [email-masked]
> > > > On Apr 2, 2019, at 5:52 AM, Rob Wilton (rwilton)
> > > > <[email-masked]>
> > > wrote:
> > > >
> > > > Hi Chris,
> > > >
> > > my view is that adding it as an optional feature to the base module
> > > is a better choice in the long term.
> > > >
> > > then I would think that putting it into a separate module might be a
> > > better choice.
> > > >
> > > here.  I.e. I think that you want to republish a new revision of the
> > > base module, but in a way that gets processed more quickly by the
> > > IESG.
> > > E.g.
> > > request that they only review/comment on the diffs between the
> > > current revision and the previous one.  Or somehow publish an
> > > updated revision of the module on github without assigning it a new
> > > RFC number every time.
> > >
> > > - Reduce the cost of adding the YANG support. A stand-alone document
> > > is very expensive time and effort wise, separate IESG reviews,
> > > directorate reviews, last-calls.
> >

[RW] I'm not sure I see the difference.

Whatever minimal base draft that does the includes has to be updated if a new include is added or changed.

Where would that updated base be published?  Would that be included in the extension RFC?

> 
> > > I had wondered if we could use errata on the base vs doing a brand
> > > new bis version of the base module; however, this seems to be
> > > trading too much process overhead with perhaps not quite enough.
> > >
> > > To the first goal, I wrote that reverse metric module a couple days
> > > ago as an example. I have to wonder when or even if it would have
> > > gotten written (or the equivalent feature added) otherwise. Instead
> > > I suspect it would just get added into N vendors models as people
> > > move on to other things in the WG.
> > >
> > > In a perfect world I would add a YANG section to my functionality
> > > RFC that updated (not augment) the base module, but with augment
> > > style definition (i.e., so the entire huge base module doesn't need
> > > to be re-represented in the document). This would then cause the
> > > base document to get reissued with the changes. Sort of like IANA
> > > sections are capable of updating a registry.
> >
> > > So maybe your github idea is like this, we create a module
> > > definition registry where the most up-to-date module definitions go,
> > > and then RFCs can update that using something like (or exactly like)
> > > augment to document the changes to the module in the individual
> > > RFCs.
> >
> Note that we can "gc" the submodules and fold their contents into the main
> module, or perhaps a "top" submodule, when you have N submodules.

True.

> Right.  This is longer term though, since it requires a process update!

Yes.

But, if we think that this is the right long term plan perhaps we should be writing up a draft to propose this to see what the WG reaction is?

Thanks,
Rob

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 2 Apr 2019 12:11:48 +0000

Hi Martin, 

On 4/2/19, 7:29 AM, "yang-doctors on behalf of Martin Bjorklund" <[email-masked] on behalf of [email-masked]> wrote:

    "Rob Wilton (rwilton)" <[email-masked]> wrote:
    > > better
    > > base

The alternative to individual modules we had discussed is to "batch" these features in a single document. However, once published, we'd start on the next set of optional features. 

From a programmability standpoint, which is preferred option? Are they all pretty much the same level of complexity? 

Thanks,
Acee

    > > ago as an

    

    /martin
    _______________________________________________
    yang-doctors mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/yang-doctors

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Tue, 2 Apr 2019 12:13:40 +0000

Hi Acee,

Perhaps Martin’s suggestion of using submodules is the pragmatic choice.

The base ISIS draft just contains a tiny module that only contains a list of submodule “includes with revision dates”.  The text for this tiny module can easily be rev’ed to add new submodules, and can probably be published as part of the extension RFC that adds the new submodule.

Most of the basic ISIS model goes into a “base ISIS functionality submodule”, to keep the base “includes with revision dates” module definition very concise.

Thanks,
Rob

From: Acee Lindem (acee) <[email-masked]>
Sent: 02 April 2019 13:06
To: Rob Wilton (rwilton) <[email-masked]>; Christian Hopps <[email-masked]>; YANG Doctors <[email-masked]>
Cc: Yingzhen Qu <[email-masked]>
Subject: Re: [yang-doctors] Small modules discussion from LSR [Fwd: [Lsr] When to augment LSR base YANG modules...]

Hi Rob,

Thanks,
Acee

From: yang-doctors <[email-masked]<mailto:[email-masked]>> on behalf of "Rob Wilton (rwilton)" <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, April 2, 2019 at 5:53 AM
To: Christian Hopps <[email-masked]<mailto:[email-masked]>>, YANG Doctors <[email-masked]<mailto:[email-masked]>>
Cc: Yingzhen Qu <[email-masked]<mailto:[email-masked]>>
Subject: Re: [yang-doctors] Small modules discussion from LSR [Fwd: [Lsr] When to augment LSR base YANG modules...]

Hi Chris,

Thanks,
Rob

From: yang-doctors <[email-masked]<mailto:[email-masked]>> On Behalf Of Christian Hopps
Sent: 01 April 2019 13:40
To: YANG Doctors <[email-masked]<mailto:[email-masked]>>
Cc: Yingzhen Qu <[email-masked]<mailto:[email-masked]>>
Subject: [yang-doctors] Small modules discussion from LSR [Fwd: [Lsr] When to augment LSR base YANG modules...]

Hi YANG Doctors,

So to quote Acee here:

Thanks,
Chris.

Begin forwarded message:

Hi Chris, Yingzhen,

Thanks,
Acee

   But why?

   Thanks,
   Chris.

Thanks,
Yingzhen

Rob and Acee:

Sue

r.

Thanks,
Acee

   Chris,

   Regards,
   Tony

Thanks,
Chris.

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 02 Apr 2019 14:15:40 +0200 (CEST)

> [RW] I'm not sure I see the difference.

Just less to update all the time.

Yes.

Yes.

> > main
> But, if we think that this is the right long term plan perhaps we
> should be writing up a draft to propose this to see what the WG
> reaction is?

Actually, Ignas is currently driving this.

/martin

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 2 Apr 2019 12:16:22 +0000

I’d be in favor of any option other than one where we start over and restructure the base models…

Acee

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Tuesday, April 2, 2019 at 8:14 AM
To: Acee Lindem <[email-masked]>, Christian Hopps <[email-masked]>, YANG Doctors <[email-masked]>
Cc: Yingzhen Qu <[email-masked]>
Subject: RE: [yang-doctors] Small modules discussion from LSR [Fwd: [Lsr] When to augment LSR base YANG modules...]

Hi Acee,

Thanks,
Rob

Hi Rob,

Thanks,
Acee

Hi Chris,

Thanks,
Rob

Hi YANG Doctors,

So to quote Acee here:

Thanks,
Chris.

Begin forwarded message:

Hi Chris, Yingzhen,

Thanks,
Acee

   But why?

   Thanks,
   Chris.

Thanks,
Yingzhen

Rob and Acee:

Sue

r.

Thanks,
Acee

   Chris,

   Regards,
   Tony

Thanks,
Chris.

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Tue, 2 Apr 2019 12:55:23 +0000

- Get YANG management support added at the same time as the functionality, not as an after thought maybe someday, maybe never.
 <RR> Chris, I think this is very important and should be "strongly encouraged". Now that many base YANG modules in routing etc are close to being published, new drafts should have YANG module included. E.g. draft-ietf-bfd-unsolicited. Unfortunately I don't think this is yet common practice.

Regards,
Reshad.