Re: [netmod] YANG action not allowed at root?

[Per Hedeland]

On 2020-05-05 11:55, Juergen Schoenwaelder wrote:
> On Tue, May 05, 2020 at 11:45:41AM +0200, Per Hedeland wrote:
>> On 2020-05-05 11:00, Martin Björklund wrote:
>>> Hi,
>>>
>>> If we were to redo YANG, I would prefer to have a single statement
>>> "operation", either on the top-level, or tied to a node.
>>
>> So, no rpc statement, and thereby no possibility to extend NETCONF
>> with new RPCs? (Or to be precise, YANG would extend NETCONF with
>> exactly one RPC, called "operation"?)
>>
>
> OLD
>
>   rpc foo {}
>   list something { action bar {} }
>
> NEW
>
>   operation foo {}
>   list something { operation bar {} }

Yes, that much is obvious, my question was really about the NETCONF
encoding.

> Syntactic sugar if you will.

So you're saying that the NETCONF encoding of "operation foo" at the
top level would be an RPC called "foo", while the NETCONF encoding of
"operation foo" elsewhere would be an RPC called "action"?

--Per

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] YANG action not allowed at root?

[Per Hedeland]

On 2020-05-05 11:00, Martin Björklund wrote:
> Hi,
>
> If we were to redo YANG, I would prefer to have a single statement
> "operation", either on the top-level, or tied to a node.

So, no rpc statement, and thereby no possibility to extend NETCONF
with new RPCs? (Or to be precise, YANG would extend NETCONF with
exactly one RPC, called "operation"?)

--Per

> /martin
>
> Christian Hopps  wrote:
>> An action is defined as being something bound to a node. Talking about
>> actions that aren't bound to a node is talking about RPCs AFAICT. In
>> the server it just comes down to passing the bound node data in to the
>> function or not. Defining "unbound actions" to replace RPCs is just
>> different syntax for the same thing, right? Having 2 ways to do the
>> same thing wouldn't help make servers easier to implement (it would do
>> the opposite actually).
>>
>> Thanks,
>> Chris.
>>
>>> On Apr 30, 2020, at 11:50 AM, Sterne, Jason (Nokia - CA/Ottawa)
>>>  wrote:
>>>
>>> Yes - the intent was to address the limitation that an RPC can only be
>>> at root. Actions can be out in a tree & nicely associated with
>>> something (e.g. instead of having a pile of flat RPCs with long names
>>> that encode containers like reset-www-xxx-yyy-zzz-entity).
>>>
>>> But I don't really understand why we limited actions from being at the
>>> root. It prevents a strategy of implementing all operations in a
>>> server (some of which may be desirable at root for various reasons,
>>> some of which may be desirable in the tree) as actions.
>>>
>>> Why not allow this?
>>>
>>>module bar {
>>>  action do-stuff {
>>>input {
>>>  leaf iterations {
>>>type uint8;
>>>   }
>>> }
>>>  }
>>>}
>>>}
>>>
>>> Which could be called from NETCONF like this:
>>>
>>>  >>   xmlns="urn:ietf:params:xml:ns:netconf:base:1..0">
>>>
>>>  
>>>5
>>>  
>>>
>>>  
>>>
>>>
>>> Jason
>>>
>>> From: Reshad Rahman (rrahman) 
>>> Sent: Thursday, April 30, 2020 11:31 AM
>>> To: Sterne, Jason (Nokia - CA/Ottawa) ;
>>> netmod@ietf.org
>>> Subject: Re: [netmod] YANG action not allowed at root?
>>>
>>> I dont know the history on this but the intent is to have action tied
>>> to a data node.
>>>
>>> https://tools.ietf.org/html/rfc7950#section-7.15
>>>The difference between an action and an rpc is that an action is tied
>>>to a node in the datastore, whereas an rpc is not.  When an action is
>>>invoked, the node in the datastore is specified along with the name
>>>of the action and the input parameters.
>>>
>>> Regards,
>>> Reshad.
>>>
>>> From: netmod  on behalf of "Sterne, Jason
>>> (Nokia - CA/Ottawa)" 
>>> Date: Thursday, April 30, 2020 at 11:08 AM
>>> To: "netmod@ietf.org" 
>>> Subject: [netmod] YANG action not allowed at root?
>>>
>>> Hi all,
>>>
>>> I was a bit surprised to find this in section 7.15 of 7950 recently:
>>>
>>>Since an action cannot be defined at the top level of a module or in
>>>a "case" statement, it is an error if a grouping that contains an
>>>action at the top of its node hierarchy is used at the top level of a
>>>module or in a case definition.
>>>
>>> I realize that actions can be placed down in a schema tree (i.e. sit
>>> in the context of a container or list), but why is it phrased that
>>> they *must* be in a container?
>>>
>>> RPCs are limited to being at the root. I would have thought actions
>>> could be anywhere (root or down in the tree).
>>>
>>> Jason
>>>
>>>
>>> ___
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>>
>> ___
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Alexey Melnikov's Discuss on draft-ietf-netmod-module-tags-07: (with DISCUSS)

[Per Hedeland]

On 2020-02-17 23:14, Christian Hopps wrote:
>
>
>> On Feb 17, 2020, at 4:42 PM, Randy Presuhn 
 wrote:
>>
>> Hi -
>>
>> On 2/17/2020 11:47 AM, Christian Hopps wrote:
 On Feb 17, 2020, at 11:51 AM, Randy Presuhn 
 wrote: Hi - On 2/17/2020 3:15 AM, Christian Hopps 
wrote: ...
> BTW, I did look at the "SHOULD be avoided" (occurs twice that I saw) once 
dealing with LFs and CRs which lucky for us is not part of a tags allowable characters.
 There are lots of other things that complicate life. The Yang string 
definition circumscribes some of them, but not all.
> " typedef tag { type string { length "1..max"; pattern '[\S ]+'; } "
 This pattern doesn't make sense to me when I try to understand it using https://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#charcter-classes It excludes "symbols", but permits, for example, 
paragraph separators and formatting characters and such delights as zero-width non-joiner. Also, in complementing the "all symbols" category, it seems to me it already permits space, so I don't see 
why it calls out space again.
>>> The intent was to have the pattern match the description immediately below it: "A tag value is composed of a standard prefix followed by any type 'string' value that does not include carriage 
return, newline or tab characters." Does this pattern fail in doing that?

>>
>> Yes, what it accomplishes does not match the stated intent.
>
> I'm finding this hard to believe looking at the definition of "\S" which is "everything but space, tab, newline and carriage return" and then adding "space". Seems to match the definition unless we 
quibble over the prefix (which I don't think we are).


+1

>> I suspect you may have intended something like '[\Z ]+'
>> See https://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#charcter-classes
>
> I don't think that's a valid pattern.

+1

> If you are talking about the property categories (where I see 'Z' mentioned as "All separators") then there doesn't appear to be a "lower means include, upper means exclude" relationship. Also it 
appears that to refer to one of these things the syntax is actually "\P{Z}" or "\p{Z}" not just "Z". So translating maybe that's "[\P{Z} ]"? I see nothing that defines how "catEsc" (\p{}) vs "compEsc" 
(\P{}) are different, but maybe the upper here means exclude.


The description is right above the definitions:

  The set containing all characters that have property X, can be
  identified with a category escape \p{X}. The complement of this set
  is specified with the category escape \P{X}. ([\P{X}] = [^\p{X}])

So yes, \P{Z} would be the complement of "All Separators", while your
original \S is the complement of \s ([#x20\t\n\r]). I.e. \P{Z} would
exclude "more separators", but is hardly worth the trouble I think -
and it is *not* the "stated intent".

> I'm more inclined to just ditch any pattern or restriction the more this gets discussed. Let the user do what they want. If they want to include crazy unicode stuff (almost certainly they dont) 
then I guess that's what they want.


FWIW, as I already wrote, I think your original pattern is fine (and I
think Randy needs to have a closer look at the section he references).

--Per

> Thanks,
> Chris.
>
>>
>> Randy
>>
>> ___
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>>
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Alexey Melnikov's Discuss on draft-ietf-netmod-module-tags-07: (with DISCUSS)

[Per Hedeland]

On 2020-02-17 20:47, Christian Hopps wrote:
>
>
>> On Feb 17, 2020, at 11:51 AM, Randy Presuhn 
 wrote:
>>
>> Hi -
>>
>> On 2/17/2020 3:15 AM, Christian Hopps wrote:
>> ...
>>> BTW, I did look at the "SHOULD be avoided" (occurs twice that I saw) once 
dealing with LFs and CRs which lucky for us is not part of a tags allowable characters.
>>
>> There are lots of other things that complicate life.  The Yang string 
definition
>> circumscribes some of them, but not all.
>>
>>> "
>>>   typedef tag {
>>> type string {
>>>   length "1..max";
>>>   pattern '[\S ]+';
>>> }
>>> "
>>
>> This pattern doesn't make sense to me when I try to understand it using
>> https://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#charcter-classes
>> It excludes "symbols", but permits, for example, paragraph separators and
>> formatting characters and such delights as zero-width non-joiner. Also, in
>> complementing the "all symbols" category, it seems to me it already permits
>> space, so I don't see why it calls out space again.

\S is not the *complement* of the "all symbols" category, it *is* the
"all symbols" category - a.k.a. the complement of \s ([#x20\t\n\r]).

> The intent was to have the pattern match the description immediately below it:
>
> "A tag value is composed of a standard prefix followed by any type 'string' value 
that does not include carriage return, newline or tab characters."
>
> Does this pattern fail in doing that?

No, as far as I can see that is exactly what it does.

--Per

> If this requires anymore work to get right then I think we should drop the pattern, as this isn't the document to come up with a better way to deal with the apparent ugliness of UTF strings in 
YANG. The overriding intent is to leave it to the users to decide what they want to put in there.

>
> Thanks,
> Chris.
>
>> Randy
>>
>> ___
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] draft-ietf-netmod-rfc6991-bis: Comment on node-instance-identifier

[Per Hedeland]

On 2019-11-04 14:46, Schönwälder, Jürgen wrote:

Hi,

what about this wording :

  [...]

   A node-instance-identifier value is an unrestricted
   YANG instance-identifier expression or the special
   value '/', which refers to the entire accessible tree.

  [...]


Yes, that should be "good enough" I think. Though when reading the
text from NACM for the umpteenth time, I got hung up on the word
"unrestricted" - doesn't that mean "require-instance true"?

From 7950:

9.13.1.  Restrictions

   An instance-identifier can be restricted with the "require-instance"
   statement (Section 9.9.3).

9.9.3.  The "require-instance" Statement

   The "require-instance" statement, which is a substatement to the
   "type" statement, MAY be present if the type is "instance-identifier"
   or "leafref".  It takes as an argument the string "true" or "false".
   If this statement is not present, it defaults to "true".

Probably not worth worrying about...

--Per

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] draft-ietf-netmod-rfc6991-bis: Comment on node-instance-identifier

[Per Hedeland]

On 2019-11-04 11:32, Schönwälder, Jürgen wrote:

Hi,

this may be resolved by adding

  The special value '/' refers to the entire accessible tree.

to the description statement. Does this work for you?


Hm, it seems to me that this would conflict with this part of the
description:

   A node-instance-identifier value is an
   unrestricted YANG instance-identifier expression.

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

- since '/' is not a valid value for a YANG instance-identifier.
I.e. if '/' should be included in the typedef (seems reasonable to
me), the text for it probably needs to be "incorporated" in the text
above.

--Per


/js

On Mon, Sep 30, 2019 at 03:17:25PM +0100, Robert Wilton wrote:

Hi Juergen,

Should the "node-instance-identify" type specify how the path "/" is
treated?

I noted that in rfc8341, the behavior for "/" is described in the leaf
"path" description rather than in the type definition, but I was thinking
that it might be better if this behaviour was specified as part of the
typedef.

Snippet from RFC8341:

  case data-node {
leaf path {
  type node-instance-identifier;
  mandatory true;
  description
"Data node instance-identifier associated with the
 data node, action, or notification controlled by
 this rule.

 Configuration data or state data
 instance-identifiers start with a top-level
 data node.  A complete instance-identifier is
 required for this type of path value.

 The special value '/' refers to all possible
 datastore contents.";
}
  }

Thanks,
Rob





___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] [Technical Errata Reported] RFC7950 (5784)

[Per Hedeland]

On 2019-07-17 14:34, Juergen Schoenwaelder wrote:

Its the first half of the sentence in my copy of RFC 7950.


It believe that there is a problem with English language both in Qin's
understanding of the original text (which is correct also in my
opinion) and in his explanation of his (mis)understanding...


I propose to reject this errata.


I agree, in particular since the suggested change is IMHO no actual
improvement. It seems the problem is in understanding the "subject to"
construct, which is perhaps not obvious to *all* non-native English
readers, but I can't think of a replacement that wouldn't result in an
unecessarily complex text.


/js

On Wed, Jul 17, 2019 at 12:02:21PM +, Qin Wu wrote:

Hi, Juergen and Rob:
The condition to apply " Leading and trailing zeros are prohibited ",is the second half 
sentence, i.e.,"there MUST be at least one digit before and after the decimal point".


It seems that you have it almost backwards... "The rule is A subject
to the rule B" means that rule A should be applied, except when it
will violate rule B.


One digit before the decimal point and one digit after the decimal point at the 
same time cover 0.500?, I still don't get it.


It's a very good example. With unconditional application of "Leading
and trailing zeros are prohibited", we end up with .5 - but then we
violate "there MUST be at least one digit before and after the decimal
point", so we need to back out the removal of the leading zero, and
end up with 0.5.


Maybe I am wrong, but this is not a big deal.


Hopefully the above helps...

--Per


-Qin
-®öŸö-
Ñöº: Juergen Schoenwaelder [mailto:j.schoenwael...@jacobs-university.de]
Ñ
öô: 2019t717å 18:29
6öº: Qin Wu 
„
: Rob Wilton (rwilton) ; ibagd...@gmail.com; war...@kumari.net; 
netmod@ietf.org; RFC Errata System 
;˜: Re: [netmod] RE: [Technical Errata Reported] RFC7950 (5784)

The text starts with the general case and says "Leading and trailing zeros are 
prohibited", which seems to cover 0.5000 (which must be represented as 0.5.

/js

On Wed, Jul 17, 2019 at 09:42:38AM +, Qin Wu wrote:

I realized my proposed changes also have some flaw and may need to be tweaked.

My question is should trailing zeros in 0.5 be allowed? I didnt see the 
original text prohibit this.
Yes, the original text is correct, but it excludes some exception cases, such 
as 0.5, if my understanding is correct.
Ñöº: Rob Wilton (rwilton) [mailto:rwil...@cisco.com]
Ñ
öô: 2019t717å 17:20
6öº: Qin Wu ; Juergen Schoenwaelder

„
: ibagd...@gmail.com; war...@kumari.net; netmod@ietf.org; RFC Errata
System 
;˜: RE: [netmod] T

: [Technical Errata Reported] RFC7950 (5784)


Hi Qin,

I also find the current RFC text quite understandable and correct.

The and is required to disallow .0 and 0. as valid canonical forms.  I.e. 
in the canonical form there MUST always be at least one digit (which could be 
0) before the decimal point and then must be at least one digit (which could be 
0) after the decimal point.  Otherwise, there must be no leading or trailing 
0s.  So, none of  .0, 0., 00.0, 0.00 and 00.00 are in the canonical 
form, and should be represented as 0.0 instead; similarly none of .1, 1., 
01.0, 1.00 and 01.00 are in the canonical form and should be represented 
as 1.0 instead.

Thanks,
Rob


From: netmod mailto:netmod-boun...@ietf.org>>
On Behalf Of Qin Wu
Sent: 17 July 2019 09:59
To: Juergen Schoenwaelder
mailto:j.schoenwaelder@jacobs-un
iversity.de>>
Cc: ibagd...@gmail.com;
war...@kumari.net;
netmod@ietf.org; RFC Errata System
mailto:rfc-edi...@rfc-editor.org>>
Subject: [netmod] T

: [Technical Errata Reported] RFC7950 (5784)



Understand, the problem lies at "and" that is used in " one digit before and after the decimal point 
", that is to say it only focus on the case that has two digits, one is before decimal point, the other digit is 
after decimal such as "5.06", but doesn't cover the case where "one digit before or after the decimal 
point ", thats why I think the case 0.50 is not covered. We should prohibit trailing zeros in 0.500.

-®öŸö-
Ñöº: Juergen Schoenwaelder
[mailto:j.schoenwael...@jacobs-university.de]
Ñ
öô: 2019t717å 16:46
6öº: Qin Wu mailto:bill...@huawei.com>>
„
: RFC Errata System
mailto:rfc-edi...@rfc-editor.org>>;
ibagd...@gmail.com;
netmod@ietf.org;
war...@kumari.net
;˜: Re: [netmod] [Technical Errata Reported] RFC7950 (5784)



The text starts with the general case and says "Leading and trailing zeros are 
prohibited", which seems to cover 0.5000. The text then handles the special rule 
that there needs to be at least one digit before and after the decimal point. I think all 
is fine.



/js



On Wed, Jul 17, 2019 at 08:11:41AM +, Qin Wu wrote:


What about "0.5000"? based on original text, is 

Re: [netmod] A question on the parameter overriding in draft-ietf-isis-yang-isis-cfg

[Per Hedeland]

On 2019-06-11 15:43, Xufeng Liu wrote:
Thank Per for the clear analysis.  Since the current YANG RFC7950 does not have a formal way to specify the overriding rule, I agree that the best way is to remove the default statements from 
"level-1" and "level-2", as Per, Martin, and Rob suggested.


Yes, I agree - i.e. the wording "the server MUST operationally behave
as if the leaf was present in the data tree with the default value as
its value" in the spec is absolutely correct, and since this doesn't
match the behavior you want to achieve, you can't use the 'default'
statement.

You should of course still *describe* the behavior, and text in a
'description' statement is just as "normative" as a 'default' statement,
"just" not machine-readable.

--Per


Regards,
- Xufeng

[Forwarding Per's reply to LSR mailing list]

On Sun, Jun 9, 2019 at 1:08 PM Per Hedeland mailto:p...@hedeland.org>> wrote:

On 2019-06-09 17:28, Juergen Schoenwaelder wrote:
 >
 > YANG does not have 'levels'. This seems to be an ISIS specific
 > question you should ask on the ISIS list.

AFAIK, this list is not restricted to discussions of what YANG "is" or
"has", but also covers (at least) how YANG can be used, and what the
semantics of various YANG usage patterns are. I think there is a
generic YANG question in the problem described, and possibly even an
indication that the wording in the spec is overly restrictive.

 > On Sun, Jun 09, 2019 at 10:35:11AM -0400, Xufeng Liu wrote:
 >> In Section 2.3. and many other locations, the current IS-IS model 
applies
 >> the parameter overriding rule as below:
 >>
 >> [Quote]:
 >>
 >> 2.3 
<https://tools.ietf.org/html/draft-ietf-isis-yang-isis-cfg-35#section-2..3>.
 >> Per-Level Parameters
 >>
 >>
 >> Some parameters allow a per level configuration.  In this case, the
 >> parameter is modeled as a container with three configuration
 >> locations:
 >>
 >> o  a top-level container: corresponds to level-1-2, so the
 >>configuration applies to both levels.
 >>
 >> o  a level-1 container: corresponds to level-1 specific parameters.
 >>
 >> o  a level-2 container: corresponds to level-2 specific parameters.
 >>
 >> +--rw priority
 >> |  +--rw value? uint8
 >> |  +--rw level-1
 >> |  |  +--rw value?   uint8
 >> |  +--rw level-2
 >> | +--rw value?   uint8
 >>
 >> Example:
 >>
 >> 
 >> 250
 >> 
 >> 100
 >> 
 >> 
 >> 200
 >> 
 >> 
 >>
 >> An implementation SHOULD prefer a level specific parameter over a
 >> level-all parameter.  As example, if the priority is 100 for the
 >> level-1, 200 for the level-2 and 250 for the top-level 
configuration,
 >> the implementation should use 100 for the level-1 and 200 for the
 >> level-2.
 >>
 >> [End of Quote]
 >>
 >>
 >> In the model, all three value leaves above have a default statement
 >>  default 64 , which brings up my question for the following example:

So, to give an actual YANG snippet for this example, it would be

container priority {
  leaf value {
type uint8;
default 64;
  }
  container level-1 {
leaf value {
  type uint8;
  default 64;
}
  }
  container level-2 {
leaf value {
  type uint8;
  default 64;
}
  }
}

 >> 
 >> 250
 >> 
 >> 100
 >> 
 >> 
 >>
 >>
 >> The user does not provide a configured value for level-2. According to
 >> Section 7.6.1. of RFC7950, because the default value is in use, "the 
server
 >> MUST operationally behave as if the leaf was present in the data tree 
with
 >> the default value as its value". This means the priority value for 
level-2
 >> will be 64 (the default value), so the value 250 can never take effect 
as
 >> intended in the above quoted Section 2.3.

Obviously 

Re: [netmod] A question on the parameter overriding in draft-ietf-isis-yang-isis-cfg

[Per Hedeland]

On 2019-06-09 17:28, Juergen Schoenwaelder wrote:


YANG does not have 'levels'. This seems to be an ISIS specific
question you should ask on the ISIS list.


AFAIK, this list is not restricted to discussions of what YANG "is" or
"has", but also covers (at least) how YANG can be used, and what the
semantics of various YANG usage patterns are. I think there is a
generic YANG question in the problem described, and possibly even an
indication that the wording in the spec is overly restrictive.


On Sun, Jun 09, 2019 at 10:35:11AM -0400, Xufeng Liu wrote:

In Section 2.3. and many other locations, the current IS-IS model applies
the parameter overriding rule as below:

[Quote]:

2.3 .
Per-Level Parameters


Some parameters allow a per level configuration.  In this case, the
parameter is modeled as a container with three configuration
locations:

o  a top-level container: corresponds to level-1-2, so the
   configuration applies to both levels.

o  a level-1 container: corresponds to level-1 specific parameters.

o  a level-2 container: corresponds to level-2 specific parameters.

+--rw priority
|  +--rw value? uint8
|  +--rw level-1
|  |  +--rw value?   uint8
|  +--rw level-2
| +--rw value?   uint8

Example:


250

100


200



An implementation SHOULD prefer a level specific parameter over a
level-all parameter.  As example, if the priority is 100 for the
level-1, 200 for the level-2 and 250 for the top-level configuration,
the implementation should use 100 for the level-1 and 200 for the
level-2.

[End of Quote]


In the model, all three value leaves above have a default statement
default 64, which brings up my question for the following example:


So, to give an actual YANG snippet for this example, it would be

  container priority {
leaf value {
  type uint8;
  default 64;
}
container level-1 {
  leaf value {
type uint8;
default 64;
  }
}
container level-2 {
  leaf value {
type uint8;
default 64;
  }
}
  }



250

100




The user does not provide a configured value for level-2. According to
Section 7.6.1. of RFC7950, because the default value is in use, "the server
MUST operationally behave as if the leaf was present in the data tree with
the default value as its value". This means the priority value for level-2
will be 64 (the default value), so the value 250 can never take effect as
intended in the above quoted Section 2.3.


Obviously there is at least a deficiency in the description, since it
makes no sense with your (justifiable) interpretation. I think it is
clear that the *intent* is that the value 250 should take effect for
level-2 in this case (and I think that this is a very valid design).
That intent could have been made clear by saying "if the priority is
*configured* as 100" instead of just "if the priority is 100", since
the "is" applies equally well to a "default value in effect" and a
configured value.

But this would seem to violate the statement in RFC 7950, since it
actually does say that the value 64 MUST be used for level-2 in this
case. Maybe it should have some conditional like "unless otherwise
specified" or something - but IMHO it's entirely reasonable that the
"overall system" behaves differently depending on whether the value
for a specific leaf is actually configured or is just a
"default-in-effect".

Then again, in this case one could question what the point of the
default values for the level-1 and level-2 leafs is. Removing them
would mean that without values configured, they would use the
"toplevel" value, whether default or configured - and since the
defaults *in this case* are all the same, it would amount to the
exactly the intent I assume above, but without any violation of the
7950 statement.

However with different defaults, it is not as straightforward - say
e.g.

  container priority {
leaf value {
  type uint8;
}
container level-1 {
  leaf value {
type uint8;
default 32;
  }
}
container level-2 {
  leaf value {
type uint8;
default 64;
  }
}
  }

IMHO, it would make perfect sense (assuming of course that it is
documented) for the system to in this case behave like

   configured "toplevel"   configured level-2   use for level-2

1)  nothing   nothing   64
2)250 nothing  250
3) irrelevant   128128

And then the case 2) would again seem to violate the 7950 

Re: [netmod] 6991bis: address-with-prefix-length

[Per Hedeland]

On 2019-04-18 10:41, Ladislav Lhotka wrote:

On Thu, 2019-04-18 at 10:09 +0200, Kristian Larsson wrote:


On 2019-04-18 09:40, Ladislav Lhotka wrote:

Juergen Schoenwaelder  writes:


On Wed, Apr 17, 2019 at 09:35:51PM +0200, Kristian Larsson wrote:

I wonder though, isn't ipX-address-and-prefix-length the clearer name,
or if
we do want to shorten then ipX-address-and-plen. I think Martin stated
the
case for ipX-address-and-prefix but that is IMHO not the way this is
typically perceived by people.

1.2.3.4/24
^^^- ipv4 address
 ^^^-- ipv4 prefix length

now, taking the prefix-length you know that 1.2.3 is the prefix but does
that mean the above is an IPv4 address and a prefix? Or is it just that
you
can infer the prefix from the above? It's just different ways of looking
at
it. My experience tells me ipX-address-and-prefix-length is the clearer
way
of conveying what this is.



I guess this is somewhat subjective. The prefix length is the number
used to convey what the prefix is. So you are effectively defining an
address and the prefix that this address belongs to. ;-)


Strictly speaking, what is being defined by the number is a subnet mask.


Heh, amazing how something so binary can turn out to be so subjective ;)
This sort of turns into philosophical questions and I'm not sure we need
to straighten it all out. I'd still call the prefix-length the
prefix-length. It directly maps to the typical subnet mask
representation and as you say, they can be thought of as the same thing.

Does this mean you prefer ipX-address-and-subnet-mask? Because I think


No.


that when someone reads that they are going to expect a value that looks
like 1.2.3.4/255.255.255.0 rather than 1.2.3.4/24, which is why I still
think ipX-address-and-prefix-length (possibly s/prefix-length/plen/) is
the better name :)



Given that we already have ip-prefix (which does as well use a prefix
length to convey what the prefix is), it seems ip-address-and-prefix
is more consistent with the existing RFC 6991 definitions. Being
consistent with what we have was the main reason for me to prefer
ip-address-and-prefix.


I am not in favour of adding this type. Having ip-prefix next to
ip-address-and-prefix is confusing.


Confusing or not, they are NOT interchangeable and actually do different
things, which is why both are needed. There's plenty of precedence to


I actually agree with you. It is a historical accident that these two different
things got mixed up (and some vendors contributed to this). I would argue that

- IP prefix is a set of IP addresses, and as such can be thought of as a single
entity.

- IP address and subnet mask/prefix are two separate things, the latter being an
instruction for routing to *other* destination addresses.


Agreed - except the not entirely minor nit that the thing after the
"/" is not a prefix but a *prefix-length*. Another way of putting it
is that the IP address is a property of an interface, while the
prefix-length or subnet mask is a property of the network that an
interface is connected to.

So this would clearly be two separate values "bundled" into one, and
despite the similar syntax, it is radically different from the
existing ip*-prefix types, which really do represent a single value -
as Kristian pointed out earlier in the thread, the value is the
initial N bits of a set of IP addresses - i.e. a prefix, as the name
says.

Thus if these types should be added, I don't think there is any reason
to have a naming that is "consistent" with the existing ip*-prefix
types - rather the naming should highlight the difference. And since
the two values given are an IP address and a prefix-length, the
natural choice would be ip*-address-and-prefix-length.

Using ip*-address-and-prefix would be both inaccurate (neither of the
two values is a prefix, although they can of course be combined to
compute a one) and IMHO confusing due to the similarity in naming of
the existing ip*-prefix types.

If ip*-address-and-prefix-length is considered too verbose/clunky
(although I don't know why this matters for a type name), a reasonable
shorter form could IMHO be ip*-address-and-length - the prefix-length
is of course a length, but it is not a prefix. Kristian's
ip*-address-and-plen is of course even shorter, and could be
considered to have more information, but I believe we generally try to
avoid at least non-obvious abbreviations in the YANG modules.


this, like postgresql has data types (cidr and inet) that map exactly to
this behaviour, i.e. both store something that looks like an IP address
and a prefix-length but one (cidr for pg) forces bits in host portion to
be set to all 0. Python ipaddress has the same with IPv4Address and
IPv4Interface.



Moreover, the most natural use for
this type would be the address specification in the "ietf-ip" module,
but we already have two leaves there: ip and prefix-length.


Like I said in another mail, I think it is nice if these common
datatypes become used by 

Re: [netmod] guidelines for top-level nodes in RFC 8407

[Per Hedeland]

On 2019-03-22 14:45, Ladislav Lhotka wrote:

Martin Bjorklund  writes:


IMO it doesn't violate the spirit of the rule.  So the question is; is
this allowed?


It seems to me that it would make sense to apply the same logic as
for "remote" augments to this rule - from RFC 7950:

   If the augmentation adds mandatory nodes (see Section 3) that
   represent configuration to a target node in another module, the
   augmentation MUST be made conditional with a "when" statement.  Care
   must be taken when defining the "when" expression [...]

I.e. the answer to your (original) question would in that case be
"yes" (at least for YANG 1.1 modules...).

--Per Hedeland

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Adding a pre-existing leaf into a new 'choice' - NBC change?

[Per Hedeland]

On 2018-11-22 16:37, Ladislav Lhotka wrote:
> On Thu, 2018-11-22 at 15:31 +, Sterne, Jason (Nokia - CA/Ottawa) wrote:
>> From what I can understand below, none of this debate affects the conclusion
>> that choice & case identifiers do *not* appear in:
>> - leafref paths
>> - must statements
>> - when statements
>> right?
> 
> Yup.
> 
> Lada
> 
>>
>> (they *do* appear in augment paths though since that definitely needs to 
>> refer
>> to schema)

They also appear in 'deviation' and 'refine' paths, which unlike augment
paths can identify a leaf or leaf-list (although 'refine' is of course
only relevant for nodes in a (top-level) grouping).

--Per

>> Jason
>>
>>> -Original Message-
>>> From: Ladislav Lhotka 
>>> Sent: Thursday, November 22, 2018 10:28 AM
>>> To: Martin Bjorklund 
>>> Cc: a...@yumaworks.com; Sterne, Jason (Nokia - CA/Ottawa)
>>> ; netmod@ietf.org
>>> Subject: Re: [netmod] Adding a pre-existing leaf into a new 'choice' - NBC
>>> change?
>>>
>>> On Thu, 2018-11-22 at 16:14 +0100, Martin Bjorklund wrote:
 Ladislav Lhotka  wrote:
> On Thu, 2018-11-22 at 15:00 +0100, Martin Bjorklund wrote:
>> Andy Bierman  wrote:
>>> On Thu, Nov 22, 2018 at 5:39 AM Martin Bjorklund 
>>> wrote:
 Hi,

 Ladislav Lhotka  wrote:
> Andy Bierman  writes:
>
>> On Mon, Nov 19, 2018 at 12:32 PM Sterne, Jason (Nokia -
>>> CA/Ottawa)
 <
>> jason.ste...@nokia.com> wrote:
>>
>>> Hi all,
>>>
>>>
>>>
>>> If we have a YANG model with a leaf:
>>>
>>>
>>>
>>> MODEL VERSION 1:
>>>
>>> container my-model {
>>>
>>> leaf a { type string; }
>>>
>>> }
>>>
>>>
>>>
>>> And then later we produce another version of the model where
>>> that
 leaf is
>>> placed into a choice construct:
>>>
>>>
>>>
>>> MODEL VERSION 2:
>>>
>>> container my-model {
>>>
>>> choice some-choice {
>>>
>>> case x {
>>>
>>> leaf a { type string; }
>>>
>>> }
>>>
>>> }
>>>
>>> }
>>>
>>>
>>>
>>> Is that considered a non-backwards-compatible change?
>>>
>>
>> yes -- even though the data node /my-model/x did not change,
>> the schema node /my-model/a changed to /my-model/some-
>>> choice/x/a.
>> Any leafref path pointing at this leaf will break.
>
> This is not correct. A leafref path is a special XPath, and as
> such
> includes only data nodes, i.e. NOT choice and case nodes.
>
> What does change are schema node identifier. This could be
 significant
> in an augment statement, but not ini this example because a leaf
 cannot
> be augmented anyway.
>
> I don't see anything else that could break, so Jason's change
> seems
> backward compatible to me.

 Since it does change the schema tree, this is not legal according
 to
 7950.  So in that sense it is not backwards compatible.  The rules
 in
 7950 protect both clients and other modules that import the
>>> module.

>>> This text is confusing wrt/ schema tree vs data tree:
>>>
>>>
>>> 9.9 ;;;.  The
>>> leafref
>>> Built-In Type
>>>
>>>The leafref built-in type is restricted to the value space of
>>> some
>>>leaf or leaf-list node in the schema tree and optionally further
>>>restricted by corresponding instance nodes in the data tree.  The
>>>"path" substatement (Section 9.9.2
>>> ;;;) is used to
>>> identify the referred
>>>leaf or leaf-list node in the schema tree.  The value space of
>>> the
>>>referring node is the value space of the referred node.
>>
>> Yes, it should be "data tree" in both occurrences.
>
> I tend to disagree. The values of a leafref are first restricted
> according
 to
> the *schema*, i.e. even before any leaf instance exists in the data tree
 that
> the leafref can point to. Consider this example:
>
> list map {
>   key name;
>   leaf name {
> type string;
>   }
>   leaf value {
> type uint8;
>   }
> }
> leaf link {
>   type leafref {
> path "../map[name='quux']/value";
> default "foo";
>   }
> }
>
> We had a long discussion about this, maybe I could find it, and the
 conclusion
> was that a YANG parser should flag the default "foo" value as incorrect
>>> even
> before any instance data are in sight.

 Yes, 

Re: [netmod] for a future rfc6991bis

[Per Hedeland]

On 2018-11-07 16:56, Qin Wu wrote:
> -®öŸö-
> Ñöº: netmod [mailto:netmod-boun...@ietf.org] ãh Per Hedeland
> Ñ
öô: 2018t117å 15:57
> 6öº: Juergen Schoenwaelder 
> „
: NETMOD WG 
> ;˜: Re: [netmod] for a future rfc6991bis
> 
> On 2018-11-07 09:34, Juergen Schoenwaelder wrote:
>> On Wed, Nov 07, 2018 at 07:49:54AM +, Yemin (Amy) wrote:
>>
>>> For the range, if the defintion can cover the our range(0..99.), 
>>> it will be acceptable.  In your suggestion below, does that mean the 
>>> base defintion is without range, while refined types can chosse the 
>>> range they like?
>>
>> I was thinking loud. Let me detail somewhat more what was going on in 
>> my head:
>>
>>We could define a percent type without the upper bound being
>>whatever the decimal covers but fixing the precision of the
>>fractional part. We could then narrow the upper bound via
>>subtyping:
>>
>>   typedef percent {
>> type decimal {
>>   fraction-digits 4;
>>   range "0..max";
>> }
>>   }
>>
>>   typedef percent' {
>> type percent { range 0..100; }
>>   }
>>
>>If wanted flexibility on the fractional part, we could define
>>percent with a fixed range and the largest number of fraction digits
>>possible and then we could subtype this to obtain a precision that
>>makes sense in the usage contexts (although it is not clear whether
>>YANG 1.1 really allows this, if not this may be just due to nobody
>>ever thinking about this before):
> 
> I believe it is quite clear that this is *not* allowed:
> 
>9.3.3.  Restrictions
> 
>   A decimal64 type can be restricted with the "range" statement
>   (Section 9.2.4).
> 
> --Per
> 
> [Qin]: Section 9.2.4 said:
> "
> If a range restriction is applied to a type that is
>already range-restricted, the new restriction MUST be equally
>limiting or more limiting, i.e., raising the lower bounds, reducing
>the upper bounds, removing explicit values or ranges, or splitting
>ranges into multiple ranges with intermediate gaps.
> "
> I am not sure the above example really violates the rule described above.

No, it's the example *below* - that Juergen was referring to above with
the "it is not clear whether YANG 1.1 really allows this" that I replied
to - that does. I.e. restricting a decimal64 type with a fraction-digits
statement is not allowed.

--Per

>>  typedef percent {
>>type decimal {
>>  fraction-digits 16;
>>  range 0..100;
>>}
>>  }
>>
>>  typedef percent' {
>>type percent { fraction-digits 4; }  <<<<<<<<<<<<<<
>>  }
>>
>>An ideal solution would provide flexibility both on the range and
>>the number of fraction digits but it seems this is impossible since
>>these two properties (range and precision) interact.
>>
>> So it seems we have to do something that is pragmatic and this likely 
>> means fixing the fraction since subtyping the fractional part may not 
>> be allowed by YANG or not be supported by implementations. The 
>> question is then how we pick suitable fractions. I understand you want
>> 4 digits.
>>
>> /js
>>
>>> BR,
>>> Amy
>>> 
>>> Ñöº: Juergen Schoenwaelder [j.schoenwael...@jacobs-university.de]
>>> Ñ
öô: 2018t116å 22:16
>>> 6öº: Yemin (Amy)
>>> „
: Qin Wu; Xufeng Liu; balazs.leng...@ericsson.com; NETMOD WG
>>> ;˜: Re: [netmod] for a future rfc6991bis
>>>
>>> Well, the draft-ye-ccamp-mw-topo-yang-02 definition excludes 100%, 
>>> which is likely not generally useful. In fact, even 150% can be in 
>>> some contexts a perfectly sensible percentage. So we may need to 
>>> provide some flexibility here, i.e., having a base time where the 
>>> range can be refined and refined types with an upper limit set to 
>>> 100% for use in situations where this limit is sensible.
>>>
>>> The more difficult aspect seems to be precision, I am not sure YANG 
>>> allows subtyping the fractional part. RFC 7950 seems to be silent 
>>> about this and in the general case this would not be meaningful. But 
>>> in this particular case, when the number range is limited, it would 
>>> actually be OK to allow this (but then we have to have a limit and we 
>>> can't

Re: [netmod] for a future rfc6991bis

[Per Hedeland]

On 2018-11-07 09:34, Juergen Schoenwaelder wrote:

On Wed, Nov 07, 2018 at 07:49:54AM +, Yemin (Amy) wrote:


For the range, if the defintion can cover the our range(0..99.),
it will be acceptable.  In your suggestion below, does that mean the
base defintion is without range, while refined types can chosse the
range they like?


I was thinking loud. Let me detail somewhat more what was going on in
my head:

   We could define a percent type without the upper bound being
   whatever the decimal covers but fixing the precision of the
   fractional part. We could then narrow the upper bound via
   subtyping:

  typedef percent {
type decimal {
  fraction-digits 4;
  range "0..max";
}
  }

  typedef percent' {
type percent { range 0..100; }
  }

   If wanted flexibility on the fractional part, we could define
   percent with a fixed range and the largest number of fraction digits
   possible and then we could subtype this to obtain a precision that
   makes sense in the usage contexts (although it is not clear whether
   YANG 1.1 really allows this, if not this may be just due to nobody
   ever thinking about this before):


I believe it is quite clear that this is *not* allowed:

  9.3.3.  Restrictions

 A decimal64 type can be restricted with the "range" statement
 (Section 9.2.4).

--Per


 typedef percent {
   type decimal {
 fraction-digits 16;
 range 0..100;
   }
 }

 typedef percent' {
   type percent { fraction-digits 4; }
 }

   An ideal solution would provide flexibility both on the range and
   the number of fraction digits but it seems this is impossible since
   these two properties (range and precision) interact.

So it seems we have to do something that is pragmatic and this likely
means fixing the fraction since subtyping the fractional part may not
be allowed by YANG or not be supported by implementations. The
question is then how we pick suitable fractions. I understand you want
4 digits.

/js


BR,
Amy

Ñöº: Juergen Schoenwaelder [j.schoenwael...@jacobs-university.de]
Ñ
öô: 2018t116å 22:16
6öº: Yemin (Amy)
„
: Qin Wu; Xufeng Liu; balazs.leng...@ericsson.com; NETMOD WG
;˜: Re: [netmod] for a future rfc6991bis

Well, the draft-ye-ccamp-mw-topo-yang-02 definition excludes 100%,
which is likely not generally useful. In fact, even 150% can be in
some contexts a perfectly sensible percentage. So we may need to
provide some flexibility here, i.e., having a base time where the
range can be refined and refined types with an upper limit set to 100%
for use in situations where this limit is sensible.

The more difficult aspect seems to be precision, I am not sure YANG
allows subtyping the fractional part. RFC 7950 seems to be silent
about this and in the general case this would not be meaningful. But
in this particular case, when the number range is limited, it would
actually be OK to allow this (but then we have to have a limit and
we can't set the upper limit to max).

/js

On Tue, Nov 06, 2018 at 02:21:33AM +, Yemin (Amy) wrote:

If the percentage is defined as following, as a author of 
draft-ye-ccamp-mw-topo-yang-02, we will be happy to use it.
But it's better to include in RFC6991bis, as percentage is a generic and widely 
used item.

BR,
Amy

Ñöº: netmod [netmod-boun...@ietf.org] ãh Qin Wu [bill...@huawei.com]
Ñ
öô: 2018t116å 9:25
6öº: Xufeng Liu; balazs.leng...@ericsson.com
„
: NETMOD WG
;˜: Re: [netmod] for a future rfc6991bis


Another case would be :




typedef percentage {

   type decimal64 {

  fraction-digits 5;

  range "0..100";

  }

description "Percentage.";
}

Which is defined ietf-connectionless-oam.yang module.

-Qin
Ñöº: netmod [mailto:netmod-boun...@ietf.org] ãh Xufeng Liu
Ñ
öô: 2018t116å 3:49
6öº: balazs.leng...@ericsson.com
„
: NETMOD WG 
;˜: Re: [netmod] for a future rfc6991bis

The draft that asked for the percentage type is: 
https://tools.ietf.org/html/draft-ye-ccamp-mw-topo-yang-02

They currently define:

   leaf availability {
 type decimal64 {
   fraction-digits 4;
   range "0..99.";
 }
 description "Availability level of the link";
   }

Thanks,
- Xufeng

On Sun, Nov 4, 2018 at 7:07 AM Balázs Lengyel 
mailto:balazs.leng...@ericsson.com>> wrote:

+1 to percentage.

Balazs
On 2018. 11. 03. 3:44, Xufeng Liu wrote:
Remember that some draft asked for a type of percentage value to the nearest 
hundredth. Wondering if it can be put in.

Thanks,
- Xufeng

On Fri, Nov 2, 2018 at 11:39 AM tom petch 
mailto:ie...@btconnect.com>> wrote:
 Original Message -
From: "Juergen Schoenwaelder" 
mailto:j.schoenwael...@jacobs-university.de>>
To: "Kent Watsen" mailto:kwat...@juniper..net>>
Cc: mailto:netmod@ietf.org>>
Sent: Tuesday, October 30, 

Re: [netmod] removing a node from a grouping

[Per Hedeland]

On 2018-07-15 13:11, Robert Wilton wrote:

Hi Kent,

I don't think that this is a valid use of augment - I thought that augment can 
only add news data nodes, not add extra sub statements to existing ones.


Well, it is valid (though not if "foo" is a leaf), but you are right,
and it doesn't do what Kent expects. The 'when' statement, as always,
"makes its parent data definition statement conditional". I.e. it
applies to the 'augment' statement, not the 'foo' statement, and thus
with an always-false 'when', no 'augment' will happen.

--Per

Also, YANG allows grouping to be changed so that it is constructed from sub groupings, at long as the original grouping name is preserved and is only updated in a backwards compatible way.  But as you 
say, this can still lead to unnatural groupings.


I still think that groupings are probably being overused.  Perhaps Andy's clone 
statement might be a better alternative in some cases 
(https://github.com/netmod-wg/yang-next/issues/31).

Thanks,
Rob


On 14/07/2018 18:46, Kent Watsen wrote:

Hi Rob,

Right you are, "refine" doesn't have a "when" substatement, but "augment" does.

 grouping "bar-etc" {
   uses "foo-bar-etc" {
 augment "foo" {
   when "false()";
 }
   }
 }


The problem with splitting up groupings is that 1) it needs to be done
beforehand and 2) it may produce "unnatural" groupings that wouldn't be
there otherwise.

Kent


= original message =

Hi Kent,

I'm not sure that sec 7.13.2 of 7950 allows refine to add a when
statement, although an equivalent solution would be refine it with an
if-feature statement for a feature that is never enabled.

Ideally, I think that the groupings would be split up, so that they
build on each other.

grouping "foo" {
  container-or-leaf "foo" { ... }
}

grouping "bar-etc" {
  container-or-leaf "bar" { ... }
  ...  // the "etc" ;)
}

grouping "foo-bar-etc" {
  grouping "foo";
  grouping "bar-etc";
}

Thanks,
Rob

On 11/07/2018 18:30, Kent Watsen wrote:

Say there is:

grouping "foo-bar-etc" {
  container-or-leaf "foo" { ... }
  container-or-leaf "bar" { ... }
  ...  // the "etc" ;)
}

And the goal is to use the grouping sans the "foo" node.
Can a "when" statement that always evaluates to "false"
do it?

grouping "bar-etc" {
  uses "foo-bar-etc" {
refine "foo" {
  when "false()";
}
  }
}

Any better ideas?

Thanks,
Kent



___
netmod mailing list
netmod@ietf.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod=DwIDaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=n8AUR8gtF330d96dqckvx53hCdyUm5tsTzJsm6DU83U=hD50p0RzLVzzTnQ62nxgs256wFf7UmIczTJMf9ym_n8= 


.






___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] choice/case in tree diagrams

[Per Hedeland]

On 2018-03-05 16:06, Ladislav Lhotka wrote:
> On Mon, 2018-03-05 at 15:49 +0100, Per Hedeland wrote:
>> On 2018-03-05 15:41, Ladislav Lhotka wrote:
>>> On Mon, 2018-03-05 at 15:26 +0100, Martin Bjorklund wrote:
>>>> Juergen Schoenwaelder <j.schoenwael...@jacobs-university.de> wrote:
>>>>> On Mon, Mar 05, 2018 at 02:54:18PM +0100, Martin Bjorklund wrote:
>>>>>>>
>>>>>>> So it seems the running code got it right. ;-)
>>>>>>
>>>>>> As the author of that code, I think that was purely by accident...
>>>>>>
>>>>>> But I'm not convinced it is the correct solution.  We have one example
>>>>>> in the other thread where someone was confused by the "rw" flag and
>>>>>> thought that it implied that the node would be present in the data
>>>>>> tree.
>>>>>>
>>>>>
>>>>> So what does rw mean?
>>>>>
>>>>> (i)  The schema node has a rw property.
>>>>> (ii) The schema node can be instantiated and the instantiated data node
>>>>>  has a rw property.
>>>>>
>>>>> I think it is difficult to have both at the same time. If the tree is
>>>>> a representation of schema nodes, then (i) seems to make more
>>>>> sense. That said, the explanation in 2.6 is somewhat vague since it
>>>>> says 'data' and not 'nodes' (like everywhere else):
>>>>>
>>>>> OLD:
>>>>>
>>>>> is one of:
>>>>>  rw  for configuration data
>>>>>  ro  for non-configuration data, output parameters to rpcs
>>>>>  and actions, and notification parameters
>>>>>
>>>>> NEW:
>>>>>
>>>>> is one of:
>>>>>  rw  for configuration data nodes
>>>>>  ro  for non-configuration data nodes, output parameters to rpcs
>>>>>  and actions, and notification parameters
>>>>
>>>> I think this is ok.  But that means that we also have to add:
>>>>
>>>>--  for a choice or case node
>>>>
>>>> But in order to be consistent, we should probably have:
>>>>
>>>>--  for a choice, case, input or output node
>>>
>>> But unlike the three other statements, "choice" can have the config
>>> substatement, so "rw/ro" makes sense there.
>>
>> I don't think so - that config statement does not a define a property of
>> the choice node (it can obviously neither be read nor written), only a
>> default for descendant data nodes, as described in section 7.21.1 of RFC
>> 7950.
> 
> It is not a default - if a choice has "config false", then no descendant can 
> be
> "config true". One of the benefits of having rw/ro in the ascii tree is to see
> where a state data subtree actually starts.

It is a default, but yes, it is also a restriction in the specific case
of the argument being "false" at a point where the default would
otherwise be "true". And in that case it is equivalent to having "config
false" on all the descendant data nodes, and they will of course be
flagged as "ro" regardless of whether the "config false" comes from the
choice or the individual data nodes - and that is where the state *data*
suntree(s) actually start(s).

So I guess the question then is whether this specific case motivates
always having flags on specifically choice nodes, while the other
non-data nodes have no flags. Since the 'config' statement is ignored in
rpc/action input/output and notification, choice nodes there should then
presumably have "-w"/"ro"/"-n". Personally I think the diagram is
clearer with flags only on the data nodes.

--Per

> Lada
> 
>>
>> --Per
>>
>>> Lada
>>>
>>>>
>>>>
>>>> This means that the correct tree syntax for choice and case will be:
>>>>
>>>>  +-- (subnet)?
>>>> +-- :(prefix-length)
>>>> |  +--rw prefix-length?   uint8
>>>> +-- :(netmask)
>>>>+--rw netmask? yang:dotted-quad
>>>>
>>>>
>>>> /martin
>>>>
>>>>
>>>>> The document (as far as I searched for it) does not clearly say that
>>>>> 'node' means 'schema node'. In hindsight, it might have been useful to
>>>>> explicitely import terminology from RFC 7950 and to use it carefully
>>>>> (RFC 7950 has 'schema node' and 'data node' but here we largely talk
>>>>> about 'nodes' - and my assumption is that this means 'schema nodes'.)
>>>>
>>>> ___
>>>> netmod mailing list
>>>> netmod@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/netmod
>>
>> ___
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] choice/case in tree diagrams

[Per Hedeland]

On 2018-03-05 15:41, Ladislav Lhotka wrote:
> On Mon, 2018-03-05 at 15:26 +0100, Martin Bjorklund wrote:
>> Juergen Schoenwaelder  wrote:
>>> On Mon, Mar 05, 2018 at 02:54:18PM +0100, Martin Bjorklund wrote:
>
> So it seems the running code got it right. ;-)

 As the author of that code, I think that was purely by accident...

 But I'm not convinced it is the correct solution.  We have one example
 in the other thread where someone was confused by the "rw" flag and
 thought that it implied that the node would be present in the data
 tree.

>>>
>>> So what does rw mean?
>>>
>>> (i)  The schema node has a rw property.
>>> (ii) The schema node can be instantiated and the instantiated data node
>>>  has a rw property.
>>>
>>> I think it is difficult to have both at the same time. If the tree is
>>> a representation of schema nodes, then (i) seems to make more
>>> sense. That said, the explanation in 2.6 is somewhat vague since it
>>> says 'data' and not 'nodes' (like everywhere else):
>>>
>>> OLD:
>>>
>>> is one of:
>>>  rw  for configuration data
>>>  ro  for non-configuration data, output parameters to rpcs
>>>  and actions, and notification parameters
>>>
>>> NEW:
>>>
>>> is one of:
>>>  rw  for configuration data nodes
>>>  ro  for non-configuration data nodes, output parameters to rpcs
>>>  and actions, and notification parameters
>>
>> I think this is ok.  But that means that we also have to add:
>>
>>--  for a choice or case node
>>
>> But in order to be consistent, we should probably have:
>>
>>--  for a choice, case, input or output node
> 
> But unlike the three other statements, "choice" can have the config
> substatement, so "rw/ro" makes sense there.

I don't think so - that config statement does not a define a property of
the choice node (it can obviously neither be read nor written), only a
default for descendant data nodes, as described in section 7.21.1 of RFC
7950.

--Per

> Lada
> 
>>
>>
>> This means that the correct tree syntax for choice and case will be:
>>
>>  +-- (subnet)?
>> +-- :(prefix-length)
>> |  +--rw prefix-length?   uint8
>> +-- :(netmask)
>>+--rw netmask? yang:dotted-quad
>>
>>
>> /martin
>>
>>
>>> The document (as far as I searched for it) does not clearly say that
>>> 'node' means 'schema node'. In hindsight, it might have been useful to
>>> explicitely import terminology from RFC 7950 and to use it carefully
>>> (RFC 7950 has 'schema node' and 'data node' but here we largely talk
>>> about 'nodes' - and my assumption is that this means 'schema nodes'.)
>>
>> ___
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] derived-from() vs derived-from-or-self() in acl model

[Per Hedeland]

On 2018-02-26 23:02, Mahesh Jethanandani wrote:




On Feb 26, 2018, at 1:31 PM, Per Hedeland <p...@tail-f.com> wrote:

On 2018-02-26 20:20, Mahesh Jethanandani wrote:

On Feb 26, 2018, at 9:01 AM, Per Hedeland <p...@tail-f.com 
<mailto:p...@tail-f.com>> wrote:

[Adding Cc todraft-ietf-netmod-acl-mo...@ietf.org 
<mailto:draft-ietf-netmod-acl-mo...@ietf.org>]

On 2018-02-26 14:24, Ladislav Lhotka wrote:

Per Hedeland <p...@tail-f.com <mailto:p...@tail-f.com>> writes:


Hi,

A customer of ours using one of the draft versions of the
ietf-access-control-list module reported that it was not possible to
configure an ethernet ace with type acl:eth-acl-type, due to the
derived-from() in

  container eth {
when "derived-from(../../../../type, " +
 "'acl:eth-acl-type')";
if-feature match-on-eth;
uses pf:acl-eth-header-fields;
description
  "Rule set that matches ethernet headers.";
  }

evaluating to "false". I pointed out that this is correct behavior of
our SW, since acl:eth-acl-type is not derived from acl:eth-acl-type, and
it would need to be derived-from-or-self() in order to evaluate to
"true". I also ventured a guess (not having followed the development of
the acl model in detail) that the intent was that vendors should define
their own identities, that actually *were* derived from acl:eth-acl-type
(and ditto for all the other *-acl-type identities, of course).

However I'm not at all sure that the guess is correct, and if so why
this should be *enforced* by excluding the base identity. And having a
look at the example in section 4.3 of draft-ietf-netmod-acl-model-16, it
seems to be doing exactly what our customer tried, alhough with
ipv4-acl-type:


  

  sample-ipv4-acl
  ipv4-acl-type
  

  rule1
  

  
tcp

As far as I can see, this snippet is invalid for the model, since the
'ipv4' container has

  container ipv4 {
when "derived-from(../../../../type, " +
 "'acl:ipv4-acl-type')";

- and ipv4-acl-type is *not* derived from ipv4-acl-type. (Of course
there shouldn't be any  element either, but that's another thing.)

So, is it the case that the derived-from()s should actually be
derived-from-or-self()s, or is the example wrong?


This has to do with the irreflexivity property of identity derivation,
which is, in my view, an unnecessary complication. It would be simpler
but sufficient to define derivation as a reflexive relation, and have
only one "derived-from()" XPath function.


Be that as it may, it is obviously not what RFC 7950 says.

I would agree that that is not how I am reading RFC 7950. For now my choice is 
to change all the derived-from() to derived-from-or-self().


I think that is a useful change. FWIW, when I actually tried the example
as the payload of an  towards our NETCONF server, I found
some other problems, which I believe are still relevant with the pull
request applied:

1) (Aldready mentioned) the  element corresponding to the choice in
the model should not be present (RFC 7950 section 7.9.5).


Removed . Although I have say the tree diagram confused me. It identifies 
l3 as a node with a +rw next to it, while for ipv4 it says +.


Hm... - the tree diagram has

||  +--rw (l3)?
||  |  +--:(ipv4)
||  |  |  +--rw ipv4 {match-on-ipv4}?

Where "(l3)?" is the choice, ":(ipv4)" is the case (not present in the
YANG module since it makes use of the "shorthand" per RFC 7950 section
7.9.2), and "ipv4" is the container (with its if-feature). The
latest/last tree diagram draft (-06) doesn't say anything in particular
about  for choice/case, so it would seem that it should be "rw"
for both choice and case in configuration data. I.e. the case should be
shown as

||  |  +--rw :(ipv4)

Latest pyang from github shows a 'case' as the first variant above
though, i.e. without both  and whitespace before the name. I
guess Martin will fix...

--Per


2) "tcp" is not a valid value for the 'protocol' leaf - from
ietf-packet-fie...@2018-02-02.yang:

leaf protocol {
  type uint8;
  description
"Internet Protocol number. Refers to the protocol of the
 payload. In IPv6, this field is known as 'next-header.";
  reference "RFC 719, RFC 2460.";
}

I.e. it should be "6". And the reference for this leaf, as well as for
'length' and 'ttl', should presumably be RFC 791, not RFC 719.


Changed it to 6, and 719 to 791.



3) 11.11.11.1/24 (for 'destination-ipv4-network') and 10.10.10.1/24 (for
'source-ipv4-network') are not valid (canonical) values for
inet:ipv4-pre

Re: [netmod] derived-from() vs derived-from-or-self() in acl model

[Per Hedeland]

On 2018-02-26 20:20, Mahesh Jethanandani wrote:




On Feb 26, 2018, at 9:01 AM, Per Hedeland <p...@tail-f.com 
<mailto:p...@tail-f.com>> wrote:

[Adding Cc todraft-ietf-netmod-acl-mo...@ietf.org 
<mailto:draft-ietf-netmod-acl-mo...@ietf.org>]

On 2018-02-26 14:24, Ladislav Lhotka wrote:

Per Hedeland <p...@tail-f.com <mailto:p...@tail-f.com>> writes:


Hi,

A customer of ours using one of the draft versions of the
ietf-access-control-list module reported that it was not possible to
configure an ethernet ace with type acl:eth-acl-type, due to the
derived-from() in

  container eth {
when "derived-from(../../../../type, " +
 "'acl:eth-acl-type')";
if-feature match-on-eth;
uses pf:acl-eth-header-fields;
description
  "Rule set that matches ethernet headers.";
  }

evaluating to "false". I pointed out that this is correct behavior of
our SW, since acl:eth-acl-type is not derived from acl:eth-acl-type, and
it would need to be derived-from-or-self() in order to evaluate to
"true". I also ventured a guess (not having followed the development of
the acl model in detail) that the intent was that vendors should define
their own identities, that actually *were* derived from acl:eth-acl-type
(and ditto for all the other *-acl-type identities, of course).

However I'm not at all sure that the guess is correct, and if so why
this should be *enforced* by excluding the base identity. And having a
look at the example in section 4.3 of draft-ietf-netmod-acl-model-16, it
seems to be doing exactly what our customer tried, alhough with
ipv4-acl-type:


  

  sample-ipv4-acl
  ipv4-acl-type
  

  rule1
  

  
tcp

As far as I can see, this snippet is invalid for the model, since the
'ipv4' container has

  container ipv4 {
when "derived-from(../../../../type, " +
 "'acl:ipv4-acl-type')";

- and ipv4-acl-type is *not* derived from ipv4-acl-type. (Of course
there shouldn't be any  element either, but that's another thing.)

So, is it the case that the derived-from()s should actually be
derived-from-or-self()s, or is the example wrong?


This has to do with the irreflexivity property of identity derivation,
which is, in my view, an unnecessary complication. It would be simpler
but sufficient to define derivation as a reflexive relation, and have
only one "derived-from()" XPath function.


Be that as it may, it is obviously not what RFC 7950 says.


I would agree that that is not how I am reading RFC 7950. For now my choice is 
to change all the derived-from() to derived-from-or-self().


I think that is a useful change. FWIW, when I actually tried the example
as the payload of an  towards our NETCONF server, I found
some other problems, which I believe are still relevant with the pull
request applied:

1) (Aldready mentioned) the  element corresponding to the choice in
the model should not be present (RFC 7950 section 7.9.5).

2) "tcp" is not a valid value for the 'protocol' leaf - from
ietf-packet-fie...@2018-02-02.yang:

leaf protocol {
  type uint8;
  description
"Internet Protocol number. Refers to the protocol of the
 payload. In IPv6, this field is known as 'next-header.";
  reference "RFC 719, RFC 2460.";
}

I.e. it should be "6". And the reference for this leaf, as well as for
'length' and 'ttl', should presumably be RFC 791, not RFC 719.

3) 11.11.11.1/24 (for 'destination-ipv4-network') and 10.10.10.1/24 (for
'source-ipv4-network') are not valid (canonical) values for
inet:ipv4-prefix - from ietf-inet-types.yang:

  The canonical format of an IPv4 prefix has all bits of
  the IPv4 address set to zero that are not part of the
  IPv4 prefix.";

And of course it doesn't make much sense to have bits outside the prefix
length set for a match specification. It seems the pull request changes
these prefixes to RFC 1918 / RFC 5737 space, but those prefixes have
the same issue.

I'm attaching the output from a  towards our NETCONF server
with these issues fixed (and the derived-from() ->
derived-from-or-self() change made).

--Per




Identities that are considered "abstract" should not be instantiated, and
then derived-from() and derived-from-or-self() give the same result.


So I guess your take is that the *-acl-type identities derived from
acl:acl-base in the ietf-access-control-list module should be considered
"abstract", and thus the example should not use ipv4-acl-type for the
'type' leaf, but instead some other identity derived from
acl:ipv4-acl-type. Do the authors agree?

--Per


Lada



--Per Hedeland

Re: [netmod] derived-from() vs derived-from-or-self() in acl model

[Per Hedeland]

[Adding Cc to draft-ietf-netmod-acl-mo...@ietf.org]

On 2018-02-26 14:24, Ladislav Lhotka wrote:
> Per Hedeland <p...@tail-f.com> writes:
> 
>> Hi,
>>
>> A customer of ours using one of the draft versions of the
>> ietf-access-control-list module reported that it was not possible to
>> configure an ethernet ace with type acl:eth-acl-type, due to the
>> derived-from() in
>>
>>container eth {
>>  when "derived-from(../../../../type, " +
>>   "'acl:eth-acl-type')";
>>  if-feature match-on-eth;
>>  uses pf:acl-eth-header-fields;
>>  description
>>"Rule set that matches ethernet headers.";
>>}
>>
>> evaluating to "false". I pointed out that this is correct behavior of
>> our SW, since acl:eth-acl-type is not derived from acl:eth-acl-type, and
>> it would need to be derived-from-or-self() in order to evaluate to
>> "true". I also ventured a guess (not having followed the development of
>> the acl model in detail) that the intent was that vendors should define
>> their own identities, that actually *were* derived from acl:eth-acl-type
>> (and ditto for all the other *-acl-type identities, of course).
>>
>> However I'm not at all sure that the guess is correct, and if so why
>> this should be *enforced* by excluding the base identity. And having a
>> look at the example in section 4.3 of draft-ietf-netmod-acl-model-16, it
>> seems to be doing exactly what our customer tried, alhough with
>> ipv4-acl-type:
>>
>> 
>>> xmlns="urn:ietf:params:xml:ns:yang:ietf-access-control-list">
>>  
>>sample-ipv4-acl
>>ipv4-acl-type
>>
>>  
>>rule1
>>
>>  
>>
>>  tcp
>>
>> As far as I can see, this snippet is invalid for the model, since the
>> 'ipv4' container has
>>
>>container ipv4 {
>>  when "derived-from(../../../../type, " +
>>   "'acl:ipv4-acl-type')";
>>
>> - and ipv4-acl-type is *not* derived from ipv4-acl-type. (Of course
>> there shouldn't be any  element either, but that's another thing.)
>>
>> So, is it the case that the derived-from()s should actually be
>> derived-from-or-self()s, or is the example wrong?
> 
> This has to do with the irreflexivity property of identity derivation,
> which is, in my view, an unnecessary complication. It would be simpler
> but sufficient to define derivation as a reflexive relation, and have
> only one "derived-from()" XPath function.

Be that as it may, it is obviously not what RFC 7950 says.

> Identities that are considered "abstract" should not be instantiated, and
> then derived-from() and derived-from-or-self() give the same result.

So I guess your take is that the *-acl-type identities derived from
acl:acl-base in the ietf-access-control-list module should be considered
"abstract", and thus the example should not use ipv4-acl-type for the
'type' leaf, but instead some other identity derived from
acl:ipv4-acl-type. Do the authors agree?

--Per

> Lada
> 
>>
>> --Per Hedeland
>>
>> ___
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
> 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] derived-from() vs derived-from-or-self() in acl model

[Per Hedeland]

Hi,

A customer of ours using one of the draft versions of the
ietf-access-control-list module reported that it was not possible to
configure an ethernet ace with type acl:eth-acl-type, due to the
derived-from() in

  container eth {
when "derived-from(../../../../type, " +
 "'acl:eth-acl-type')";
if-feature match-on-eth;
uses pf:acl-eth-header-fields;
description
  "Rule set that matches ethernet headers.";
  }

evaluating to "false". I pointed out that this is correct behavior of
our SW, since acl:eth-acl-type is not derived from acl:eth-acl-type, and
it would need to be derived-from-or-self() in order to evaluate to
"true". I also ventured a guess (not having followed the development of
the acl model in detail) that the intent was that vendors should define
their own identities, that actually *were* derived from acl:eth-acl-type
(and ditto for all the other *-acl-type identities, of course).

However I'm not at all sure that the guess is correct, and if so why
this should be *enforced* by excluding the base identity. And having a
look at the example in section 4.3 of draft-ietf-netmod-acl-model-16, it
seems to be doing exactly what our customer tried, alhough with
ipv4-acl-type:


  

  sample-ipv4-acl
  ipv4-acl-type
  

  rule1
  

  
tcp

As far as I can see, this snippet is invalid for the model, since the
'ipv4' container has

  container ipv4 {
when "derived-from(../../../../type, " +
 "'acl:ipv4-acl-type')";

- and ipv4-acl-type is *not* derived from ipv4-acl-type. (Of course
there shouldn't be any  element either, but that's another thing.)

So, is it the case that the derived-from()s should actually be
derived-from-or-self()s, or is the example wrong?

--Per Hedeland

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] [Netconf] Retrieving Information Pointed by leafref

[Per Hedeland]

I already showed you an XPath filter expression that will do what you
originally asked for, i.e. retrieve the data for a tunnel and the
associated 'explicit-path's in a single request, based on the
(simplified) data model that you provided. What you are describing now
seems like just variations on the theme - as I wrote, it is the client
that decides, via the XPath expression, which leafref-leafs that should
be "dereferenced" for selection of additional data.

I'm afraid I don't have the time to craft XPath expressions for each and
every one of your use cases (and I wouldn't trust them to be correct
without testing anyway). I also provided a link to the definition of the
XPath capability in the NETCONF spec. XPath itself is well-established
technology, not specific to NETCONF or YANG. I suggest that you consult
the specification at http://www.w3.org/TR/1999/REC-xpath-19991116 and/or
one of the many tutorials or even books dedicated to the subject - I
don't have any specific recommendations for the latter, but maybe
someone else does.

--Per

On 2017-10-10 00:11, Igor Bryskin wrote:

Hi Per,

This is a good news, but, please, help us out.
Consider, we have a node - "te-tunnel" - which among other attributes has two 
key leafref lists:
1) each member of the 1st list points to a "connection" supporting the 
te-tunnel. All connections supporting all te-tunnels are stored in a single list of 
connections.
2) each member of the 2nd list points to a supporting "te-tunnel" - the 
te-tunnel in question depends on. All te=tunnels including the te-tunnel in question, are 
stored in a single list of te-tunnels.

The question: how the client can retrieve via a single request all attributes 
of the te-tunnel in question along with all parameters of all connections 
supporting the te-tunnel, but with just pointers to supporting te-tunnels (so 
that the interested client can use the pointers to retrieve full data via 
subsequent separate requests) ?

Likewise, how the client can ask for full data of the te-tunnel and all 
supporting te-tunnels and just pointers for supporting connections?

I really appreciate your help,

Igor

  
-Original Message-

From: Per Hedeland [mailto:p...@tail-f.com]
Sent: Monday, October 09, 2017 5:21 PM
To: Igor Bryskin
Cc: m...@tail-f.com; xufeng.liu.i...@gmail.com; netc...@ietf.org; 
netmod@ietf.org
Subject: Re: [Netconf] [netmod] Retrieving Information Pointed by leafref

Just to be clear: what we're suggesting is that you can use the
already-existing standard NETCONF XPath capability to achieve the desired
result - see https://tools.ietf.org/html/rfc6241#section-8.9

--Per

On 2017-10-09 21:52, Igor Bryskin wrote:

I agree. For example, a leafref may point not to a singls entity, but to a list 
of entities, and the client might want to expand all of them into the joint get 
response.

Igor

*From:*Per Hedeland
*To:*Martin Bjorklund,
*Cc:*Igor Bryskin,xufeng.liu.i...@gmail.com,netc...@ietf.org,netmod@ietf.org,
*Date:*2017-10-09 15:12:22
*Subject:*Re: [Netconf] [netmod] Retrieving Information Pointed by leafref

On 2017-10-09 19:13, Martin Bjorklund wrote:

Igor Bryskin <igor.brys...@huawei.com> wrote:


Hi Per,

Basically, what we need is a way for a client to request something
like this:

get  joint with <XPath1, XPath2, ..., XPathn>


... which is what Per's expression does!  Note that "|" in XPath means
"union".

But as Per explained, it only works in some cases (when the leafref
acts a "single pointer").


Well, that particular expression works only in that case - but since it
is effectively the client that (perhaps based on the data model) decides
what the leafref-leafs "mean" (in this case the single key of a single
list), other cases can be handled the same way. E.g. multiple
leafref-to-key leafs that together give the keys of a multi-key list
just amounts to a slightly hairier XPath filter...

--Per


with a server interpreting the request as follows:
if a node pointed by XPath contains a pointer (e.g. key leafref)
matching one of the XPath from the "joint with" list, then the server
must provide the entire body of the node pointed by the pointer,
otherwise, just the pointer (as it happens today, that is, when no
"joint with" list specified).

We think that this would allow for the client to optimize the number
of request-response iterations depending on application/use case.

Regards,
Igor




/martin









-Original Message-
From: Per Hedeland [mailto:p...@tail-f.com]
Sent: Monday, October 09, 2017 12:06 PM
To: Xufeng Liu
Cc: Igor Bryskin; netc...@ietf.org; netmod@ietf.org
Subject: Re: [Netconf] [netmod] Retrieving Information Pointed by
leafref

I understand your use case, but a leaf of type leafref does not in
general identify a single node in the data tree - the leafref path
could
be for a non-key leaf, and/or the path could traverse list 

Re: [netmod] [Netconf] Retrieving Information Pointed by leafref

[Per Hedeland]

Just to be clear: what we're suggesting is that you can use the
already-existing standard NETCONF XPath capability to achieve the desired
result - see https://tools.ietf.org/html/rfc6241#section-8.9

--Per

On 2017-10-09 21:52, Igor Bryskin wrote:

I agree. For example, a leafref may point not to a singls entity, but to a list 
of entities, and the client might want to expand all of them into the joint get 
response.

Igor

*From:*Per Hedeland
*To:*Martin Bjorklund,
*Cc:*Igor Bryskin,xufeng.liu.i...@gmail.com,netc...@ietf.org,netmod@ietf.org,
*Date:*2017-10-09 15:12:22
*Subject:*Re: [Netconf] [netmod] Retrieving Information Pointed by leafref

On 2017-10-09 19:13, Martin Bjorklund wrote:

Igor Bryskin <igor.brys...@huawei.com> wrote:


Hi Per,

Basically, what we need is a way for a client to request something
like this:

get  joint with <XPath1, XPath2, ..., XPathn>


... which is what Per's expression does!  Note that "|" in XPath means
"union".

But as Per explained, it only works in some cases (when the leafref
acts a "single pointer").


Well, that particular expression works only in that case - but since it
is effectively the client that (perhaps based on the data model) decides
what the leafref-leafs "mean" (in this case the single key of a single
list), other cases can be handled the same way. E.g. multiple
leafref-to-key leafs that together give the keys of a multi-key list
just amounts to a slightly hairier XPath filter...

--Per


with a server interpreting the request as follows:
if a node pointed by XPath contains a pointer (e.g. key leafref)
matching one of the XPath from the "joint with" list, then the server
must provide the entire body of the node pointed by the pointer,
otherwise, just the pointer (as it happens today, that is, when no
"joint with" list specified).

We think that this would allow for the client to optimize the number
of request-response iterations depending on application/use case.

Regards,
Igor




/martin









-Original Message-
From: Per Hedeland [mailto:p...@tail-f.com]
Sent: Monday, October 09, 2017 12:06 PM
To: Xufeng Liu
Cc: Igor Bryskin; netc...@ietf.org; netmod@ietf.org
Subject: Re: [Netconf] [netmod] Retrieving Information Pointed by
leafref

I understand your use case, but a leaf of type leafref does not in
general identify a single node in the data tree - the leafref path
could
be for a non-key leaf, and/or the path could traverse list nodes,
and/or
the "target" list could have multiple keys and thus multiple
leafref-leafs be required to identify a specific list entry.

Thus it seems to me that your use case is not a reasonable basis for a
new protocol operation. My XPath foo isn't very good either, but I do
believe Robert's suggestion of using an XPath filter could be a way
forward. I *think* the filter expression would be something along the
lines of

  /te/tunnels/tunnel[name='foo'] |
  
/te/explicit-paths/explicit-path[name=/te/tunnels/tunnel[name='foo']/paths/path/explicit-path]

--Per

On 2017-10-09 15:42, Xufeng Liu wrote:

Hi Per,

  


*From:* Igor Bryskin [mailto:igor.brys...@huawei.com]
*Sent:* Sunday, October 8, 2017 7:04 PM
*To:* Igor Bryskin <igor.brys...@huawei.com>; p...@tail-f.com;
*xufeng.liu.i...@gmail.com
*Cc:* netc...@ietf.org; netmod@ietf.org
*Subject:* Re: [Netconf] [netmod] Retrieving Information Pointed by
*leafref

  



Hi Joel,

Thanks, I think I didnt explain our problem correctly.

In our case we have a leafref pointing to a te tunnel name, which
happens to be a key to lookup the (axilary) tunnel.  We need a way to
include the entire tunnel body (not just a name) into the get
response. This is to optimize the number of iterations between the
client and the server. As Xufeng put it something similar to SQL join,

Igor

*From:*Igor Bryskin

*To:*p...@tail-f.com,xufeng.liu.i...@gmail.com,

*Cc:*netc...@ietf.org,netmod@ietf.org,

*Date:*2017-10-08 17:36:47

*Subject:*Re: [Netconf] [netmod] Retrieving Information Pointed by
*leafref

  


Hi Per,

In a nutshell we would lika for a netconf client to have a way to
instruct the server on whether in response to the get request the
server needs to provide the entire body of a datastore node pointed
to by a leafref or just a pointer to said node, so that the node's
body could be retrieved by a subsequent separate request. This is
requested by implementors who want to optimise rhe number of
interactions between a client and its server.

Cheers,
Igor

*From:*Per Hedeland

*To:*Xufeng Liu,

*Cc:*netc...@ietf.org,'NetMod WG',

*Date:*2017-10-08 14:01:27

*Subject:*Re: [Netconf] [netmod] Retrieving Information Pointed by
*leafref

  


On 2017-10-06 23:11, Xufeng Liu wrote:

During the design team discussion for TE and MPLS YANG modeling, we
have received a request from implementers: How to minimize the number
of NETCONF/RESTCONF RPCs to improve operation efficiency?
Especially for the

Re: [netmod] [Netconf] Retrieving Information Pointed by leafref

[Per Hedeland]

On 2017-10-09 19:13, Martin Bjorklund wrote:

Igor Bryskin <igor.brys...@huawei.com> wrote:


Hi Per,

Basically, what we need is a way for a client to request something
like this:

get  joint with <XPath1, XPath2, ..., XPathn>


... which is what Per's expression does!  Note that "|" in XPath means
"union".

But as Per explained, it only works in some cases (when the leafref
acts a "single pointer").


Well, that particular expression works only in that case - but since it
is effectively the client that (perhaps based on the data model) decides
what the leafref-leafs "mean" (in this case the single key of a single
list), other cases can be handled the same way. E.g. multiple
leafref-to-key leafs that together give the keys of a multi-key list
just amounts to a slightly hairier XPath filter...

--Per


with a server interpreting the request as follows:
if a node pointed by XPath contains a pointer (e.g. key leafref)
matching one of the XPath from the "joint with" list, then the server
must provide the entire body of the node pointed by the pointer,
otherwise, just the pointer (as it happens today, that is, when no
"joint with" list specified).

We think that this would allow for the client to optimize the number
of request-response iterations depending on application/use case.

Regards,
Igor




/martin









-Original Message-
From: Per Hedeland [mailto:p...@tail-f.com]
Sent: Monday, October 09, 2017 12:06 PM
To: Xufeng Liu
Cc: Igor Bryskin; netc...@ietf.org; netmod@ietf.org
Subject: Re: [Netconf] [netmod] Retrieving Information Pointed by
leafref

I understand your use case, but a leaf of type leafref does not in
general identify a single node in the data tree - the leafref path
could
be for a non-key leaf, and/or the path could traverse list nodes,
and/or
the "target" list could have multiple keys and thus multiple
leafref-leafs be required to identify a specific list entry.

Thus it seems to me that your use case is not a reasonable basis for a
new protocol operation. My XPath foo isn't very good either, but I do
believe Robert's suggestion of using an XPath filter could be a way
forward. I *think* the filter expression would be something along the
lines of

  /te/tunnels/tunnel[name='foo'] |
  
/te/explicit-paths/explicit-path[name=/te/tunnels/tunnel[name='foo']/paths/path/explicit-path]

--Per

On 2017-10-09 15:42, Xufeng Liu wrote:

Hi Per,

  


*From:* Igor Bryskin [mailto:igor.brys...@huawei.com]
*Sent:* Sunday, October 8, 2017 7:04 PM
*To:* Igor Bryskin <igor.brys...@huawei.com>; p...@tail-f.com;
*xufeng.liu.i...@gmail.com
*Cc:* netc...@ietf.org; netmod@ietf.org
*Subject:* Re: [Netconf] [netmod] Retrieving Information Pointed by
*leafref

  



Hi Joel,

Thanks, I think I didnt explain our problem correctly.

In our case we have a leafref pointing to a te tunnel name, which
happens to be a key to lookup the (axilary) tunnel.  We need a way to
include the entire tunnel body (not just a name) into the get
response. This is to optimize the number of iterations between the
client and the server. As Xufeng put it something similar to SQL join,

Igor

*From:*Igor Bryskin

*To:*p...@tail-f.com,xufeng.liu.i...@gmail.com,

*Cc:*netc...@ietf.org,netmod@ietf.org,

*Date:*2017-10-08 17:36:47

*Subject:*Re: [Netconf] [netmod] Retrieving Information Pointed by
*leafref

  


Hi Per,

In a nutshell we would lika for a netconf client to have a way to
instruct the server on whether in response to the get request the
server needs to provide the entire body of a datastore node pointed
to by a leafref or just a pointer to said node, so that the node's
body could be retrieved by a subsequent separate request. This is
requested by implementors who want to optimise rhe number of
interactions between a client and its server.

Cheers,
Igor

*From:*Per Hedeland

*To:*Xufeng Liu,

*Cc:*netc...@ietf.org,'NetMod WG',

*Date:*2017-10-08 14:01:27

*Subject:*Re: [Netconf] [netmod] Retrieving Information Pointed by
*leafref

  


On 2017-10-06 23:11, Xufeng Liu wrote:

During the design team discussion for TE and MPLS YANG modeling, we
have received a request from implementers: How to minimize the number
of NETCONF/RESTCONF RPCs to improve operation efficiency?
Especially for the case when the operator or client software needs to
retrieve the object contents pointed by a leafref.

For example, given the following simplified TE tunnel model,

+--rw te

  +--rw explicit-paths

  |  +--rw explicit-path* [name]

  | +--rw name  string

  |+--rw explicit-route-object* [index]

  |   +--rw index   uint32

  |   +--rw explicit-route-usage?   identityref

  +--rw tunnels

  |  +--rw tunnel* [name]

  |  |  +--rw name   string

  |  |  +--rw paths

  |  |  |  +--rw path* [name]

|  |  | +--rw explicit-path?

Re: [netmod] [Netconf] Retrieving Information Pointed by leafref

[Per Hedeland]

I understand your use case, but a leaf of type leafref does not in
general identify a single node in the data tree - the leafref path could
be for a non-key leaf, and/or the path could traverse list nodes, and/or
the "target" list could have multiple keys and thus multiple
leafref-leafs be required to identify a specific list entry.

Thus it seems to me that your use case is not a reasonable basis for a
new protocol operation. My XPath foo isn't very good either, but I do
believe Robert's suggestion of using an XPath filter could be a way
forward. I *think* the filter expression would be something along the
lines of

 /te/tunnels/tunnel[name='foo'] | 
/te/explicit-paths/explicit-path[name=/te/tunnels/tunnel[name='foo']/paths/path/explicit-path]

--Per

On 2017-10-09 15:42, Xufeng Liu wrote:
> Hi Per,
> 
>  
> 
> *From:* Igor Bryskin [mailto:igor.brys...@huawei.com]
> *Sent:* Sunday, October 8, 2017 7:04 PM
> *To:* Igor Bryskin <igor.brys...@huawei.com>; p...@tail-f.com; 
> xufeng.liu.i...@gmail.com
> *Cc:* netc...@ietf.org; netmod@ietf.org
> *Subject:* Re: [Netconf] [netmod] Retrieving Information Pointed by leafref
> 
>  
> 
> 
> Hi Joel,
> 
> Thanks, I think I didnt explain our problem correctly.
> 
> In our case we have a leafref pointing to a te tunnel name, which happens to 
> be a key to lookup the (axilary) tunnel.  We need  a way to include the 
> entire tunnel body (not just a name) into the get
> response. This is to optimize the number of iterations between the client and 
> the server. As Xufeng put it something similar to SQL join,
> 
> Igor
> 
> *From:*Igor Bryskin
> 
> *To:*p...@tail-f.com,xufeng.liu.i...@gmail.com,
> 
> *Cc:*netc...@ietf.org,netmod@ietf.org,
> 
> *Date:*2017-10-08 17:36:47
> 
> *Subject:*Re: [Netconf] [netmod] Retrieving Information Pointed by leafref
> 
>  
> 
> Hi Per,
> 
> In a nutshell we would lika for a netconf client to have a way  to instruct 
> the server on whether in response to the get request the server needs to 
> provide the entire body of a datastore node pointed
> to by a leafref or just a pointer to said node, so that the node's body could 
> be retrieved by a subsequent separate request. This is requested by 
> implementors who want to optimise rhe number of
> interactions between a client and its server.
> 
> Cheers,
> Igor
> 
> *From:*Per Hedeland
> 
> *To:*Xufeng Liu,
> 
> *Cc:*netc...@ietf.org,'NetMod WG',
> 
> *Date:*2017-10-08 14:01:27
> 
> *Subject:*Re: [Netconf] [netmod] Retrieving Information Pointed by leafref
> 
>  
> 
> On 2017-10-06 23:11, Xufeng Liu wrote:
>> During the design team discussion for TE and MPLS YANG modeling, we have 
>> received a request from implementers: How to minimize the number of 
>> NETCONF/RESTCONF RPCs to improve operation efficiency? 
>> Especially for the case when the operator or client software needs to 
>> retrieve the object contents pointed by a leafref.
>> 
>> For example, given the following simplified TE tunnel model,
>> 
>> +--rw te
>> 
>>  +--rw explicit-paths
>> 
>>  |  +--rw explicit-path* [name]
>> 
>>  | +--rw name  string
>> 
>>  |+--rw explicit-route-object* [index]
>> 
>>  |   +--rw index   uint32
>> 
>>  |   +--rw explicit-route-usage?   identityref
>> 
>>  +--rw tunnels
>> 
>>  |  +--rw tunnel* [name]
>> 
>>  |  |  +--rw name   string
>> 
>>  |  |  +--rw paths
>> 
>>  |  |  |  +--rw path* [name]
>> 
>> |  |  | +--rw explicit-path?  -> 
>> ../../../../../explicit-paths/explicit-path/name
>> 
>> when the client tries to retrieve a tunnels information based on the tunnel 
>> name, the get operation returns a list of leafrefs pointing to the paths of 
>> the tunnel.
> 
> Sorry, I'm afraid I don't follow. Can you explain exactly what your
> "get" request is (protocol and payload), and where the "list of
> leafref's" (whatever that may be) occurs in the reply?
> 
> */[Xufeng]  The get operation is the NETCONF/RESTCON  protocol 
> operation, or the  operation described in 
> https://tools.ietf.org/html/draft-dsdt-nmda-netconf-01 and the GET operations
> on {+restconf}/ds/ described in  
> https://tools.ietf.org/html/draft-ietf-netconf-nmda-restconf-00./*
> 
> */ /*
> 
> */We have a list of leafref values because in this example model, each tunnel 
> contains a list of paths, each of them contains a leafref. The get returns 
> a value for each instance of such a leafref,
&

Re: [netmod] Retrieving Information Pointed by leafref

[Per Hedeland]

On 2017-10-06 23:11, Xufeng Liu wrote:
During the design team discussion for TE and MPLS YANG modeling, we have received a request from implementers: How to minimize the number of NETCONF/RESTCONF RPCs to improve operation efficiency? 
Especially for the case when the operator or client software needs to retrieve the object contents pointed by a leafref.


For example, given the following simplified TE tunnel model,

+--rw te

 +--rw explicit-paths

 |  +--rw explicit-path* [name]

 | +--rw name  string

 |+--rw explicit-route-object* [index]

 |   +--rw index   uint32

 |   +--rw explicit-route-usage?   identityref

 +--rw tunnels

 |  +--rw tunnel* [name]

 |  |  +--rw name   string

 |  |  +--rw paths

 |  |  |  +--rw path* [name]

|  |  | +--rw explicit-path?  -> 
../../../../../explicit-paths/explicit-path/name

when the client tries to retrieve a tunnels information based on the tunnel 
name, the get operation returns a list of leafrefs pointing to the paths of 
the tunnel.


Sorry, I'm afraid I don't follow. Can you explain exactly what your
"get" request is (protocol and payload), and where the "list of
leafref's" (whatever that may be) occurs in the reply?

JFYI, in case there is some fundamental misunderstanding here: a leaf of
type leafref has a single value - *one* of those that satisfy the leafref
constraint, in case there are multiple "candidates".

--Per

The client needs to issue at 
least one more get operation to retrieve the path information about the given tunnel. The request is to combine these two operations into one.


In the RDBMS SQL world, join can be used when SQL select is performed, but 
NETCONF/YANG currently does not have this capability.

Wed like to ask whether such a request is considered reasonable.

If the request is reasonable, the next question is how to proceed. This seems to be a protocol issue rather than YANG modeling issue. Is it acceptable to add a new operation to achieve such a 
 operation with expanded leafrefs?


Comments and suggestions are appreciated.

Thanks,

- Xufeng



___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod



___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] schema mount open issue #1

[Per Hedeland]

On 2017-08-29 15:40, Lou Berger wrote:
> 
> 
> On August 29, 2017 9:03:22 AM Per Hedeland <p...@tail-f.com> wrote:
> 
>> On 2017-08-29 14:34, Lou Berger wrote:
>>> On 08/29/2017 03:37 AM, Martin Bjorklund wrote:
>>>> Lou Berger <lber...@labn.net> wrote:
>>>>> Lada,
>>>>>
>>>>>
>>>>> On 8/28/2017 10:16 AM, Ladislav Lhotka wrote:
>>>>>> Lou Berger píae v Po 28. 08. 2017 v 09:40 -0400:
>>>>>>> Lada,
>>>>>>>
>>>>>>> On 8/28/2017 9:30 AM, Ladislav Lhotka wrote:
>>>>>>>>> Can you please take a look at it and see if we have any other 
>>>>>>>>> disconnects?
>>>>>>>> This is really scary.
>>>>>>> I agree!
>>>>>>>
>>>>>>>> How can we expect poor data modellers to understand the
>>>>>>>> concept if we have such fundamental disconnects, after so many hours of
>>>>>>>> discussing it?
>>>>>>> This highlights why getting the text in (any) document is so important,
>>>>>>> and why discussions shouldn't be viewed as being closed until the impact
>>>>>>> on the text is agreed to!
>>>>>> I think many people still don't make much distinction between schema 
>>>>>> mount
>>>>>> (manipulation of the schema) and data mount. I still believe we need to 
>>>>>> clearly
>>>>>> separate these two concepts, preferably using two different mechanisms.
>>>>>
>>>>> Frankly, I'm focused on removing blocking issues on the current WG
>>>>> deliverable, i.e., schema mount.
>>>>> ...
>>>>>>> Lou
>>>>>>>
>>>>>>> PS is your view aligned with martin or our example?
>>>>>> If you mean shifting the XPath context node to the mount point instance, 
>>>>>> then
>>>>>> yes.
>>>>>
>>>>> funny, you answered yes to a choice!  I was asking if you think the
>>>>> mount point shows up as a node in the data tree, i.e., as shown in the
>>>>> example in
>>>>> https://tools.ietf.org/html/draft-ietf-rtgwg-ni-model-03#appendix-B.1?
>>>>>
>>>>> from my perspective and my co-authors in the RTG area using schema
>>>>> mount, we've never heard of a (filesystem) mount point that doesn't show
>>>>> in the (directory) structure and this is the mental analogue we've been
>>>>> assuming. Since there never was an explicit example/discussion or text
>>>>> to dissuade us of this
>>>>
>>>> The current text says:
>>>>
>>>>   A "container" or "list" node becomes a mount point if the
>>>>   "mount-point" extension (defined in the "ietf-yang-schema-mount"
>>>>   module) is used in its definition.
>>>
>>> interesting, read that a few times to (now) get the gist of your intent.
>>>
>>>>
>>>> But of course we should clarify this.
>>>>
>>>
>>>
>>>
>>>>> , this disconnect was never noticed.  Certainly
>>>>> this needs to be explicit in the document (either way). The following
>>>>> change could be made to the schema mount draft (at a minimum):
>>>>>
>>>>> OLD
>>>>>   A mount point defines a place in the node hierarchy where
>>>>>   other data models may be attached. A server that implements a
>>>>> NEW
>>>>>   A mount point defines a node in a data tree under which
>>>>> instances of
>>>>>   other data models may be attached. A server that implements a
>>>>
>>>> I strongly object to letting the extension define a new data node.
>>>
>>>> This would be a new type of data node that presumably look a lot like
>>>> a container,
>>>
>>> agreed, just like a mount point looks a lot like a directory in a unix
>>> file system.
>>
>> It seems to me that the schema mount concept is 100% equivalent to the
>> Unix file system analogy in this particular respect. You need a
>> pre-existing directory to mount a remote file system (or for that matter
>> a disk device). The directory gains the property of being a mount point
>

Re: [netmod] schema mount open issue #1

[Per Hedeland]

On 2017-08-29 14:34, Lou Berger wrote:
> On 08/29/2017 03:37 AM, Martin Bjorklund wrote:
>> Lou Berger  wrote:
>>> Lada,
>>>
>>>
>>> On 8/28/2017 10:16 AM, Ladislav Lhotka wrote:
 Lou Berger píae v Po 28. 08. 2017 v 09:40 -0400:
> Lada,
>
> On 8/28/2017 9:30 AM, Ladislav Lhotka wrote:
>>> Can you please take a look at it and see if we have any other 
>>> disconnects?
>> This is really scary. 
> I agree!
>
>> How can we expect poor data modellers to understand the
>> concept if we have such fundamental disconnects, after so many hours of
>> discussing it?
> This highlights why getting the text in (any) document is so important,
> and why discussions shouldn't be viewed as being closed until the impact
> on the text is agreed to!
 I think many people still don't make much distinction between schema mount
 (manipulation of the schema) and data mount. I still believe we need to 
 clearly
 separate these two concepts, preferably using two different mechanisms.
>>>
>>> Frankly, I'm focused on removing blocking issues on the current WG
>>> deliverable, i.e., schema mount.
>>> ...
> Lou
>
> PS is your view aligned with martin or our example?
 If you mean shifting the XPath context node to the mount point instance, 
 then
 yes.
>>>
>>> funny, you answered yes to a choice!  I was asking if you think the
>>> mount point shows up as a node in the data tree, i.e., as shown in the
>>> example in
>>> https://tools.ietf.org/html/draft-ietf-rtgwg-ni-model-03#appendix-B.1?
>>>
>>> from my perspective and my co-authors in the RTG area using schema
>>> mount, we've never heard of a (filesystem) mount point that doesn't show
>>> in the (directory) structure and this is the mental analogue we've been
>>> assuming. Since there never was an explicit example/discussion or text
>>> to dissuade us of this
>>
>> The current text says:
>>
>>   A "container" or "list" node becomes a mount point if the
>>   "mount-point" extension (defined in the "ietf-yang-schema-mount"
>>   module) is used in its definition.
> 
> interesting, read that a few times to (now) get the gist of your intent.
> 
>>
>> But of course we should clarify this.
>>
> 
> 
> 
>>> , this disconnect was never noticed.  Certainly
>>> this needs to be explicit in the document (either way). The following
>>> change could be made to the schema mount draft (at a minimum):
>>>
>>> OLD
>>>   A mount point defines a place in the node hierarchy where
>>>   other data models may be attached. A server that implements a
>>> NEW
>>>   A mount point defines a node in a data tree under which
>>> instances of
>>>   other data models may be attached. A server that implements a
>>
>> I strongly object to letting the extension define a new data node.
> 
>> This would be a new type of data node that presumably look a lot like
>> a container, 
> 
> agreed, just like a mount point looks a lot like a directory in a unix
> file system.

It seems to me that the schema mount concept is 100% equivalent to the
Unix file system analogy in this particular respect. You need a
pre-existing directory to mount a remote file system (or for that matter
a disk device). The directory gains the property of being a mount point
by the process of mounting, and loses it by the process of unmounting:

# mount earth:/home /foo
mount: /foo: No such file or directory
# mkdir /foo
# mount earth:/home /foo
# ls /foo
(... lots of user directories ...)
# umount /foo
# ls /foo
#

--Per

>> and you'd have to define all sorts of rules for this new
>> node (how it is encoded in XML, JSON, CBOR; how it is handled in
>> edit-config, how it is mapped to RESTCONF resources etc etc).
> 
> I'm don't see this, the rules would be the same as a container, as in
> "mount points in data trees are encoded identically as containers".
> 
>>
>> If you thought that the extension implicitly creates a node, adding an
>> explicit container won't do any harm; it will not change the schema
>> tree from what you thought it was.
> 
> Well we could make this work, but it feels like every model that uses
> schema has added complexity to its definition and use to perhaps avoid
> making some minor tooling changes.  Keep in mind that any use of the
> mount point extension will required changes in tooling.
> 
>>
>> But I think we should also restrict the mount-point extension so that
>> there cannot be more than one mount-point in a given container.
>>
> In this case, I'd go further and say that the only thing in the
> container (of the module schema) is the mount point and a mount point
> extension is only valid within a container. (Then the semantics are the
> same as we expected, just the syntax is different.)
> 
> Lou
> 
> 
>>
>> /martin
>>
>>
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> 

Re: [netmod] Potential additions to rfc6087bis: RegEx guidelines

[Per Hedeland]

On 2017-08-24 17:54, Ladislav Lhotka wrote:
> Per Hedeland <p...@tail-f.com> writes:
> 
>> I strongly agree with all of Juergen's statements, and disagree also
>> with the suggestion to include the parts of the text that he didn't
>> specifically disagree with. And I'd like to add that the "lack of XSD
>> support" argument is pretty weak - there exists at least one freely
>> available implementation in the form of libxml2, which is actually
>> present by default in basically all "normal" Linux installations.
>> It is portable C code, and the parts needed for regexp matching amount
>> to just above 100 kB of compiled code on an x86_64 CPU.
> 
> I wouldn't be so strict here. Libxml2 has its share of problems - for
> one, its "official" bindings do not support Python3, so e.g. in Yangson
> I had to use PyXB package instead and pyang gives up pattern validation
> in Python 3 entirely. 

I don't really see how claiming that the "lack of XSD support" argument
is weak amounts to being "strict" - and I suspect that the claim is
valid even considering the amount of pattern-validating server and
client implementations written in Python3. For a validation/translation
tool such as pyang, having a minuscule C program that is invoked for
validation would seem to be a reasonable implementation if no other
options exist, though admittedly it is an annoyance.

> That being said, there doesn't seem to be a clearly superior
> replacement, and some aspects of XSD regexes, such as support for
> Unicode and the absence of ^ and $ anchors, make a lot of sense in
> YANG. So I am also not in favour of the proposed change.

I did not see a proposed change to the standard YANG specification
regarding the regexp flavor, only a proposal that module authors SHOULD
show consideration for implementations that don't comply with the
standard.

--Per

> BTW, it is actually a shame that there is no standard regex language
> that could be easily used in all programming languages. Oh well ...
> 
> Lada
> 
>>
>> --Per
>>
>> On 2017-08-24 08:09, Juergen Schoenwaelder wrote:
>>> On Wed, Aug 23, 2017 at 09:20:36PM +, Xufeng Liu wrote:
>>>> Members of Routing Area Yang DT have had some discussions about the 
>>>> handling of various variants of regular expressions. The followings are 
>>>> the current state, and we are thinking that if this topic can be added to 
>>>> RFC6087bis:
>>>>
>>>> 1. Regular Expression Usage
>>>> YANG uses regular expressions to restrict string values. Such a 
>>>> restriction can be a part of a "pattern" statement or a string matching 
>>>> function. [RFC7950] specifies that YANG regular expressions will conform 
>>>> to Appendix F in [XSD-TYPES].
>>>> YANG models have been implemented in many different environments and the 
>>>> XSD variant of the regular expressions is not supported in many of these 
>>>> environments. There are currently more than a dozen popular regular 
>>>> expression variants implemented in various environments. While the usage 
>>>> of the XSD variant of regular expression described in [RFC7950] remains 
>>>> the preferred standard, a few conventions are prescribed to maximize the 
>>>> portability of YANG models between environments.
>>>>
>>>
>>> I strongly disagree with this statement. The standard format are XSD
>>> regular expressions. RFC 7950 section 9.4.5:
>>>
>>> The "pattern" statement, which is an optional substatement to the
>>> "type" statement, takes as an argument a regular expression string,
>>> as defined in [XSD-TYPES].
>>>
>>> There is no notion of a 'preferred' standard.
>>>
>>>> 1.1. Regular Expression Variant Choice Precedence
>>>> YANG model designers SHOULD use the most portable syntax whenever 
>>>> possible. Under the condition that XSD compliance is satisfied and there 
>>>> are multiple choices for a given expression, the following precedence 
>>>> SHOULD be used to choose a regular expressions variant:
>>>>
>>>> oPOSIX base
>>>>
>>>> oPOSIX extended
>>>>
>>>> oBSD
>>>>
>>>> oGNU Regular Expression Extensions
>>>>
>>>> oC++ Regular Expressions with std::regex
>>>>
>>>> oOthers
>>>
>>> Strongly disagree. You either write YANG or something different. There
>>> is no way to recog

Re: [netmod] Potential additions to rfc6087bis: RegEx guidelines

[Per Hedeland]

I strongly agree with all of Juergen's statements, and disagree also
with the suggestion to include the parts of the text that he didn't
specifically disagree with. And I'd like to add that the "lack of XSD
support" argument is pretty weak - there exists at least one freely
available implementation in the form of libxml2, which is actually
present by default in basically all "normal" Linux installations.
It is portable C code, and the parts needed for regexp matching amount
to just above 100 kB of compiled code on an x86_64 CPU.

--Per

On 2017-08-24 08:09, Juergen Schoenwaelder wrote:

On Wed, Aug 23, 2017 at 09:20:36PM +, Xufeng Liu wrote:

Members of Routing Area Yang DT have had some discussions about the handling of 
various variants of regular expressions. The followings are the current state, 
and we are thinking that if this topic can be added to RFC6087bis:

1. Regular Expression Usage
YANG uses regular expressions to restrict string values. Such a restriction can be a part 
of a "pattern" statement or a string matching function. [RFC7950] specifies 
that YANG regular expressions will conform to Appendix F in [XSD-TYPES].
YANG models have been implemented in many different environments and the XSD 
variant of the regular expressions is not supported in many of these 
environments. There are currently more than a dozen popular regular expression 
variants implemented in various environments. While the usage of the XSD 
variant of regular expression described in [RFC7950] remains the preferred 
standard, a few conventions are prescribed to maximize the portability of YANG 
models between environments.



I strongly disagree with this statement. The standard format are XSD
regular expressions. RFC 7950 section 9.4.5:

The "pattern" statement, which is an optional substatement to the
"type" statement, takes as an argument a regular expression string,
as defined in [XSD-TYPES].

There is no notion of a 'preferred' standard.


1.1. Regular Expression Variant Choice Precedence
YANG model designers SHOULD use the most portable syntax whenever possible. 
Under the condition that XSD compliance is satisfied and there are multiple 
choices for a given expression, the following precedence SHOULD be used to 
choose a regular expressions variant:

oPOSIX base

oPOSIX extended

oBSD

oGNU Regular Expression Extensions

oC++ Regular Expressions with std::regex

oOthers


Strongly disagree. You either write YANG or something different. There
is no way to recognize what kind of regular expressions have been used
by the model designer. The value of a standard is that everybody does
the same.


For example, either \d or [0-9] can be used with equivalent semantics and they 
are both compliant to [XSD-TYPES]. [0-9] is recommended because [0-9] is 
supported by POSIX base but \d is not.

1.2.  Convention Guidelines
1.2.1. Avoid Character Category Escapes
For example, in XSD regular expression, \d is a Character Category Escape 
denoting the range of digits, i.e.,  [0-9]. To maximize portability, the model 
designers SHOULD use [0-9] instead of \d.

1.2.2. Avoid Unicode Characters
Unicode characters are allowed in XSD regular expressions, but are not 
supported in the POSIX variant. If possible, the model designers SHOULD avoid 
using Unicode characters, such as: \p{L} and \p{N}.

1.3. Conversion Tools
Tools can automatically convert regular expressions from one variant to 
another. When a YANG model is implemented in an environment where XSD regular 
expressions are not supported, the recommended approach is to use a conversion 
tool. For example, if needed, anchor position characters, i.e., '^' and '$', 
can be added by a regular expression conversion tool.


If conversion tools exist that can convert, then by all means use XSD
in the YANG model and use tools to convert to whatever format your
implementation prefers to use.

/js



___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Pattern statements [was Re: Query about augmenting module from submodule in YANG 1.0]

[Per Hedeland]

On 2017-08-23 20:09, Vladimir Vassilev wrote:

On 08/23/2017 03:36 PM, Juergen Schoenwaelder wrote:


On Wed, Aug 23, 2017 at 02:23:12PM +0100, Robert Wilton wrote:

1) Email address.  I understand that the full regex to validate all email
addresses is very complex, but checking that it at least contains an @
symbol still has benefit.  It would seem that a short imperfect regex is
better than a complete perfect regex.

What is your definition of 'better'? A stricter pattern catches more
errors. An imperfect pattern is better than none.
In the case of e-mail address string pattern complying without exceptions to rfc5322#section-3.4 specification a ~500 characters of pattern expression is needed. There is value in defining data types 
that can be automatically verified by YANG. IMO in this case a strict pattern is justified.

2) A list of VLAN ranges, e.g. want to allow strings that look like this:
"1-10,20-400,600,2000-3000", but only with non overlapping values in
ascending order.  It is easy to write a regex to check that the structure is
right, but AFAIK it is hard (impossible?) to write a regex that ensures that
the ranges don't overlap and are specified in ascending order.

So what. Does this provide a helpful argument whether patterns should
be strict or imperfect?
IMO loading strings with semantics instead of using YANG is example of bad model design. There is no RFC (like in the e-mail example) that mandates use of string with complex format instead of YANG to 
model range configuration. Complex strings can and should be avoided in cases like this one.

So, I propose that we use regexes for checking that the string is
structurally correct, but don't use regexes to perform numerical range
checks of string encoded numbers, since it makes the regexes hard to
read/verify, and doesn't improve the readability of the YANG file either.

So here is the point I think:
c.
It is desirable that regexes are as strict as they can be.
However, if regexes become so complicated that they become a
verification and maintenance problem by themself, then less strict
regexes may be a better choice.
I agree. But it is the enthropy of having configuration that can not be strictly validated by model aware automation tools that has been the reason for introduction of leafref, must, when, range, 
pattern etc. So giving up the goal of handling validation in automated model driven way to the advantage of readability is a tough compromise.


If I may offer a more "philosophical" view: in my mind, a YANG module is
not an instruction for a server (or client) implementation as to what
validation to perform (and I say that with the bias of working for a
company that uses YANG modules precisely for that, and with the specific
components that translate them into such instructions) - it is a
specification of the data model. If the pattern statement allows values
that are actually invalid, the specification is incorrect.

I.e. I'm with your original comment - if you can't get it right, leave
it out. "Under-specification" will always exist, and is acceptable in my
opinion. Specification that gives the appearance of being complete
(admittedly this is also subjective), but actually isn't, is not (in my
opinion).

--Per

I agree with Rob that the pattern in draft-ietf-rtgwg-routing-types-09 is complicated to read. I have the feeling the design can be improved without compromising the strictnes of the data type. 
Redefinig the typedef as a union of 5 string based types with seperate strict patterns is one suggestion for moving logic from the string type to YANG.


Vladimir

/js



___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] [Editorial Errata Reported] RFC7317 (4795)

[Per Hedeland]

On 2016-09-05 12:34, Martin Bjorklund wrote:
> RFC Errata System  wrote:
>> The following errata report has been submitted for RFC7317,
>> "A YANG Data Model for System Management".
>>
>> --
>> You may review the report below and at:
>> http://www.rfc-editor.org/errata_search.php?rfc=7317=4795
>>
>> --
>> Type: Editorial
>> Reported by: Kaja Mohideen 
>>
>> Section: 5
>>
>> Original Text
>> -
>> typedef crypt-hash {
>>type string {
>>  pattern
>>'RFCORIGINAL_TEXT$.*'
>>  + '|$[a-zA-Z0-9./]{1,8}$[a-zA-Z0-9./]{22}'
>>  + '|$(rounds=\d+$)?[a-zA-Z0-9./]{1,16}$[a-zA-Z0-9./]{43}'
>>  + '|$(rounds=\d+$)?[a-zA-Z0-9./]{1,16}$[a-zA-Z0-9./]{86}';
>>}
>>
>> Corrected Text
>> --
>> typedef crypt-hash {
>>   type string {
>> pattern
>> '$0$.*'
>>   + '|$1$[a-zA-Z0-9./]{1,8}$[a-zA-Z0-9./]{22}'
>>   + '|$5$(rounds=\d+$)?[a-zA-Z0-9./]{1,16}$[a-zA-Z0-9./]{43}'
>>   + '|$6$(rounds=\d+$)?[a-zA-Z0-9./]{1,16}$[a-zA-Z0-9./]{86}';
>>   }
>>   
>>
>> Notes
>> -
>> Character $ has special meaning in regular expression.
> 
> No, "$" is not special in the regular expression dialect used in YANG
> (XML Schema).

+1. And in fact the suggested change (lost in the above text, but
present in the html version), to use '\$' instead of '$', results in
invalid expressions according the XML Schema spec.

--Per

> /martin
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] RFC 7950 on The YANG 1.1 Data Modeling Language

[Per Hedeland]

On 2016-09-02 00:14, Phil Shafer wrote:
> Martin Bjorklund writes:
>> See Section 1.1 (Summary of Changes from RFC 6020)
> 
> I may be missing something but it says:
> 
> o Allow "choice" as a shorthand "case" statement (see
>   Section 7.9.2).
> 
> which is definitely in 6020.

No, it isn't:

7.9.1.  The choice's Substatements

 +--+-+-+
 | substatement | section | cardinality |
 +--+-+-+
 | anyxml   | 7.10| 0..n|
 | case | 7.9.2   | 0..n|
 | config   | 7.19.1  | 0..1|
 | container| 7.5 | 0..n|
 | default  | 7.9.3   | 0..1|
 | description  | 7.19.3  | 0..1|
 | if-feature   | 7.18.2  | 0..n|
 | leaf | 7.6 | 0..n|
 | leaf-list| 7.7 | 0..n|
 | list | 7.8 | 0..n|
 | mandatory| 7.9.4   | 0..1|
 | reference| 7.19.4  | 0..1|
 | status   | 7.19.2  | 0..1|
 | when | 7.19.5  | 0..1|
 +--+-+-+

7.9.2.  The choice's case Statement
   ...
   As a shorthand, the "case" statement can be omitted if the branch
   contains a single "anyxml", "container", "leaf", "list", or
   "leaf-list" statement.

--Per

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] leafref value space and constraint

[Per Hedeland]

On 2016-06-08 09:48, Martin Bjorklund wrote:
> Andy Bierman  wrote:
>> On Tue, Jun 7, 2016 at 9:38 AM, Juergen Schoenwaelder <
>> j.schoenwael...@jacobs-university.de> wrote:
>>
>>> On Tue, Jun 07, 2016 at 09:08:56AM -0700, Andy Bierman wrote:
 On Tue, Jun 7, 2016 at 8:52 AM, Juergen Schoenwaelder <
 j.schoenwael...@jacobs-university.de> wrote:

> On Tue, Jun 07, 2016 at 11:26:03AM -0400, Dale R. Worley wrote:
>> Ladislav Lhotka  writes:
>>> "Dale R. Worley"  writes:
 A difficulty I have with the current wording is that it doesn't
>>> point
 out the crucial fact about leafref that the XPath expression can
>>> only
 select elements that are instantiations of one particular data
>>> node.
> I
 don't know XPath, but it seems that that is not a general
>>> property of
 XPath expressions, you seem to be able to write XPath expressions
>>> that
 select heterogenous groups of elements.  So it's worth pointing
>>> out
> that
 the allowed XPath expressions can't do that, and that is because
>>> of
> the
 restriction that the expression must match path-arg.
>>>
>>> Right, this is the slightly hand-waving part that I also objected
>>> to.
> An
>>> XPath expression in a leafref's "path" statement indeed selects a
>>> node
>>> set from an instance data tree. The node seet can be empty, but if
>>> it
> is
>>> non-empty, all its members necessarily have the same type, which is
>>> defined in a certain "leaf" schema node.
>>>
>>> The relationship is relatively straightforward but difficult to
>>> explain
>>> concisely. One basically has to follow the steps in the XPath
>>> expression, ignore all path-predicates, and skip all schema nodes
>>> that
>>> aren't data nodes (i.e., "choice" and "case" nodes).
>>
>> Yes, it's difficult to explain, though once one gets the idea, it's
>> straightforward enough.  The problem I have is that it's not pointed
>>> out
>> explicitly anywhere.  (E.g., Juergen suggests section 9.9.2, but I
>>> don't
>> see it there.)
>>
>> The crucial points seem to be:
>>
>> - The XPath expression is limited by the syntax "path-arg" and the
>>> rules
>>   in 9.9.2.
>>
>> - Because of those restrictions, there exists one data node in the
>>   schema such that:  evalutating the expression for any leaf or
>>   leaf-list node in any data tree returns a set of nodes, all of
>>> which
>>   are instances of that one schema node.
>>
>> - The type of that schema node is the base type of the leafref.
>>
>> - Once you learn this, it's easy to see, for any particular
>>   leaf/leaf-list node and path expression in a module, which schema
>>> node
>>   is the one.  But it's rather hard to describe that process.
>>
>> Actually, there's an ugly question:  If the path expression
>>> references
>> an element name that doesn't exist in the module.  Perhaps there are
>> rules in XPath that prevent it, but it seems to me that you could
>>> write
>>
>>  leaf mgmt-interface {
>>mandatory false;
>>type leafref {
>>  path "../interface/name";
>>  require-instance true;
>>}
>>  }
>>
>> when the current module doesn't have a "name" child defined for
>> "interface".  As long as a data tree didn't contain a mgmt-interface
>> elememt, the constraint would not be violated.
>>
>> But a later revision of the module, the "name" child could be added,
>> allowing data trees to contain mgmt-interface elements, because data
>> trees could now have "name" elements.
>>
>> The point being that when you're figuring out which schema node is
>>> the
>> base type for the leafref, that schema node has to exist so the base
>> type can be extracted.  But there's no direct statement of that as a
>> requirement for path validity.
>>
>
> As WG chair, I am getting a bit nervous. We have to wrap things up and
> we need deliver the specification - it is past WG last call, it is
> past IETF last call, it is past IESG approval (kind of). We can likely
> endlessly continue to search for possible ways to misunderstand the
> specification but lets remember the aphorism 'perfect is the enemy of
> good'.
>
> I leave it to Martin's discretion to decide whether he wants to add
> 'The referred leaf or leaf-list node in the schema tree MUST exist.'
> to the new text but I think the time has come to stop searching for
> new possible ways to misunderstand the specification.
>
>

 Doesn't the text above exclude a default leaf or leaf-list from the
 value space?  That would be incorrect.

>>>
>>> It says 'in the schema tree' so I think there is no problem. We were

Re: [netmod] restricted enumeration

[Per Hedeland]

On 2016-04-29 17:07, Ladislav Lhotka wrote:
> 
>> On 29 Apr 2016, at 16:32, Per Hedeland <p...@tail-f.com> wrote:
>>
>> On 2016-04-29 16:15, Ladislav Lhotka wrote:
>>>
>>>> On 29 Apr 2016, at 15:51, Per Hedeland <p...@tail-f.com> wrote:
>>>>
>>>> On 2016-04-29 15:28, Ladislav Lhotka wrote:
>>>>>
>>>>>> On 29 Apr 2016, at 15:07, Juergen Schoenwaelder 
>>>>>> <j.schoenwael...@jacobs-university.de> wrote:
>>>>>>
>>>>>> On Fri, Apr 29, 2016 at 02:57:36PM +0200, Ladislav Lhotka wrote:
>>>>>>>
>>>>>>> Or are you saying that "type foo {}" is not the same as "type foo;"?
>>>>>>>
>>>>>>
>>>>>> Yes, "type foo {}" has a restriction while "type foo;" does not have a
>>>>>> restriction. OK, I think I see your point now that we have a case
>>>>>> where there is a subtle difference between "{}" and ";" and so you
>>>>>> suggest to interpret "type foo {}" as all values of foo?
>>>>>
>>>>> Now it becomes really interesting! :-) I wonder if there is any YANG 
>>>>> parser out there that is able to distinguish those two syntactic forms. I 
>>>>> think they must be considered identical by all means.
>>>>
>>>> +1. Though if I read the ABNF right, "type foo {}" is actually illegal
>>>> if foo is an enum type.:-)
>>>
>>> I don't think so:
>>>
>>>   type-stmt   = type-keyword sep identifier-ref-arg-str optsep
>>> (";" /
>>>  "{" stmtsep
>>>  [type-body-stmts]
>>>  "}") stmtsep
>>>
>>> Everything inside the braces is optional.
>>
>> Yes, fixed in 1.1 - but 6020 (which I "happened" to look at as I was
>> flipping between the two) has:
>>
>>   type-stmt   = type-keyword sep identifier-ref-arg-str optsep
>> (";" /
>>  "{" stmtsep
>>  type-body-stmts
>>  "}")
>>
>>>>> My point was that the text about restrictions of the "enumeration" type 
>>>>> is unclear, and IMO the more logical answer to my original question is 
>>>>> that the "bar" set is empty. This is most likely not the 1.0 semantics 
>>>>> though.
>>>>
>>>> No, it isn't - and I think the answer to your *original* question is
>>>> quite clearly "bar is the same set as foo" in both 1 and 1.1, since 1.1
>>>> says:
>>>>
>>>>  An enumeration can be restricted with the "enum" (Section 9.6.4)
>>>>  statement.
>>>>
>>>> If there is no "enum" statement, there is no restriction, and thus foo
>>>> and bar are identical. The "if-feature removes all the enum
>>>> restrictions" case is perhaps ambiguous with an "extremely literal"
>>>> interpretation of "if-feature", but to me (just having implemented
>>>> if-feature for enums/bits in our compiler) it is obvious that this case
>>>> too is a restriction and not an identity - the if-feature only modifies
>>>> the specifics of the restriction.
>>>
>>> Yes, this makes sense, too, but needs to be explained.
>>
>> I think some text would be appreciated if you think it is needed.
> 
> OLD
>When an existing enumeration type is restricted, the set of assigned
>names in the new type MUST be a subset of the base type's set of
>assigned names.  The value of such an assigned name MUST NOT be
>changed.
> 
> NEW
>When an existing enumeration type is restricted by means of one or more
>"enum" statements (even if any or all of them are disabled through an
>"if-feature" statement), the set of assigned names in the new type MUST
>be a subset of the base type's set of assigned names.  The value of such
>an assigned name MUST NOT be changed.
> 
>If a new type is derived from an existing enumeration type and no "enum"
>restrictions are specified, then the sets of permitted values are the same
>for both types.
> 
> And the same for bits type, mutatis mutandis.

Agree with the first paragraph, but I do think the second is superfluous
- it just says "if there is no restriction statement, the type isn't
restricted". This is true for all types.

--Per

> Lada 
> 
>>
>>> In a way, solution Y10-02 would have been more straightforward.
>>
>> Please don't do that.
>>
>> --Per
>>
>>> Lada
>>>
>>>>
>>>> But adding some text that clarifies this can't hurt I guess (just like
>>>> the text that points out that the outcome of if-feature evaluation does
>>>> not affect the value assignment).
>>>>
>>>> --Per
>>>
>>> --
>>> Ladislav Lhotka, CZ.NIC Labs
>>> PGP Key ID: E74E8C0C
> 
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
> 
> 
> 
> 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] restricted enumeration

[Per Hedeland]

On 2016-04-29 16:15, Ladislav Lhotka wrote:
> 
>> On 29 Apr 2016, at 15:51, Per Hedeland <p...@tail-f.com> wrote:
>>
>> On 2016-04-29 15:28, Ladislav Lhotka wrote:
>>>
>>>> On 29 Apr 2016, at 15:07, Juergen Schoenwaelder 
>>>> <j.schoenwael...@jacobs-university.de> wrote:
>>>>
>>>> On Fri, Apr 29, 2016 at 02:57:36PM +0200, Ladislav Lhotka wrote:
>>>>>
>>>>> Or are you saying that "type foo {}" is not the same as "type foo;"?
>>>>>
>>>>
>>>> Yes, "type foo {}" has a restriction while "type foo;" does not have a
>>>> restriction. OK, I think I see your point now that we have a case
>>>> where there is a subtle difference between "{}" and ";" and so you
>>>> suggest to interpret "type foo {}" as all values of foo?
>>>
>>> Now it becomes really interesting! :-) I wonder if there is any YANG parser 
>>> out there that is able to distinguish those two syntactic forms. I think 
>>> they must be considered identical by all means.
>>
>> +1. Though if I read the ABNF right, "type foo {}" is actually illegal
>> if foo is an enum type.:-)
> 
> I don't think so:
> 
>type-stmt   = type-keyword sep identifier-ref-arg-str optsep
>  (";" /
>   "{" stmtsep
>   [type-body-stmts]
>   "}") stmtsep
> 
> Everything inside the braces is optional.

Yes, fixed in 1.1 - but 6020 (which I "happened" to look at as I was
flipping between the two) has:

   type-stmt   = type-keyword sep identifier-ref-arg-str optsep
 (";" /
  "{" stmtsep
  type-body-stmts
  "}")

>>> My point was that the text about restrictions of the "enumeration" type is 
>>> unclear, and IMO the more logical answer to my original question is that 
>>> the "bar" set is empty. This is most likely not the 1.0 semantics though.
>>
>> No, it isn't - and I think the answer to your *original* question is
>> quite clearly "bar is the same set as foo" in both 1 and 1.1, since 1.1
>> says:
>>
>>   An enumeration can be restricted with the "enum" (Section 9.6.4)
>>   statement.
>>
>> If there is no "enum" statement, there is no restriction, and thus foo
>> and bar are identical. The "if-feature removes all the enum
>> restrictions" case is perhaps ambiguous with an "extremely literal"
>> interpretation of "if-feature", but to me (just having implemented
>> if-feature for enums/bits in our compiler) it is obvious that this case
>> too is a restriction and not an identity - the if-feature only modifies
>> the specifics of the restriction.
> 
> Yes, this makes sense, too, but needs to be explained.

I think some text would be appreciated if you think it is needed.

> In a way, solution Y10-02 would have been more straightforward.

Please don't do that.

--Per

> Lada
> 
>>
>> But adding some text that clarifies this can't hurt I guess (just like
>> the text that points out that the outcome of if-feature evaluation does
>> not affect the value assignment).
>>
>> --Per
> 
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
> 
> 
> 
> 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] actions and keyless lists

[Per Hedeland]

On 2016-04-05 22:33, Ladislav Lhotka wrote:
> 
>> On 05 Apr 2016, at 16:32, Martin Bjorklund  wrote:
>>
>> Ladislav Lhotka  wrote:
>>>
 On 05 Apr 2016, at 11:09, Martin Bjorklund  wrote:

 Andy Bierman  wrote:
> On Mon, Apr 4, 2016 at 1:08 PM, Ladislav Lhotka  wrote:
>
>>
>>> On 04 Apr 2016, at 16:15, Andy Bierman  wrote:
>>>
>>>
>>> On Mon, Apr 4, 2016 at 12:01 PM, Ladislav Lhotka  wrote:
>>>
 On 04 Apr 2016, at 15:57, Andy Bierman  wrote:

 Hi,

 I do not see any reason to prohibit this use of action-stmt
 or notification-stmt.  If the list has no keys then there is
 no need to distinguish instances because the data model defines
 no such semantics.
>>>
>>> If such a keyless list has multiple entries, how can an action request
>> specify which of the list entries it is tied to?
>>>
>>> it must be be relevant to distinguish instances or else the designer
>>> would have defined a key.
>>>
>>>

 What breaks if this is allowed?
>>>
>>> The behaviour is undefined.
>>>
>>>
>>>
>>> IMO lists without keys are a really bad idea.
>>> But the semantics are fully defined according to YANG.
>>> If the list has no keys then there is no instance information
>>> relevant to the data model.  The action or notification is passed
>>> all the keys (happens to be zero in this case).
>>
>> To my understanding, each action request has to specify the unique
>> instance that's the "receiver" of the action. If this cannot be done, it 
>> is
>> IMO a problem in the spec.
>>
>> An alternative implementation of actions would be to use instance
>> identifiers instead of an explicit data hierarchy, and in this case it
>> would be possible to use indices for identifying entries. But the 
>> hierarchy
>> provides no such option.
>>
>> It's not a big issue, but there is already a couple of rules regarding
>> where actions can and cannot be defined, so this would be another one
>> intended to avoid potential ambiguity.
>>
>>
> I agree actions were not considered when keyless lists were allowed in 
> YANG.
> There was an assumption that this data is always read-only that is no
> longer true in YANG 1.1.
>
> I certainly prefer adding a restriction than redoing the way actions work.
> Using /foo[5] does not work because entry "5" might move or get deleted,
> so the numbering is not stable.

 How about:

 An action MUST NOT have any ancestor node that is a list node without
 a "key" statement.
>>>
>>>
>>> Or rather:
>>>
>>> An action MUST NOT be defined for a node that is a list without a
>>> "key" statement, or has a list node without a "key" statement as its
>>> ancestor.
>>
>> I don't see the difference.  Even in:
>>
>>   list foo {
>> action bar { ... }
>>   }
>>
>> "foo" is an ancestor to "bar".
> 
> Provided "action" is a schema node which it doesn't seem to be:
> 
> action: An operation defined for a node in the data tree.

IMO it is absolutely clear that it is a schema node - later in the
Terminology section:

   o  schema node: A node in the schema tree.  One of action, container,
  leaf, leaf-list, list, choice, case, rpc, input, output,
  notification, anydata, and anyxml.

And "7.15 The action Statement":

   The "action" statement defines an action node in the schema tree.

I can see how the "action" entry in the Terminology section - which
apparently talks about the action "concept" rather than the statement or
the node - can be confusing, though. And looking for symmetry with "rpc"
it gets perhaps even more confusing - there is no literal "rpc" entry,
but:

   o  RPC: A Remote Procedure Call.

Yeah, but...:-) Anyway, given

4.2.9.  Operation Definitions

   YANG allows the definition of operations.  The operations' name,
   input parameters, and output parameters are modeled using YANG data
   definition statements.  Operations on the top-level in a module are
   defined with the "rpc" statement.  Operations can also be tied to a
   data node.  Such operations are defined with the "action" statement.

[snip example]

   The "rpc" statement is covered in Section 7.14, and the "action"
   statement in Section 7.15.

- it seems to me that the full picture is clear enough.

--Per

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] VRFY :45: better conformance mechanism

[Per Hedeland]

On 2015-05-21 19:46, Andy Bierman wrote:
 On Thu, May 21, 2015 at 10:38 AM, Per Hedeland p...@tail-f.com wrote:
 On 2015-05-21 19:14, Andy Bierman wrote:
 On Thu, May 21, 2015 at 7:37 AM, Ladislav Lhotka lho...@nic.cz wrote:

 RFC 6020 also states that must and when expessions are XPath 1.0, and we 
 are moving away from it. This is IMO a much bigger change than Y45-04.


 Show me the MUST NOT that is getting reversed and I will agree with you.
 I am not objecting to Y45-04.  I am objecting to removing a MUST NOT
 from the standard.  Discussion of relative implementation complexity
 of other YANG 1.1 changes is irrelevant.

 I don't have one for that, but these are:

A member type can be of any built-in or derived type, except it MUST
NOT be one of the built-in types empty or leafref.

 I believe they're described as CLR in the issues doc...

 
 I don't know about leafref, but type empty and a zero-length string
 are identical on the wire, and that is allowed.  This is a trivial
 change to YANG syntax. I don't think Y45 has such a trivial impact
 on YANG syntax or usage.

Probably not (though the needed server implementation change is not
likely to be as trivial as the syntax change), but you said that you
weren't objecting to Y45, but to removing a MUST NOT...

--Per

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod