Subject: [netmod] VRFY :Y09: introduce optional keys

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 7 Jan 2015 15:32:16 +0100

The 2014-12-03 virtual interim meeting proposal is to adopt Y09-03.
Please speak up by Wednesday 2015-01-14 if you disagree with this
proposal.

For more details, see the issues list and the virtual interim meeting
minutes available here:

     http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/

-- 
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, 7 Jan 2015 06:58:37 -0800

Hi,

I object to Y09-3.
In YANG 1.0 a default on a key leaf is ignored.
The exact same module parsed as YANG 1.1 does not ignore the
default on a key leaf.  Providing 1 leaf is supposed to be an error
and all of a sudden it is not and creates an entry with the automatic key.
This is not what the YANG 1.0 client is expecting.

Also, when defaults are suppressed in <get-config> or <get> replies,
do the key leafs that match defaults get suppressed?  This would also
break a YANG 1.0 client.

Andy

On Wed, Jan 7, 2015 at 6:32 AM, Juergen Schoenwaelder
<[email-masked]> wrote:
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

---

From: Andy Bierman <[email-masked]>
Date: Wed, 7 Jan 2015 08:56:08 -0800

Hi,

There is a difference between backward compatibility at compile-time
and run-time.
The former means that a YANG 1.0 module still compiles OK if parsed as if
it were a 1.1 module. The latter means a YANG 1.0 module still behaves the same
within a 1.1 server implementation.  Both are required.

There is a solution to fix Y09-3.
Add a new statement instead of redefining key-stmt.
Was this considered?

What if the designer does not want a list to automatically instantiate entries?
How is this accomplished?

  typedef X {
     type int32;
     default 42;
  }

  list broken {
     key x;
     leaf x { type X; }
     leaf y { type string; mandatory true; }
  }

Does the server automatically create a default entry for x=42?
If so, then isn't the mandatory-stmt violated immediately?
Are must-stmts in the default key leaf evaluated?

Are <edit-config> requests for list "broken" allowed to omit the <x>
leaf?  Is the server supposed to fill in x=42 in such cases?

Seems like "key" 1.0 needs to be preserved, even if "key2" is added.
This would also prevent YANG 1.0 lists from magically changing
run-time behavior.

Andy

---

From: David Reid <[email-masked]>
Date: Wed, 07 Jan 2015 16:03:51 -0500

> Please speak up by Wednesday 2015-01-14 if you disagree with this

I prefer to NOT introduce optional keys. If we do add them, I think -03 is 
the best solution.

-David Reid

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 08 Jan 2015 10:21:57 +0100 (CET)

Hi,

> The 2014-12-03 virtual interim meeting proposal is to adopt Y09-03.

The reasons for proposing Y09-03 (instead of Y09-02) were:

  1. The instance-identifier syntax proposed in Y09-02 doesn't work,
     b/c empty strings and 0-values integers would also return "true"
     in the expression "not(key)".

  But this turned out to be a false claim; the syntax proposed in
  Y09-02 is correct.

  2. Y09-02 is tricky to implement in "common databases", since they
     require values for all keys.

  But the idea for how to handle Y09-03 in these databases was to
  store additional info that the default value is set.  The same
  technique can be used to handle purely optional keys.

Thus, I prefer Y09-02.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 8 Jan 2015 11:22:45 +0100

> On 08 Jan 2015, at 10:21, Martin Bjorklund <[email-masked]> wrote:
> 
> Hi,
> 

In some common databases (e.g. mongodb) a declaration of a key is just an instruction for the server to generate an index. I think it is more a limitation of NETCONF’s edit-config design.

An implication for both Y09-02 and Y09-03 is that if a key is not set at the time a list entry is created, it cannot be set afterwards. 

>  technique can be used to handle purely optional keys.

Me too, Lada

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 8 Jan 2015 16:27:01 +0100

> On 08 Jan 2015, at 16:19, Andy Bierman <[email-masked]> wrote:
> 
> On Thu, Jan 8, 2015 at 2:22 AM, Ladislav Lhotka <[email-masked]> wrote:
>> 
> Neither solution works.
> I agree with David that they should not be added at all to YANG.
> 
> Please answer the questions below wrt/ how lists with default keys work:
> 

No, it doesn’t, see Y09-02: "All key leafs can be optional, but a list instance MUST have at least one of the key leafs instantiated, …”.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Thu, 8 Jan 2015 07:19:39 -0800

Neither solution works.

  typedef X {
     type int32;
     default 42;
  }

  list broken {
     key x;
     leaf x { type X; }

Andy

---

From: "Peyman Owladi -X (powladi - Ensoft Ltd at Cisco)" <[email-masked]>
Date: Fri, 9 Jan 2015 10:29:15 +0000

> -----Original Message-----
> From: netmod [mailto:[email-masked]] On Behalf Of Andy Bierman
> Sent: 08 January 2015 15:20
> To: Ladislav Lhotka
> Cc: [email-masked]
> Subject: Re: [netmod] VRFY :Y09: introduce optional keys
> 
> > In some common databases (e.g. mongodb) a declaration of a key is just
> an instruction for the server to generate an index. I think it is more a
> limitation of NETCONF’s edit-config design.
> >
> > An implication for both Y09-02 and Y09-03 is that if a key is not set
> at the time a list entry is created, it cannot be set afterwards.
> >
> >>

I think that as well as not having any downsides, Y09-02 actually addresses the set of issues better than Y09-03; sometimes there isn't a default that makes sense, in which case adding absence to the value space of a key is important.

> I agree with David that they should not be added at all to YANG.

Is the key concern here the handling of default values?

> How is this accomplished?

If we do have defaults, I would have thought that having a default value for a key shouldn't mean a list entry is automatically instantiated -- i.e. there should still be no list entries until they are explicitly created.

Perhaps this could be made explicit by requiring that at least one key has no default value?

> leaf?  Is the server supposed to fill in x=42 in such cases?

Per RFC6020 section 7.6.1:

   "... if the leaf's type has
   a default value, and the leaf is not mandatory, then the leaf's
   default value is the type's default value.  In all other cases, the
   leaf does not have a default value."

So in this example, since the leaf is mandatory, the default value is ignored, and the client must specify a value. (Otherwise this same problem would apply to any leaf in the list.)

Cheers,
Peyman

---

From: Andy Bierman <[email-masked]>
Date: Fri, 9 Jan 2015 02:52:16 -0800

Hi,

I do not think this is a minor change to YANG so it is
inappropriate for a minor update.

Solutions which alter the instance-identifier data type will
break NACM and this is also not a minor update change.

I do not know of any real use-cases in which a value
cannot be selected that means not-in-use.  The "union"
data-type can almost always be used to create a typedef
for this purpose.

There is no real operational need to suppress sending
a few key leafs during a "create" operation.  NETCONF
is not optimized for small message size in any way.

I do not think that lack of optional keys is a bug in YANG
and therefore it should not be part of YANG 1.1 at all.

Andy

On Fri, Jan 9, 2015 at 2:29 AM, Peyman Owladi -X (powladi - Ensoft Ltd

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 09 Jan 2015 13:20:02 +0100 (CET)

Hi,

> break NACM and this is also not a minor update change.

It is correct that in order to use YANG 1.1 optional keys w/ NACM,
NACM needs to be updated to YANG version 1.1.

But this update may happen anyway - see
http://www.ietf.org/mail-archive/web/netconf/current/msg09669.html

> cannot be selected that means not-in-use.

As soon as the key has type 'string', you need to pick an "unlikely"
value, e.g. the empty string or some weird string like "$__$".  This
is not very pretty.

Also, one reason for YANG's success so far is that it is possible to
closely follow the native (CLI) interface on the devices.  (compare w/
MIBs).  Many CLIs have the concept of optional keys, and it is pretty
natural concept.

> is not optimized for small message size in any way.

This is not the reason; the reason is that the resulting model is more
"direct" and clear, with less noise.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Fri, 9 Jan 2015 05:34:04 -0800

> value, e.g. the empty string or some weird string like "$__$".  This

It should be easy to pick the zero-length string since this
should never be used as an identifier string in a key.
There are no use cases where zero-length string is an important
value.

> MIBs).  Many CLIs have the concept of optional keys, and it is pretty

It is a big change and is not really needed.
CLI is ad-hoc and non-standard.  Not sure why it is relevant here.

> "direct" and clear, with less noise.

So it is slightly more elegant than the existing workaround.
IMO that is not worth much.  Unlike if-feature expressions,
you have not come up with a single example that cannot
easily be accomplished with YANG 1.0.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 09 Jan 2015 14:49:51 +0100 (CET)

> easily be accomplished with YANG 1.0.

I argue that using dummy values that means that the key really doesn't
exist is not "easily accomplished".  But here's an example from a
previous email:

  list address {
    key "ip vrf";
    leaf ip { ... }
    leaf vrf {
      if-feature vrf;
      ...
    }
    ...
  }

Even without the if-feature statement, this gets ugly in YANG 1.0.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Fri, 9 Jan 2015 06:43:20 -0800

Hi,

I do not support this new feature at all, but Y09-03 is the
least objectionable solution.  Y09-02 is unacceptable
because it requires changing a base type.

IMO the list below should be redesigned so feature-dependent data
is not part of the key.  It is not hard to pick empty string as "no VRF".

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 9 Jan 2015 16:03:37 +0100

> On 09 Jan 2015, at 15:43, Andy Bierman <[email-masked]> wrote:
> 
> Hi,
> 

Which base type?

> is not part of the key.  It is not hard to pick empty string as "no VRF”.

Y09-02 or -03 would allow for an elegant solution to the problem of the key for static routes that was discussed in relation to the routing module. Currently the static-route list uses only “destination-address” as the key but it is conceivable that it will be necessary to support multiple routes with the same destination address. As a new key leaf cannot be added later, a solution might be to add a dummy key now, e. g. a numeric “id” that could be used for discriminating entries where necessary. But it only makes sense if the “id” key part was optional because adding a unique number to every route is a nuisance.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Fri, 9 Jan 2015 07:12:39 -0800

>> because it requires changing a base type.

instance-identifier

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 9 Jan 2015 16:21:53 +0100

> On 09 Jan 2015, at 16:12, Andy Bierman <[email-masked]> wrote:
> 

OK, but is only a minor extension, and doesn’t change the semantics of the existing uses. Easy to do, IMO.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Fri, 9 Jan 2015 08:50:56 -0800

> OK, but is only a minor extension, and doesn’t change the semantics of the existing uses. Easy to do, IMO.

I do not agree that it is minor at all.
It would significantly impact the server design and implementation
which assumes that all list instances use all keys.

Both solutions undo this MUST in 7.8.2:

 All key leafs MUST be given values when a list entry is created.

IMO this enhancement is minor in value but major in system
and conformance impact.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 9 Jan 2015 17:57:23 +0100

> On 09 Jan 2015, at 17:50, Andy Bierman <[email-masked]> wrote:
> 

My comment was about the extension of instance-identifier syntax and their interpretation. Otherwise I agree that the changes induced by optional keys may be non-trivial.

Lada