Subject: Re: [netmod] Y09 introduce optional keys

From: David Reid <[email-masked]>
Date: Thu, 04 Sep 2014 10:17:05 -0400

> Here is a proposal for how to introduce optional keys.

Adding optional keys seems like a pretty major new feature for 
a .1 release. Most of the other issues are fixes or clarifications.
Is the benefit worth the cost?

-David Reid

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 04 Sep 2014 21:21:52 +0200 (CEST)

> Is the benefit worth the cost?

I don't think the cost is that high.  With YANG 1.0, people are forced
to use awkward workarounds, and/or vendor-specific extensions to
support a use case that seems to be natural in many circumstances.
Thus, I think it is better to support this natively.  (Incidentally,
just today I got a question from someone involved in the broadband
forum work why YANG doesn't support optional keys).

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 4 Sep 2014 22:38:18 +0200

> forum work why YANG doesn't support optional keys).

Martin,

can you detail how will instance-identifier look like that deal with
optional keys? I assume this is the biggest change Y09 would cause,
no?

/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: Thu, 4 Sep 2014 13:40:50 -0700

> forum work why YANG doesn't support optional keys).

I think the implementation impact is significant, but the feature could be
useful.
The protocol complexity increase is worse that the compiler.
What about adding optional keys to an existing entry?
IMO this cannot be supported with either RESTCONF or NETCONF.
The request will be seen by the server as a create, merge, or replace on
a new resource instance.

Even if the protocols supported that, multiple clients adding/deleting key
leafs to
the same entry at once seems complicated to get right.
IMO, a client has to delete an entry and add it back in order to change its
instance-identifier value.

> /martin

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 05 Sep 2014 09:16:45 +0200 (CEST)

> optional keys? I assume this is the biggest change Y09 would cause,

We talked about two options, easiest to examplify with this data
model:

  list foo {
    key "a b";
    leaf a {
       type string;
       mandatory true;
    }
    leaf b {
       type string;
       mandatory false;
    }

and these instances:

  <foo>
    <a>1</a>
  </foo>
  <foo>
    <a>1</a>
    <b>2</b>
  </foo>

Option A:

  /foo[a=1]
  /foo[a=1][b=1]

Option B:

  /foo[a=1][not b]
  /foo[a=1][b=1]

Both these options are still valid XPath expressions.

Option A has the advantage of having the same syntax as before, but
the disadvantage that if the instance identifier is used in an XPath
filter in e.g., NETCONF, the example of "/foo[a=1]" will return both
instances in this example.

Option B has the advantage that if used as an XPath filter, it will
return the exact instance and nothing more, but has the drawback of
not being syntactically the same as before.

I don't think this will pose a problem to a server; if it implements
YANG 1.1 with any data model that has optional keys, it will have to
support this new syntax.

For an old client it might pose a problem if it interprets the i-i:s it
receives from a 1.1 server that has such instances.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 05 Sep 2014 09:16:59 +0200 (CEST)

> The request will be seen by the server as a create, merge, or replace on

Right, and I think this is ok.  In general it would be nice with a
'rename' operation in the protocols, but that is a different issue.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 5 Sep 2014 22:49:31 +0200

On Fri, Sep 05, 2014 at 09:16:45AM +0200, Martin Bjorklund wrote:

[...]

> Both these options are still valid XPath expressions.

[...] 
 
> YANG 1.1 with any data model that has optional keys, it will have to

The instance-identifier is a type that has been used by other
modules. For example, ietf-netconf-monitoring has a leaf-list
locked-node of type instance-identifier. So how do I know whether a
certain server implements the old syntax of instance-identifier or the
new one? The node-instance-identifier module introduces a type
node-instance-identifier which is derived from xpath (so that is fine)
but the description refers to YANG instance identifiers:

       A node-instance-identifier value is an
       unrestricted YANG instance-identifier expression.
       All the same rules as an instance-identifier apply
       except predicates for keys are optional.  If a key
       predicate is missing, then the node-instance-identifier
       represents all possible server instances for that key.

Well, this does not seem really harmful but still, can you tell
whether a certain NACM implementation will accept syntax option B?

So is this really something we should do in 1.1 or something to put on
the candidate list of a future YANG 2.0 version?

> receives from a 1.1 server that has such instances.

I assume it is quite possible that there are clients that do parse
instance-identifiers.

/js

---

From: Andy Bierman <[email-masked]>
Date: Fri, 5 Sep 2014 14:08:11 -0700

> whether a certain NACM implementation will accept syntax option B?

NACM implementations will reject (b) because it is not a valid
schema-instance-identifier.
But they will treat option (a) (missing key) as a match on all instances
with that value.

> the candidate list of a future YANG 2.0 version?

IMO it would be OK to defer this feature until YANG 2.0.
There is a simple workaround, which is to define a value for the optional
key
that means "not used",  This is usually possible.

> > receives from a 1.1 server that has such instances.
It will not be accepted if the tool implements the RFC correctly.
I think it will break old clients, which violates 1 of our main design
goals.

> instance-identifiers.

yes -- implemented according to the RFC. The value is checked to
see that only the correct predicates are present.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 08 Sep 2014 10:43:42 +0200 (CEST)

Juergen Schoenwaelder <[email-masked]> wrote:
> new one?

ietf-netconf-monitoring is a YANG 1.0 module, so until it is revised
and updated to YANG 1.1 it will only support the old syntax.

> The node-instance-identifier module introduces a type

Same as above.

> the candidate list of a future YANG 2.0 version?

I don't think it would be easier or better to do this in YANG 2.0.

This is essentially an update of an existing type, and the update
rules of YANG modules allow this (ok, this isn't a YANG module that is
being updated, but similar).  If we don't think that we can make these
kind of changes in this case, can we *ever* allow an update of any
type?

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 8 Sep 2014 13:28:50 +0200

> kind of changes in this case, can we *ever* allow an update of any

I am not that sure the update rules cover this. Can you point to the
relevant text? The question at the end of the day is whether the
market will expect that a fundamental type changes in a 1.1 release.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 08 Sep 2014 13:32:02 +0200 (CEST)

> market will expect that a fundamental type changes in a 1.1 release.

Section 10 has this:

   o  A "range", "length", or "pattern" statement may expand the allowed
      value space.

In this case, we're expanding the value space of an existing type.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Mon, 8 Sep 2014 06:18:34 -0700

> In this case, we're expanding the value space of an existing type.

There are type sub-statements.
IMO this change breaks implementations of the instance-identifier base type.
NACM does not support the new syntax. It doesn't make sense to have
some objects use 1 type of instance-identifier and other objects use a
different type.
The <error-path> field is also not specific to 1 module. This new feature
breaks
existing implementations.  It should be rejected unless it is 100% backward
compatible with any possible use of an instance-identifier leaf in YANG 1.0.

Andy

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

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 08 Sep 2014 15:36:47 +0200 (CEST)

> There are type sub-statements.

How is the fact that it is a base type different from the same
situation for a derived type?

> The <error-path> field is also not specific to 1 module.

No, error-path is not an instance-identifier, it is an XPath expression.

> This new feature

My point is that if we believe that this is a problem now for this
particular type, why do we think that it is ok to extend the value
space for a derived type?

/martin

---

From: Andy Bierman <[email-masked]>
Date: Mon, 8 Sep 2014 08:03:26 -0700

On Mon, Sep 8, 2014 at 6:36 AM, Martin Bjorklund <[email-masked]> wrote:

> > > > > > So is this really something we should do in 1.1 or something to
> put
> > > on

The only allowed restriction for an instance-identifier is the
"require-instance"
sub-statement. (9.13.1)  I don't see how "range", "length", or
"pattern" have anything to do with instance-identifier.

> No, error-path is not an instance-identifier, it is an XPath expression.
It is s node-instance-identifier which has specific rules about what
predicates
are allowed.  The proposed [not foo] syntax is not allowed by this derived
type.

> space for a derived type?
The instance-identifier has specific rules that are not followed by this
proposal.
Changing a base type in a way that breaks existing tools is not acceptable,
according to our own guidelines for YANG 1.1.

IMO this is not a problem, this is a new feature.

Andy

---

From: Balazs Lengyel <[email-masked]>
Date: Tue, 9 Sep 2014 16:09:54 +0200

Hello Martin,
If instance identifier was just a string it would be OK to extend its 
value space, but i-i has a rather strict connection to other 
leafs/lists/containers in the model and a fixed internal structure. 
These rules would be changed beside expanding the value space. IMHO 
applications might be parsing the i-i following the yang 1.0 rules; i-is 
that can point to anything, not just to specific models. So this would 
mean that if you want to implement any yang 1.1 model you need to 
upgrade these applications e.g. NACM too.
regards Balazs

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
ECN: 831 7320                        Tel: +36-1-437-7320
Mobile: +36-70-330-7909              email: [email-masked]