Subject: [netmod] Schema node identifier MUST or MAY include schema nodes not part of the data tree (choice and case)

From: Vladimir Vassilev <[email-masked]>
Date: Tue, 16 Dec 2014 14:13:35 +0100

Hi,

I am wondering if the choice and case schema nodes MUST or MAY be part 
of a schema node identifier.

Example A schema node identifier without choice and case:

augment 
"/if:interfaces/if:interface/ethernet-switching:ethernet-switching/ethernet-switching:trunk-interface" 
{...}

Example B schema node identifier with choice and case:

augment 
"/if:interfaces/if:interface/ethernet-switching:ethernet-switching/ethernet-switching:port-mode-choice/ethernet-switching:trunk/ethernet-switching:trunk-interface" 
{...}

There is no requirement explicitly specified in the schema node 
identifier definition text 6.5 (RFC6020).

Logically the absence of choice and case nodes is not introducing 
ambiguity. The only practical use of having them is when the node 
identifier identifies choice or case node.

There are some YANG parser implementations that complain and at least 
one known to me that does not when choice and case are omitted.

Vladimir

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 16 Dec 2014 14:35:35 +0100 (CET)

Hi,

> of a schema node identifier.

The intention is MUST.

> ambiguity.

This is not correct.  Suppose you have:

  container x {
    choice a {
      case b;
    }
  }

  augment /x {
    leaf y;
  }

Does leaf y end up as /x/y or /x/a/b/y or /x/y/y?

So then you can say that you don't have to specify choice and case
nodes only if you have other nodes in there as well.  And in this
particular case do not treat the single leaf as a shorthand case.

Clearly there are no such rules in 6020.

/martin

---

From: Vladimir Vassilev <[email-masked]>
Date: Tue, 16 Dec 2014 15:13:55 +0100

Hi Martin,

>> of a schema node identifier.

Then you agree there is place for improvement in the 6.5 section?

> This is not correct.  Suppose you have:

It was more correct with the sentence that followed it: "Logically the 
absence of choice and case nodes is not introducing ambiguity. The only 
practical use of having them is when the node identifier identifies 
choice or case node."

> particular case do not treat the single leaf as a shorthand case.
I do agree. Your example presents the case of schema node identifier 
targeting a choice (or not). But in the cases where the case and choice 
are not the target nodes their notion is just an information overhead.

I am not saying the point of keeping schema node identifiers shorter is 
better then making life of parser developers easier. All I am saying is 
there is no clear definition in 6020 which can disambiguate the issue. 
And that is a problem that can be fixed.

Vladimir

---

From: Andy Bierman <[email-masked]>
Date: Tue, 16 Dec 2014 07:24:03 -0800

> Then you agree there is place for improvement in the 6.5 section?

The schema nodes include choice and case.
This is specified somewhere else, but sec. 6.5 does not
define a schema node.

> practical use of having them is when the node identifier identifies choice
> or case node."
>
>>
>>    container x {
>>      choice a {
>>        case b;
>>      }
>>    }
>>
>>    augment /x {
>>      leaf y;
>>    }
>>
> targeting a choice (or not). But in the cases where the case and choice are
> not the target nodes their notion is just an information overhead.
>
> there is no clear definition in 6020 which can disambiguate the issue. And
> that is a problem that can be fixed.
>

The choice and case nodes are always specified in a schema node identifier.
They are not the only schema nodes that do not have any corresponding instance
document nodes.  The rpc 'input' and 'output' nodes also appear in a schema-node
identifier but never in an instance document,

IMO the rules are clear.

> Vladimir

Andy

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