Subject: [yang-doctors] Features and must-condition

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Wed, 10 Jan 2018 21:04:25 +0000

Hi,

I am doing YD review of draft-ietf-pim-msdp-yang-01. The YANG module is small but relatively speaking there’s a big number of features 17. Basically each config knob has an if-feature.

However keepalive-interval has  a dependency on holdtime-interval via must statement. Is the only way to enforce this to add “if-feature peer-timer-holdtime” to leaf keepalive-internal?

Regards,
Reshad.

         leaf holdtime-interval {
           if-feature peer-timer-holdtime;
           type uint16;
           units seconds;
           must ". > 3";
           default 75;
           description "The SA-Hold-Down-Period of this msdp peer.";
         }
         leaf keepalive-interval {
           if-feature peer-timer-keepalive;
           type uint16;
           units seconds;
           must ". > 1 and . < ../holdtime-interval";
           default 60;
           description "The keepalive timer of this msdp peer.";
         }

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 10 Jan 2018 22:33:16 +0100 (CET)

Hi,

"Reshad Rahman (rrahman)" <[email-masked]> wrote:
> Hi,
> 
> I am doing YD review of draft-ietf-pim-msdp-yang-01. The YANG module
> is small but relatively speaking there’s a big number of features
> 17. Basically each config knob has an if-feature.
> 
> However keepalive-interval has a dependency on holdtime-interval via
> must statement. Is the only way to enforce this to add “if-feature
> peer-timer-holdtime” to leaf keepalive-internal?

Either that, or do:

      must "(not ../holdtime-interval)"
         + " or (. > 1 and . < ../holdtime-interval)";

depending on which combinations they want to support.

17 features seems quite a lot...

>            description "The keepalive timer of this msdp peer.";

/martin

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Wed, 10 Jan 2018 21:51:12 +0000

Thanks Martin. 

Yes 17 features is a lot for such a small module. I recall we had the per-counter feature a few months ago, that’s what basically this model is doing but per config.

Regards,
Reshad.

On 2018-01-10, 4:33 PM, "Martin Bjorklund" <[email-masked]> wrote:

    Hi,

    Either that, or do:

    

    /martin

---

From: Andy Bierman <[email-masked]>
Date: Wed, 10 Jan 2018 13:56:12 -0800

On Wed, Jan 10, 2018 at 1:51 PM, Reshad Rahman (rrahman) <[email-masked]>
wrote:

> Thanks Martin.
>
> Yes 17 features is a lot for such a small module. I recall we had the
> per-counter feature a few months ago, that’s what basically this model is
> doing but per config.
>
>
Seems the concepts and guidelines for YANG conformance are still very
unclear.
Are WGs thinking about the utility to the client developer,
or the ability for a server developer to claim conformance no matter what
they implement?

It seems unlikely that each leaf is completely independent of all others
wrt/ functionality.

> Reshad.

Andy

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

---

From: Ebben Aries <[email-masked]>
Date: Wed, 10 Jan 2018 15:01:31 -0700

Maybe this is a simple question but looking at these features, is this
really the intended proper use of 'feature'?

if-feature global-connect-source;
if-feature global-default-peer-policy;
if-feature global-default-peer;
if-feature global-sa-filter;
if-feature global-sa-limit;
if-feature global-ttl-threshold;
if-feature peer-admin-enable;
if-feature peer-as;
if-feature peer-connect-source;
if-feature peer-description;
if-feature peer-key-chain;
if-feature peer-sa-limit;
if-feature peer-timer-connect-retry;
if-feature peer-timer-holdtime;
if-feature peer-timer-keepalive;
if-feature rpc-clear-sa-cache;

Is it really expected that a network-element advertise features to this
degree (either capabilities/library) that a client now needs to handle a
complex matrix of feature/element mappings in order to generate specific
schemas that may wildly branch?

Multiply this by total quantity of modules on the network-element and we
could be potentially dealing w/ a large amount of features.  Based off
my experience, I don't think many folks are aware that common models
diverge into "vendor/platform" specific w/ things such as this

On Jan 10 22:33 PM, Martin Bjorklund wrote:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_yang-2Ddoctors&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=GIehbDpQlo31lSi6WbnEkA&m=aBisJd_9YYzR6N5-pRltfnJc9N2zHuiK6-TK5W-dx1I&s=qT9UUmnJuEAZgPli4oUG-SDeE8bzhSWR5TPTwsboSKU&e=

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Wed, 10 Jan 2018 22:04:34 +0000

Even if completely independent, it is very messy for the client as you mentioned.

From: 'Andy Bierman' <[email-masked]>
Date: Wednesday, January 10, 2018 at 4:56 PM
To: "Reshad Rahman (rrahman)" <[email-masked]>
Cc: Martin Bjorklund <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [yang-doctors] Features and must-condition

On Wed, Jan 10, 2018 at 1:51 PM, Reshad Rahman (rrahman) <[email-masked]<mailto:[email-masked]>> wrote:
Thanks Martin.

Seems the concepts and guidelines for YANG conformance are still very unclear.
Are WGs thinking about the utility to the client developer,
or the ability for a server developer to claim conformance no matter what they implement?

It seems unlikely that each leaf is completely independent of all others wrt/ functionality.

Regards,
Reshad.

Andy

On 2018-01-10, 4:33 PM, "Martin Bjorklund" <[email-masked]<mailto:[email-masked]>> wrote:

    Hi,

    Either that, or do:

    /martin

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

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Wed, 10 Jan 2018 22:06:00 +0000

I don’t believe this was the intent, but this is how it’s being used so that implementations can claim compatibility….

On 2018-01-10, 5:01 PM, "Ebben Aries" <[email-masked]> wrote:

---

From: Ebben Aries <[email-masked]>
Date: Wed, 10 Jan 2018 15:26:10 -0700

Claiming compatibility does not mean consumers will want or adopt imo.

So far, I've noticed that each set of authors can tackle what they can
and can't support via multiple techniques (obviously bound to their
respective organizations implementations)

- feature/if-feature
- shallow base models that call for augments
- deeper base models that require deviations
- probably a few others I can't think of off the top of my head

If one model implements a heavy feature based technique, this diverges
from the design of another model that implements another technique.  If
we look at an entire collection that would comprise the network-element,
we'll find that we have all techniques in use which lead to more pain
and an inconsistent design from what is generally looked at as a single
organization to a consumer.

Apologies if this has been brought up before and am beating something
into the ground...

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 10 Jan 2018 23:38:01 +0100

> Apologies if this has been brought up before and am beating something

There is no tight coordination how we do things across areas and
working groups, the best we can do is to write BCPs after having
gained experience (we react with years of delay to things that went
wrong) and to ask questions as part of the review procedures. All we
have here is the text in 4.17. of draft-ietf-netmod-rfc6087bis-15.txt
and perhaps we have better text in a future update of this BCP.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Andy Bierman <[email-masked]>
Date: Wed, 10 Jan 2018 14:49:48 -0800

> and perhaps we have better text in a future update of this BCP.

The feature-per-leaf approach should not be approved by YD.
The intent of if-feature, and usage in most cases, is less granular.
It may never be easy to decide what should be bundled as a feature,
but making every leaf a feature is no decision at all.

The use of deviate not-supported should be encouraged instead of
if-feature on every leaf.

IMO the conformance leaf in the YANG library should be kept,
and expanded.  I lobbied for 'other' and it never got added.
What about 'partial-implement'?  IMO it is better to tell the client
some objects are implemented, rather than ignore the module
unless it is fully implemented,

/js
Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 11 Jan 2018 00:28:30 +0100

> but making every leaf a feature is no decision at all.

Well, likely a WG trying to avoid the painful process to come to hard
decisions.

> if-feature on every leaf.

I think there is no general and simple answer. While if-feature on
every leaf is likely a failure, less extreme cases may still hide
failures to find agreement and generally are difficult to spot. (We
all know that a strong participant can find ways to push a feature
even if the vast majority of implementations would not need it.)  The
yang doctors can't help with this since we are typically not familiar
with the details of the technology being modeled. So at the end, it is
the WGs that are responsible for the YANG modules they produce and
ultimately the market will decide whether a module is usable or not.

> unless it is fully implemented,

We do have deviations but some organizations do not like using them.
I am not sure inventing something less explicit will be much more
successful. What does a client do with 'partial-implement'?

I really like packages: I like the idea of creating meaningful bundles
of modules and features that allows human operators to determine
relatively easily whether clients and servers can work together
without having to understand hundreds of modules and their
feartures.

/js

---

From: Ebben Aries <[email-masked]>
Date: Fri, 12 Jan 2018 17:34:41 -0700

> It seems unlikely that each leaf is completely independent of all others

Note, that looking through some published models, we already have a few
cases w/ single modules that contain up to 20 features (a few examples)

RFC8049 - [email-masked]
RFC6728 - [email-masked]

So I know for the module Reshad is talking about here, we are telling
the module writers that 17 is too many (and the way they are using such)
but it sounds like we need to have folks focus on the usability aspects
a bit more.  If we consider a client workflow that doesn't reach out to
the network-elements/library to discover features, the client needs a
way to absorb a fully populated list per platform/version out of band to
feed into compilation of what will be potentially greatly differing
trees.

I think it's difficult to put a number against this and tell the module
writer some amount is too many but rather consider the usability beyond
your specific focus model.

The aim should be for adoption but at certain points as a consumer I
would question common model usability in this fashion vs.
vendor/platform specific models that will theoritically have 100%
coverage.

> > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_yang-2Ddoctors&d=DwIFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=GIehbDpQlo31lSi6WbnEkA&m=Jl7tZIAix_56L5WitYmizrVtr4lri1GbY_gryWn2Zw4&s=-d8gjIFa6ZWhaMxzPnGU2M3QQbXsGpEJ9E7s5VdLuBU&e=
> >

> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_yang-2Ddoctors&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=GIehbDpQlo31lSi6WbnEkA&m=Jl7tZIAix_56L5WitYmizrVtr4lri1GbY_gryWn2Zw4&s=-d8gjIFa6ZWhaMxzPnGU2M3QQbXsGpEJ9E7s5VdLuBU&e=

---

From: Benoit Claise <[email-masked]>
Date: Tue, 16 Jan 2018 18:03:05 +0100

>> The feature-per-leaf approach should not be approved by YD.
Do we want to add a sentence in 
https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-15#section-4.17, 
expressing that a feature-per-leaf is most likely the wrong approach?

Regards, Benoit

---

From: Ebben Aries <[email-masked]>
Date: Tue, 16 Jan 2018 10:25:56 -0700

On Jan 16 18:03 PM, Benoit Claise wrote:
> Do we want to add a sentence in https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dnetmod-2Drfc6087bis-2D15-23section-2D4.17&d=DwICaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=GIehbDpQlo31lSi6WbnEkA&m=nQGeE0OfNIkUQ28OwBMtTNK_yfuu6lvybq_d4HmVgcQ&s=-Fcnf3yjcv4zOig-zswod3QT1HuorecwuFZpuT0VJm4&e=,

There likely needs to be some wording around using good judgement while
taking into account how this will be consumed and used.  A feature per
container can also be a bad idea if this turns out to be excessive.  How
many is too many?

If we fast fwd a few yrs and assume we cover the entire network-element,
are we going to end up w/ 1000s of possible features that need to be
conveyed and handled?

Thx

/ebben

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 16 Jan 2018 18:43:23 +0100

> expressing that a feature-per-leaf is most likely the wrong approach?

This is difficult to describe. Perhaps something like this is a
reasonably small change to the existing text (which only talks about
too big features but not about too small features).

OLD

   The YANG "feature" statement is used to define a label for a set of
   optional functionality within a module.  The "if-feature" statement
   is used in the YANG statements associated with a feature.

   The set of YANG features available in a module should be considered
   carefully.  The description-stmt within a feature-stmt MUST specify
   any interactions with other features.

   If there is a large set of objects...

NEW

   The YANG "feature" statement is used to define a label for a set of
   optional functionality within a module.  The "if-feature" statement
   is used in the YANG statements associated with a feature.  The
   description-stmt within a feature-stmt MUST specify any
   interactions with other features.

   The set of YANG features defined in a module should be considered
   carefully. Very fine granular features increase interoperability
   complexity and should be avoided. A likely misuse of the feature
   mechanism is the tagging of individual leafs (e.g., counters) with
   separate features.

   If there is a large set of objects...

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Tue, 16 Jan 2018 18:26:50 +0000

This change seems reasonable to me.

On 2018-01-16, 12:43 PM, "Juergen Schoenwaelder" <[email-masked]> wrote:

    
    OLD

    
    
    NEW

    
    
    /js

---

From: Benoit Claise <[email-masked]>
Date: Wed, 24 Jan 2018 14:49:58 +0100

Hi Jürgen,

I like it.
I'm busy with the RFC6087bis AD review and it will be part of the feedback.

Regards, Benoit

---

From: Benoit Claise <[email-masked]>
Date: Wed, 24 Jan 2018 14:54:11 +0100

Btw, along the same lines, in section 4.5

OLD:
    If a data definition is optional, depending on server support for a
    NETCONF or RESTCONF protocol capability, then a YANG 'feature'
    statement SHOULD be defined to indicate that the NETCONF or RESTCONF
    capability is supported within the data model.

NEW:
    If a feature or a set of data definitions is optional, depending on server support for a
    NETCONF or RESTCONF protocol capability, then a YANG 'feature'
    statement SHOULD be defined to indicate that the NETCONF or RESTCONF
    capability is supported within the data model.

It will also be in my AD review email.

Regards, B.

---

From: Mahesh Jethanandani <[email-masked]>
Date: Wed, 24 Jan 2018 10:49:33 -0800

How does one define a feature statement that indicates support for NETCONF or RESTCONF protocol capability? I thought feature statements were for features within the module.

> On Jan 24, 2018, at 5:54 AM, Benoit Claise <[email-masked]> wrote:
> 
>>>> https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-15#section-4.17 <https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-15#section-4.17>, 

Mahesh Jethanandani
[email-masked]

---

From: Ebben Aries <[email-masked]>
Date: Wed, 24 Jan 2018 20:50:38 -0700

I think this change looks good

On Jan 16 18:43 PM, Juergen Schoenwaelder wrote:
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dnetmod-2Drfc6087bis-2D15-23section-2D4.17&d=DwIBAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=GIehbDpQlo31lSi6WbnEkA&m=coUU0hud2Ev6mARcSeDrSXnjLioAu_TOiWqw0BDn_c4&s=yaqHtXjjzMi643nHVelr4Zq0_YelOsvOMfEMImH4NHE&e=,
> Fax:   +49 421 200 3103         <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.jacobs-2Duniversity.de_&d=DwIBAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=GIehbDpQlo31lSi6WbnEkA&m=coUU0hud2Ev6mARcSeDrSXnjLioAu_TOiWqw0BDn_c4&s=TlDlQ41jN97aNeLJGGDlYf6DPYwdLss2UmogmWbTPTU&e=>

---

From: Ebben Aries <[email-masked]>
Date: Wed, 24 Jan 2018 21:24:45 -0700

I'm not sure I understand the intent of the newly proposed text

I'm reading this as now stating that if a 'feature' is optional, then a
'feature' should be defined.  I think the old text was mostly correct in
what is trying to be conveyed.

How about something like:

   If a data definition is optional which depends on server support then
   a YANG 'feature' statement SHOULD be defined and conveyed through a
   NETCONF or RESTCONF protocol capability.  The defined 'feature'
   SHOULD then be used in the conditional 'if-feature' statement
   referencing the optional data definition.

On Jan 24 10:49 AM, Mahesh Jethanandani wrote:
> >>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dnetmod-2Drfc6087bis-2D15-23section-2D4.17&d=DwIFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=GIehbDpQlo31lSi6WbnEkA&m=7ZRQ7cSbMoQOwcUvfJf7Q1kdto8zoglQ4ZHXDURQl3s&s=uU5M6cHYuTrKiyxOMMI8MKvBIpYS_yg1VSIYI4MfxKo&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dnetmod-2Drfc6087bis-2D15-23section-2D4.17&d=DwIFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=GIehbDpQlo31lSi6WbnEkA&m=7ZRQ7cSbMoQOwcUvfJf7Q1kdto8zoglQ4ZHXDURQl3s&s=uU5M6cHYuTrKiyxOMMI8MKvBIpYS_yg1VSIYI4MfxKo&e=>, 
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_yang-2Ddoctors&d=DwIFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=GIehbDpQlo31lSi6WbnEkA&m=7ZRQ7cSbMoQOwcUvfJf7Q1kdto8zoglQ4ZHXDURQl3s&s=Uah4DbYVrvtZTrkciA0m1OfOgmwMXrRg_tjGmG0iX8I&e=
> 
> Mahesh Jethanandani
> [email-masked]
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 25 Jan 2018 08:28:04 +0100

It is not clear what the intention of this paragraph is (was). It is
unchanged from RFC 6087. The paragraph could mean multiple
things. First interpretation:

   If a collection of data definitions is optional, then a YANG
   'feature' statement SHOULD be defined. The YANG library then
   indicates whether the optional definitions are supported by a
   server.

This is just restating how features work but perhaps this was the
intention in order to put the following text into some context. The
text could also mean this:

   If a data definition is optional and it depends on a NETCONF
   protocol capability, then a YANG 'feature' statement SHOULD be
   defined to indicate that the definition depends on a NETCONF
   capability.

This would be a discussion of a very specific case and not really
helpful in a BCP, except if it would be intended as an example (but
there is no indication for this).

Whatever we do with this paragraph, we should avoid talking about
protocol specifics and we should point to YANG library instead of
talking about protocol capabilities.

My proposal would be to either replace the paragraph with the first
interpretation given above or to delete it entirely.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 25 Jan 2018 08:32:59 +0100 (CET)

Hi,

> what is trying to be conveyed.

This was also my reaction to the new text.

>    referencing the optional data definition.

Or keep the protocol thing out of this text; this is a guideline to
the *model writer*.

    If a data definition is optional which depends on server support then
    a YANG 'feature' statement SHOULD be defined.  The defined 'feature'
    SHOULD then be used in the conditional 'if-feature' statement
    referencing the optional data definition.

/martin