Subject: [netmod] NETCONF conformance for YANG modules

From: Andy Bierman <[email-masked]>
Date: Sun, 27 Jun 2010 10:25:06 -0700

Hi,

I am not proposing any changes to the YANG spec, but I think
more work is needed on conformance.  The current simplistic model
is extremely deficient in 3 ways:

  1) no way to have a mandatory-to-implement non-config leaf
     that is conditional on the description-stmt.
       - if mandatory=true then it MUST be in a non-filtered reply
       - if mandatory=FALSE then it is optional-to-implement
         by the server,
       - the client has no way to know if a config=false and
         non-mandatory object is implemented on a particular server
         from the <hello> message

  2) no way to allow read-only MIN-ACCESS for a config node
     as part of the conformance options.  Deviations are not
     allowed in standard modules, so they do not help.  They
     also indicate a lack of conformance, not a conformance option.

  3) no way to allow a subset of the complete syntax for a given
     leaf or leaf-list.  YANG features only control whether the node
     is allowed to exist or not.  Simple example: inet-address for
     which not all variants apply: YANG has no formal mechanisms
     to support even this well-known use-case.

I think it will be apparent as WGs try to use YANG,
just how unworkable the current conformance mechanisms are.
For now I am wondering if any usage guidelines are needed.

Andy

---

From: "Randy Presuhn" <[email-masked]>
Date: Sun, 27 Jun 2010 15:03:34 -0700

Hi -

> From: "Andy Bierman" <[email-masked]>
> To: "NETMOD Working Group" <[email-masked]>
> Sent: Sunday, June 27, 2010 10:25 AM
> Subject: [netmod] NETCONF conformance for YANG modules
...
>      also indicate a lack of conformance, not a conformance option.
...

This sounds like a feature to me.  In my opinion, the read-only MIN-ACCESS
was a big enabler (in the bad sense of "enabling" an addict) for implementors
wanting to claim conformance to MIB modules without providing for configuration.
Omitting this from YANG might be a bit of an over-correction, in that there may be
cases where this arguably useful, but we've already seen how having MIN-ACCESS
read-only as an option in MIB-land worked against standardized network
configuration management.

Randy

---

From: Andy Bierman <[email-masked]>
Date: Sun, 27 Jun 2010 15:48:53 -0700

> configuration management.

This is somewhat true, but often an application just needs to read some bit
of config-data to know how to do its job wrt/ that device.
Being able to read a standard config setting is better than nothing.

Standard CM is just as hard as before NETCONF/YANG.
Agreeing on the domain-specific knobs is the
first-order problem, and the IETF has never
addressed that very well.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 28 Jun 2010 17:09:36 +0200 (CEST)

Hi,

>        - if mandatory=FALSE then it is optional-to-implement

mandatory false does not mean that it is optional to implement.  In
some (most?) cases the difference doesn't matter though.

>      also indicate a lack of conformance, not a conformance option.

See Randy's reply.

>      is allowed to exist or not.

In Phil's and mine original proposal for features, we had this, but it
was rejected at the interim meeting.   I agree that this would be
useful...

/martin

---

From: Andy Bierman <[email-masked]>
Date: Mon, 28 Jun 2010 08:29:32 -0700

> some (most?) cases the difference doesn't matter though.

Yes it does for a non-config leaf.
It means the server never has to send the node -- ever.
That means every config=false data node, every
RPC output node and every notification node, unless they
are marked mandatory=true, do not have to be implemented.

>>      also indicate a lack of conformance, not a conformance option.

See my reply to Randy's reply.
I would love to be proven wrong by
seeing any meaningful standard CM data models
emerge from the IETF.  How many implementations
of the ipfix-psamp model exist?  Zero?
How many other YANG modules with any
writable objects at all?  Zero?
Sometimes this all-or-nothing approach backfires.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 28 Jun 2010 17:47:40 +0200 (CEST)

> are marked mandatory=true, do not have to be implemented.

Can you point me to where the YANG spec says that a server can choose
to not implement a mandatory false leaf?

As I wrote above, I agree that in some cases a valid implementation
strategy can be to not implement such a leaf, but it all depends on
the semantics of the leaf.

> Sometimes this all-or-nothing approach backfires.

I don't think the lack of deployed standard writable YANG models is
due to the coarse grained conformance model...

/martin

---

From: Andy Bierman <[email-masked]>
Date: Mon, 28 Jun 2010 09:24:38 -0700

> to not implement a mandatory false leaf?

If a vendor never ever has to return a node,
then how would the client know if it is implemented
or not?

Please explain to me why a config=false node
is mandatory to implement since it never has
to be returned by the server.

If it is optional to provide read access to a read-only
object, then 100% of the applicable NETCONF operations
are optional.

> the semantics of the leaf.

It is a great marketing strategy ;-)
"We implement every counter in the world,
except none of them can be retrieved.
A minor technicality."

> due to the coarse grained conformance model...

It is possible that 20 years of working on standardizing MIB
modules will have no relevance to YANG data modeling, but
I doubt it.  Getting vendors to agree on having a writable
object at all often required a read-only MIN-ACCESS or
there never would have been WG consensus to add the object.
If you take that bargaining chip off the table, the result
might be that the set of objects with WG consensus is near empty.
We shall find out eventually.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 28 Jun 2010 20:16:37 +0200 (CEST)

> then how would the client know if it is implemented

That's not the point.  You originally wrote that mandatory is a way to
do conformance; that mandatory false means that the node is optional
to implement.  I'm saying that this is not true.  Please see section
5.6 of the YANG spec - it doesn't mention mandatory.

> to be returned by the server.

It all depends on the semantics of the object, e.g.

  leaf enable-break-in-attempts-checking {
    type boolean;
    config true;
  }
  leaf break-in-attempts {
    type yang:counter32;
    config false;
    mandatory false;
  }

If enable-break-in-attempts-checking is implemented and set to true,
the server is still not free to simply not implement the counter.

[Sure, this can be modelled in other ways, but that's not the point]

/martin

---

From: Andy Bierman <[email-masked]>
Date: Mon, 28 Jun 2010 11:24:00 -0700

> 5.6 of the YANG spec - it doesn't mention mandatory.

When reading a YANG object, and there is no explanation
whatsoever when/why the server MUST return a value,
then the reader must assume there are no conditions
and it is completely up to the server implementor to decide.

> [Sure, this can be modelled in other ways, but that's not the point]

This is fine, except not quite for modules submitted to the IETF.
Every 'single config=false and non-mandatory' node needs
to explain in the description-stmt the conditions in which
the node MUST be available for retrieval.   This needs to be added
to the YANG usage spec.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Mon, 28 Jun 2010 11:34:39 -0700

>   leaf enable-break-in-attempts-checking {

 Add:

    when "../enable-break-in-attempts";

> [Sure, this can be modelled in other ways, but that's not the point]

I understand now -- the YANG guidelines need to make it
mandatory to provide the optionality conditions in a
description-stmt if a when-stmt is not applicable.

Andy

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 29 Jun 2010 11:00:58 +0200

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Martin Bjorklund
> Sent: Monday, June 28, 2010 6:48 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [netmod] NETCONF conformance for YANG modules
> 

...

> > How many implementations of the ipfix-psamp model exist?  Zero?
> I don't think the lack of deployed standard writable YANG 
> models is due to the coarse grained conformance model...
> 

Is not it too early to start drawing conclusions about the lack of
deployed standard writeable YANG models? We do not have the YANG RFC
published yet. No coordinated effort was started to develop standard
YANG models. Actually I start to become concerned that I do not see
activity on this respect here - there seem to be more interest to use
YANG to write models out of the netconf/netmod community than inside it.
We just have fragments in examples in the various I-Ds. Is anybody
working on the equivalent of MIB-II, Interfaces MIB, Entity MIB, etc. in
YANG? 

Dan

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 29 Jun 2010 21:05:50 +0200 (CEST)

"Romascanu, Dan (Dan)" <[email-masked]> wrote:
> published yet.

Exactly my point.

> No coordinated effort was started to develop standard

There is NACM (expect an update RSN) and Andy also published his
system module, which I hope we will discuss in Maastricht.  There is
some informal discussions about interface configuration going on as
well...  

/martin