Re: [netmod] Ben Campbell's No Objection on draft-ietf-netmod-schema-mount-11: (with COMMENT)

2018-10-12 Thread Ben Campbell


> On Oct 11, 2018, at 3:23 AM, Martin Bjorklund  wrote:
> 
> Hi,
> 
> Ben Campbell mailto:b...@nostrum.com>> wrote:
>> Ben Campbell has entered the following ballot position for
>> draft-ietf-netmod-schema-mount-11: No Objection
>> 
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>> 
>> 
>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>> for more information about IESG DISCUSS and COMMENT positions.
>> 
>> 
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-netmod-schema-mount/
>> 
>> 
>> 
>> --
>> COMMENT:
>> --
>> 
>> Substantive:
>> 
>> §3.3, 4th paragraph: The MUST NOT seems like a statement of fact -- if no
>> schema is mounted, it doesn't seem possible for it to include anything.
> 
> Right, so this MUST NOT is directed to an implementor.  If you think
> it is stating the obvious, I'd be happy to modify this to maybe "does
> not”.

I guess it comes down to whether it is reasonably possible for an implementor 
to get it wrong :-)

> 
> 

>> §5, last paragraph: Why is the SHOULD NOT not a MUST NOT? Would it ever make
>> sense to violate this?
> 
> Probably not, but it could depend on how the mount point is supposed
> to be used.  Maybe it is used in such a way that mounted rpcs are not
> applicable.
> 

Okay. Some guidance to that effect in the document would be helpful.

>> §9: The model includes RFC 2119 boilerplate, but the document itself uses the
>> newer RFC 8174 boilerplate. Is it normal to include the normative keyword
>> boilerplate in the model?
> 
> No, but in some cases models use 2119 language w/o the boilerplate and
> since models have a life on their own outside the RFC, we thought that
> it would be a good idea to clarify the intention by including the
> boilerplate.

Okay.

> 
>> If so, it should probably match that of the
>> containing document.
> 
> Yes, fixed.

Thanks!

> 
>> Editorial:
>> 
>> §1, list item 2: "... and is stable as YANG library information of the 
>> server."
>> Assuming you mean specific YANG library information rather than the general
>> concept, there is a missing article before "YANG". (This pattern repeats a 
>> few
>> time throughout the document.)
> 
> Yes, fixed.
> 
> 
> /martin



signature.asc
Description: Message signed with OpenPGP
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod


Re: [netmod] WHEN statement within mandatory objects doesn't ensure presence of the mandatory object

2018-10-12 Thread Michael Rehder
I provided an example.
Requiring something to be present when a condition is to me a useful capability.
How else would you enforce in an optimal way that something is present under 
only certain conditions (define it on the controlled section, not use a zillion 
if-feature)?

Thanks
Mike

From: Robert Wilton [mailto:rwil...@cisco.com]
Sent: Friday, October 12, 2018 12:30 PM
To: Michael Rehder 
Cc: Andy Bierman ; Walker, Jason 
(jason_walk...@comcast.com) ; netmod@ietf.org
Subject: Re: [netmod] WHEN statement within mandatory objects doesn't ensure 
presence of the mandatory object


On 12/10/2018 17:08, Michael Rehder wrote:
The mandatory statement in that case is ignored (I’ve pointed out the RNG and 
Schematron lack of enforcement).
OK, I'm not familiar with RNG and Schematron.


WHEN trumps the mandatory status (via explicit mandatory or implicit mandatory 
via min-elements 1)
So I think that you are asking for mandatory to trump a when condition.  Can 
you provide a concrete example where this is required, or even useful?

A solution here, that doesn't require any changes in the YANG language, would 
be to just move the when condition, down to each of the child nodes that are 
not marked as mandatory.

But, sorry, at the moment I'm still at a loss to see how where this would 
actually be useful.

Thanks,
Rob



Thanks
Mike

From: Robert Wilton [mailto:rwil...@cisco.com]
Sent: Friday, October 12, 2018 12:06 PM
To: Michael Rehder 
Cc: Andy Bierman ; Walker, Jason 
(jason_walk...@comcast.com) 
; 
netmod@ietf.org
Subject: Re: [netmod] WHEN statement within mandatory objects doesn't ensure 
presence of the mandatory object


Hi Mike,

On 11/10/2018 19:05, Andy Bierman wrote:


On Thu, Oct 11, 2018 at 11:00 AM, Michael Rehder 
mailto:michael.reh...@amdocs.com>> wrote:
I think the wording is relevant - something can be conditional but still 
required.
Yes, but I think that this is already expressed by a node that has both a when 
condition and mandatory statement.




container a {

  container x {

when "some condition";

leaf foo {

  mandatory true;

}

leaf bar {

  ...

}

  }

  container y {

leaf baz {

  mandatory true;

}

leaf tee {

  ...

}

  }

}



a/x/foo is conditional (due to when) but required (if the when condition is 
met).

a/x/bar is conditional (due to when) but optional (if the when condition is 
met).

a/y/baz is unconditional but required.

a/y/tee is unconditional but optional.




It should be clarified that elements become implicitly “mandatory false” when a 
“when” statement is used.
But they don't.




I would like to see an enhancement to YANG to control this behavior, to allow 
the mandatory status to be enforced.
That is, support also “conditionally required” instead of only the current 
“conditionally optional”.
I'm trying to understand what this would even mean.

Taking your original example, but with "enforce-mandatory-status":

 leaf AssignmentMechanism {

type enumeration {

  enum "DHCP";

  enum "Static";

}

mandatory true;

description "The address assignment mechanism.";

  }

  list IPAddresses {

when "../AssignmentMechanism = 'Static'" {

  enforce-mandatory-status;

}  key Address;

min-elements 1;



leaf Address {

  type capit:IPv4Address;

  description "An ipv4 address.";

}

   }

So this means that list IPaddresses must have at least one element regardless 
of whether the when condition holds.  I.e. no matter whether the assignment is 
DHCP or Static there must always be at least one 1 address configured.  But I 
don't understand what this actually means - it seems like a contradiction.  
What am I missing?  Please can you give a concrete example (in YANG) of what 
behaviour you are looking for.

Thanks,
Rob

“Amdocs’ email platform is based on a third-party, worldwide, cloud-based 
system. Any emails sent to Amdocs will be processed and stored using such 
system and are accessible by third party providers of such system on a limited 
basis. Your sending of emails to Amdocs evidences your consent to the use of 
such system and such processing, storing and access”.

“Amdocs’ email platform is based on a third-party, worldwide, cloud-based 
system. Any emails sent to Amdocs will be processed and stored using such 
system and are accessible by third party providers of such system on a limited 
basis. Your sending of emails to Amdocs evidences your consent to the use of 
such system and such processing, storing and access”.
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod


Re: [netmod] xpath expressions in JSON

2018-10-12 Thread Reshad Rahman (rrahman)
On 2018-10-12, 4:37 AM, "netmod on behalf of Martin Bjorklund" 
 wrote:

Robert Wilton  wrote:
> 
> 
> On 11/10/2018 17:11, Martin Bjorklund wrote:
> > Robert Wilton  wrote:
> >>
> >> On 11/10/2018 11:50, Martin Bjorklund wrote:
> >>> Robert Wilton  wrote:
>  On 11/10/2018 11:21, Martin Bjorklund wrote:
> > Andy Bierman  wrote:
> >> On Wed, Oct 10, 2018 at 11:39 PM, Martin Bjorklund 

> >> wrote:
> >>
> >>> Andy Bierman  wrote:
>  On Wed, Oct 10, 2018 at 6:59 PM, Reshad Rahman (rrahman) <
> >>> rrah...@cisco.com>
>  wrote:
> 
> > On 2018-10-10, 9:59 AM, "netmod on behalf of Martin Bjorklund" <
> > netmod-boun...@ietf.org on behalf of m...@tail-f.com> wrote:
> >
> >Ladislav Lhotka  wrote:
> >> Martin Bjorklund  writes:
> >>
> >> > Hi,
> >> >
> >> > While reviewing restconf-notif, I saw this example:
> >> >
> >> >{
> >> >   "ietf-subscribed-notifications:input": {
> >> >  "stream": "NETCONF",
> >> >  "stream-xpath-filter": "/ds:foo/",
> >> >  "dscp": "10"
> >> >   }
> >> >}
> >> >
> >> > Note the "stream-xpath-filter".  It has a prefix in 
the
> >> > XPath
> > string.
> >> > How are prefixes declared when JSON is used?
> >> >
> >> > The leaf "stream-xpath-filter" says:
> >> >
> >> >   o The set of namespace declarations are
> >> >   those
> >> >   in
> > scope on
> >> >  the 'stream-xpath-filter' leaf 
element.
> >> >
> >> > (I think I provided that text...)
> >> >
> >> > This assumes that the encoding is XML, or at leas 
that the
> >>> encoding
> >> > can somehow transfer namespace declarations.
> >>
> >> It can't. There are two options:
> >>
> >> 1. have different representations of this value in XML 
and
> >> JSON,
> >>analogically to instance indentifiers (sec. 6.11 in 
RFC
> >>7951).
> >>
> >> 2. use a module name rather than a prefix in XML, too.
> >>
> >> I would suggest #2.
> >  But that means making non-backwards compatible change to 
the XML
> > representation?
> >
>  Not really. It means NETMOD WG would be creating its own special
>  variant
> >>> of
>  XPath.
> >>> Not at all.  What I propose is perfectly fine, legal XPath 1.0.
> >>>
> >>> XPath 1.0 says that an XPath expression is evaluated in a context.
> >>> One item in the context is a set of mappings from  to 
,
> >>> where  is used to lookup prefixes used in the XPath
> >>> expression, e.g. in "/foo:interfaces" "foo" is the prefix.
> >>>
> >>> It is perfectly fine to say that the prefix mapping set is this:
> >>>
> >>>   "ietf-interfaces" ->
> >>>   "urn:ietf:params:xml:ns:yang:ietf-interfaces"
> >>>   "ietf-ip" -> "urn:ietf:params:xml:ns:yang:ietf-ip"
> >>>
> >>> and use that to evaluate the expression
> >>>
> >>>  
/ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip/ipv4
> >>>
> >>>
> >>>
> >> The XPath expression is normally parsed within an XML instance
> >> document.
> >> There are "xmlns" attributes present that map the prefix to a
> >> namespace URI.
> >> These mappings will not be present in the JSON at all.
> >>
> >> A custom XPath implementation is required to magically identify the
> >> prefix
> >> as a module name and magically find the namespace URI for the 
module
> >> name.
> > I disagree.  You need an XPath implementation + custom code to set 
up
> > the environment.
>  This is OK, but can we just use the JSON encoding instance identifier
>  format exactly?  I.e .RFC 7951 section 6.11.
> 
>  So "/ietf-interfaces:interfaces/interface/ietf-ip:ipv4/enabled"
> 
>  can trivially be expanded to:
> 
>  

Re: [netmod] WHEN statement within mandatory objects doesn't ensure presence of the mandatory object

2018-10-12 Thread Robert Wilton


On 12/10/2018 17:08, Michael Rehder wrote:


The mandatory statement in that case is ignored (I’ve pointed out the 
RNG and Schematron lack of enforcement).



OK, I'm not familiar with RNG and Schematron.

WHEN trumps the mandatory status (via explicit mandatory or implicit 
mandatory via min-elements 1)


So I think that you are asking for mandatory to trump a when condition.  
Can you provide a concrete example where this is required, or even useful?


A solution here, that doesn't require any changes in the YANG language, 
would be to just move the when condition, down to each of the child 
nodes that are not marked as mandatory.


But, sorry, at the moment I'm still at a loss to see how where this 
would actually be useful.


Thanks,
Rob


Thanks

Mike

*From:*Robert Wilton [mailto:rwil...@cisco.com]
*Sent:* Friday, October 12, 2018 12:06 PM
*To:* Michael Rehder 
*Cc:* Andy Bierman ; Walker, Jason 
(jason_walk...@comcast.com) ; netmod@ietf.org
*Subject:* Re: [netmod] WHEN statement within mandatory objects 
doesn't ensure presence of the mandatory object


Hi Mike,

On 11/10/2018 19:05, Andy Bierman wrote:

On Thu, Oct 11, 2018 at 11:00 AM, Michael Rehder
mailto:michael.reh...@amdocs.com>> wrote:

I think the wording is relevant - something can be conditional
but still required.

Yes, but I think that this is already expressed by a node that has 
both a when condition and mandatory statement.



container a {
   container x {
     when "some condition";
     leaf foo {
   mandatory true;
     }
     leaf bar {
   ...
     }
   }
   container y {
     leaf baz {
   mandatory true;
     }
     leaf tee {
   ...
     }
   }
}
a/x/foo is conditional (due to when) but required (if the when condition is 
met).
a/x/bar is conditional (due to when) but optional (if the when condition is 
met).
a/y/baz is unconditional but required.
a/y/tee is unconditional but optional.

It should be clarified that elements become implicitly
“mandatory false” when a “when” statement is used.

But they don't.


I would like to see an enhancement to YANG to control this
behavior, to allow the mandatory status to be enforced.

That is, support also “conditionally required” instead of only
the current “conditionally optional”.

I'm trying to understand what this would even mean.

Taking your original example, but with "enforce-mandatory-status":

  leaf AssignmentMechanism {
     type enumeration {
   enum "DHCP";
   enum "Static";
     }
     mandatory true;
     description "The address assignment mechanism.";
   }
   list IPAddresses {
     when "../AssignmentMechanism = 'Static'" {
   enforce-mandatory-status;
     }  key Address;
     min-elements 1;
 
 leaf Address {

   type capit:IPv4Address;
   description "An ipv4 address.";
     }
    }


So this means that list IPaddresses must have at least one element 
regardless of whether the when condition holds. I.e. no matter whether 
the assignment is DHCP or Static there must always be at least one 1 
address configured.  But I don't understand what this actually means - 
it seems like a contradiction.  What am I missing?  Please can you 
give a concrete example (in YANG) of what behaviour you are looking for.


Thanks,
Rob

/“Amdocs’ email platform is based on a third-party, worldwide, 
cloud-based system. Any emails sent to Amdocs will be processed and 
stored using such system and are accessible by third party providers 
of such system on a limited basis. Your sending of emails to Amdocs 
evidences your consent to the use of such system and such processing, 
storing and access”./




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


Re: [netmod] WHEN statement within mandatory objects doesn't ensure presence of the mandatory object

2018-10-12 Thread Andy Bierman
On Fri, Oct 12, 2018 at 9:08 AM, Michael Rehder 
wrote:

> The mandatory statement in that case is ignored (I’ve pointed out the RNG
> and Schematron lack of enforcement).
>
> WHEN trumps the mandatory status (via explicit mandatory or implicit
> mandatory via min-elements 1)
>
>
>


Implementation of the when-stmt is complicated, especially if the server is
expected to be fast.
RFC 7950 has many more details than RFC 6020 about implementation of this
statement,
but it is still difficult.

The schema dictates what can be in the instance documents. The when-stmt
modifies the
schema based on what is in the instance document.  Even the default value
goes away if the
when-stmt is false (as it should). I would be very surprised if static
document validation tools could handle that.

YANG validation is already heavyweight and complex to implement.
Allowing designers to pick and choose when which constraints are active,
would make much more complex.



> Thanks
>
> Mike
>

Andy


>
>
> *From:* Robert Wilton [mailto:rwil...@cisco.com]
> *Sent:* Friday, October 12, 2018 12:06 PM
> *To:* Michael Rehder 
> *Cc:* Andy Bierman ; Walker, Jason (
> jason_walk...@comcast.com) ; netmod@ietf.org
> *Subject:* Re: [netmod] WHEN statement within mandatory objects doesn't
> ensure presence of the mandatory object
>
>
>
> Hi Mike,
>
>
>
> On 11/10/2018 19:05, Andy Bierman wrote:
>
>
>
>
>
> On Thu, Oct 11, 2018 at 11:00 AM, Michael Rehder <
> michael.reh...@amdocs.com> wrote:
>
> I think the wording is relevant - something can be conditional but still
> required.
>
> Yes, but I think that this is already expressed by a node that has both a
> when condition and mandatory statement.
>
>
> container a {
>
>   container x {
>
> when "some condition";
>
> leaf foo {
>
>   mandatory true;
>
> }
>
> leaf bar {
>
>   ...
>
> }
>
>   }
>
>   container y {
>
> leaf baz {
>
>   mandatory true;
>
> }
>
> leaf tee {
>
>   ...
>
> }
>
>   }
>
> }
>
>
>
> a/x/foo is conditional (due to when) but required (if the when condition is 
> met).
>
> a/x/bar is conditional (due to when) but optional (if the when condition is 
> met).
>
> a/y/baz is unconditional but required.
>
> a/y/tee is unconditional but optional.
>
>
>
>
>
> It should be clarified that elements become implicitly “mandatory false”
> when a “when” statement is used.
>
> But they don't.
>
>
>
>
> I would like to see an enhancement to YANG to control this behavior, to
> allow the mandatory status to be enforced.
>
> That is, support also “conditionally required” instead of only the current
> “conditionally optional”.
>
> I'm trying to understand what this would even mean.
>
> Taking your original example, but with "enforce-mandatory-status":
>
>  leaf AssignmentMechanism {
>
> type enumeration {
>
>   enum "DHCP";
>
>   enum "Static";
>
> }
>
> mandatory true;
>
> description "The address assignment mechanism.";
>
>   }
>
>   list IPAddresses {
>
> when "../AssignmentMechanism = 'Static'" {
>
>   enforce-mandatory-status;
>
> }  key Address;
>
> min-elements 1;
>
>
>
> leaf Address {
>
>   type capit:IPv4Address;
>
>   description "An ipv4 address.";
>
> }
>
>}
>
>
> So this means that list IPaddresses must have at least one element
> regardless of whether the when condition holds.  I.e. no matter whether the
> assignment is DHCP or Static there must always be at least one 1 address
> configured.  But I don't understand what this actually means - it seems
> like a contradiction.  What am I missing?  Please can you give a concrete
> example (in YANG) of what behaviour you are looking for.
>
> Thanks,
> Rob
>
> *“Amdocs’ email platform is based on a third-party, worldwide, cloud-based
> system. Any emails sent to Amdocs will be processed and stored using such
> system and are accessible by third party providers of such system on a
> limited basis. Your sending of emails to Amdocs evidences your consent to
> the use of such system and such processing, storing and access”.*
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod


Re: [netmod] xpath expressions in JSON

2018-10-12 Thread Andy Bierman
On Fri, Oct 12, 2018 at 3:22 AM, Robert Wilton  wrote:

> Hi Andy,
> On 11/10/2018 17:52, Andy Bierman wrote:
>
>
>
> On Thu, Oct 11, 2018 at 9:45 AM, Robert Wilton  wrote:
>
>>
>> 
>>
>>>
>>> Finally, I'm trying to figure out have RFC 8040 query parameter (sect
 4.8.4), which also uses XPath expressions is meant to work. That
 states:

 The set of namespace declarations is the set of prefix and
namespace pairs for all supported YANG modules, where the prefix
is the YANG module name and the namespace is as defined by the
"namespace" statement in the YANG module.

>>> Perfect!  It seems the authors of 8040 thought of this ;-)
>>>
>> OK, what you propose would at least be consistent with how the XPath is
>> formed in sec 8040, 4.8.4?
>>
>> I can live with that.  But still strongly think that WG should think of
>> trying to move YANG on from Xpath 1.0.
>>
>
>
> I do not agree YANG should change any statements where XPath is being used.
> (Note that leafs like the filter are free to use whatever data type they
> want, including yang:xpath1.0).
>
>
> OK, I think that I would be proposing either doing this as part of
> YANG.next, or perhaps as different leaf types.
>
>
> The WG is on the right track already wrt/ XPath by creating custom XPath
> functions
> like 'deref' that simplify syntax or extend functionality.
>
>
> Yes, the functions partially help.
>
> But there are bits of Xpath expressions that are not meaningful for YANG
> (e.g. NodeType checks or processing-instruction).
>
> The fact that NodeSets are sets rather than sequences isn't particularly
> helpful (fixed in future versions of XPath).
>
> E.g. if I wanted to check that a particular YANG boolean leaf is true then
> I might write "enabled = true" ... which is valid XPath, but probably
> doesn't do what most people expect ...
> When they realize that is wrong, perhaps they will try "enabled = true()"
> instead ... which is also valid XPath, but still probably won't do what
> they expect ...
> Instead they have to do 'enabled = "true"'.
>
> And then what about comparisons for 64 bit numbers that don't work
> properly?
>
> So, it seems like there are quite a lots of gotchas when using XPath for
> YANG, and it is far from an ideal language for expressing configuration
> constraints.
>
> If YANG adoption increases, and if folks start putting more validation
> constrains into the model then I hope that we will end up with a better
> language for expressing those constraints.
>
>

There are parts of XPath that are not used and most people are unaware
XPath even has
those details. Not a real problem.

There is usually a high cost to pay for instability. IMO we have already
seen that with the churn
that NMDA has caused. Training people over again has a cost.  Confusing
people by having
6 or 7 different path language variants that mostly look the same has a
cost.

I guess we will have this debate for real if YANG 2.0 is ever done


Thanks,
> Rob
>
>
Andy


>
>
>
>
>>
>>> Yet the examples in section 8.3.6 don't seem to use namespace prefixes
 in very many places, e.g. why is it "/example-mod:event1/name='joe'"
 and not "/example-mod:event1/example-mod:name='joe'"?  Is the example
 wrong, or otherwise what am I missing? :-)

>>> It seems the example is wrong!
>>>
>> Please can you check section 8040, 8.3.6.  Are all the examples wrong?
>>
>> Thanks,
>> Rob
>>
>>
>>>
>>> /martin
>>> .
>>>
>>>
>>
>
> Andy
>
>
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod


Re: [netmod] WHEN statement within mandatory objects doesn't ensure presence of the mandatory object

2018-10-12 Thread Michael Rehder
The mandatory statement in that case is ignored (I’ve pointed out the RNG and 
Schematron lack of enforcement).
WHEN trumps the mandatory status (via explicit mandatory or implicit mandatory 
via min-elements 1)

Thanks
Mike

From: Robert Wilton [mailto:rwil...@cisco.com]
Sent: Friday, October 12, 2018 12:06 PM
To: Michael Rehder 
Cc: Andy Bierman ; Walker, Jason 
(jason_walk...@comcast.com) ; netmod@ietf.org
Subject: Re: [netmod] WHEN statement within mandatory objects doesn't ensure 
presence of the mandatory object


Hi Mike,

On 11/10/2018 19:05, Andy Bierman wrote:


On Thu, Oct 11, 2018 at 11:00 AM, Michael Rehder 
mailto:michael.reh...@amdocs.com>> wrote:
I think the wording is relevant - something can be conditional but still 
required.
Yes, but I think that this is already expressed by a node that has both a when 
condition and mandatory statement.



container a {

  container x {

when "some condition";

leaf foo {

  mandatory true;

}

leaf bar {

  ...

}

  }

  container y {

leaf baz {

  mandatory true;

}

leaf tee {

  ...

}

  }

}



a/x/foo is conditional (due to when) but required (if the when condition is 
met).

a/x/bar is conditional (due to when) but optional (if the when condition is 
met).

a/y/baz is unconditional but required.

a/y/tee is unconditional but optional.




It should be clarified that elements become implicitly “mandatory false” when a 
“when” statement is used.
But they don't.



I would like to see an enhancement to YANG to control this behavior, to allow 
the mandatory status to be enforced.
That is, support also “conditionally required” instead of only the current 
“conditionally optional”.
I'm trying to understand what this would even mean.

Taking your original example, but with "enforce-mandatory-status":

 leaf AssignmentMechanism {

type enumeration {

  enum "DHCP";

  enum "Static";

}

mandatory true;

description "The address assignment mechanism.";

  }

  list IPAddresses {

when "../AssignmentMechanism = 'Static'" {

  enforce-mandatory-status;

}  key Address;

min-elements 1;



leaf Address {

  type capit:IPv4Address;

  description "An ipv4 address.";

}

   }

So this means that list IPaddresses must have at least one element regardless 
of whether the when condition holds.  I.e. no matter whether the assignment is 
DHCP or Static there must always be at least one 1 address configured.  But I 
don't understand what this actually means - it seems like a contradiction.  
What am I missing?  Please can you give a concrete example (in YANG) of what 
behaviour you are looking for.

Thanks,
Rob
“Amdocs’ email platform is based on a third-party, worldwide, cloud-based 
system. Any emails sent to Amdocs will be processed and stored using such 
system and are accessible by third party providers of such system on a limited 
basis. Your sending of emails to Amdocs evidences your consent to the use of 
such system and such processing, storing and access”.
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod


Re: [netmod] WHEN statement within mandatory objects doesn't ensure presence of the mandatory object

2018-10-12 Thread Robert Wilton

Hi Mike,


On 11/10/2018 19:05, Andy Bierman wrote:



On Thu, Oct 11, 2018 at 11:00 AM, Michael Rehder 
mailto:michael.reh...@amdocs.com>> wrote:


I think the wording is relevant - something can be conditional but
still required.

Yes, but I think that this is already expressed by a node that has both 
a when condition and mandatory statement.


container a {
  container x {
when "some condition";
leaf foo {
  mandatory true;
}
leaf bar {
  ...
}
  }
  container y {
leaf baz {
  mandatory true;
}
leaf tee {
  ...
}
  }
}

a/x/foo is conditional (due to when) but required (if the when condition is 
met).
a/x/bar is conditional (due to when) but optional (if the when condition is 
met).
a/y/baz is unconditional but required.
a/y/tee is unconditional but optional.



It should be clarified that elements become implicitly “mandatory
false” when a “when” statement is used.


But they don't.


I would like to see an enhancement to YANG to control this
behavior, to allow the mandatory status to be enforced.

That is, support also “conditionally required” instead of only the
current “conditionally optional”.


I'm trying to understand what this would even mean.

Taking your original example, but with "enforce-mandatory-status":

 leaf AssignmentMechanism {
type enumeration {
  enum "DHCP";
  enum "Static";
}
mandatory true;
description "The address assignment mechanism.";
  }
  list IPAddresses {
when "../AssignmentMechanism = 'Static'" {
  enforce-mandatory-status;
}  key Address;
min-elements 1;

leaf Address {

  type capit:IPv4Address;
  description "An ipv4 address.";
}
   }


So this means that list IPaddresses must have at least one element 
regardless of whether the when condition holds.  I.e. no matter whether 
the assignment is DHCP or Static there must always be at least one 1 
address configured.  But I don't understand what this actually means - 
it seems like a contradiction.  What am I missing? Please can you give a 
concrete example (in YANG) of what behaviour you are looking for.


Thanks,
Rob

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


Re: [netmod] Whitespace in XML encoding - allowed ?

2018-10-12 Thread Balázs Lengyel

  
  
Hello,
Thanks for all the replies. So preceding and following whitespace
  is not allowed. 
  However as I got similar questions often, and some RFC examples
  seem to indicate that it is allowed, I feel that an explanatory
  statement like the following would help YANG users.:
"It is not allowed to add preceding or following whitespace after
  the value of a leaf/leaf-list. 
  Note that some text documents may add whitespace to Netconf
  examples to avoid long lines, 
  however this extra whitespace MUST NOT be present in the actual
  Netconf encoding."
regards Balazs

On 2018. 10. 09. 10:59, Balázs Lengyel
  wrote:


  
  Hello,
  Recently we came up against a problem where a certain
implementation did not accept the following:
  
report-all

  while it did accept 
  
  report-all

  I am unsure whether YANG's XML encoding allows whitespace
before and after a leaf's value? In RFC7950 it does not say yes
or no. I have found the following examples that seem to allow
preceding/following whitespace:
  https://tools.ietf.org/html/rfc7950#section-4.2.9
 "http://example.com/system">
 The image example-fw-2.3 is being installed.
   

  https://tools.ietf.org/html/rfc7950#section-7.16.3
   
   /ex:interface[ex:name='Ethernet0']
 

  https://tools.ietf.org/html/rfc6243#appendix-A.3.1
  xml:ns:yang:ietf-netconf-with-defaults">
  report-all


  It is problematic that this is not clarified. IMHO this should
be clarified in an errata to rfc7950. Chose one:
  
It is not allowed to add preceding or following whitespace
  after the value of a leaf/leaf-list. 
  Note that some text documents may add whitespace to Netconf
  examples to avoid long lines, 
  however this extra whitespace MUST NOT be present in the
  actual Netconf encoding.

It is not allowed to add preceding or following whitespace
  after the value of a leaf/leaf-list.
It is allowed to add preceding or following whitespace after
  the value of a leaf/leaf-list except 
  for string based types, where the whitespace could be part of
  the leaf's value itself..
  
  What do you think?
  
  regards Balazs
  
  -- 
Balazs Lengyel   Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909  email: balazs.leng...@ericsson.com 

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


-- 
Balazs Lengyel   Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909  email: balazs.leng...@ericsson.com 

  




smime.p7s
Description: S/MIME Cryptographic Signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod


Re: [netmod] WHEN statement within mandatory objects doesn't ensure presence of the mandatory object

2018-10-12 Thread Michael Rehder
It depends what’s meant by “Conditional”. I think the term is distinct from 
“Optional”.

I don’t think the implementation can be changed (unless you meant that I change 
my own local implementation).

That’s why I think there should be a YANG language addition to control this 
behavior, since there are valid use cases for it.
Adding options to the WHEN statement seems a reasonable way to do this.

Thanks
Mike

From: Andy Bierman [mailto:a...@yumaworks.com]
Sent: Thursday, October 11, 2018 2:48 PM
To: Michael Rehder 
Cc: Juergen Schoenwaelder ; Walker, Jason 
(jason_walk...@comcast.com) ; netmod@ietf.org
Subject: Re: [netmod] WHEN statement within mandatory objects doesn't ensure 
presence of the mandatory object



On Thu, Oct 11, 2018 at 11:14 AM, Michael Rehder 
mailto:michael.reh...@amdocs.com>> wrote:
There is no specific text - the text just says it is “conditional”.
However the implementation forces it optional:

-  The RNG file makes it optional (I’m not actually running this for 
various reasons so I’m just interpreting the file generated – maybe I 
misunderstand RNG)

-  Schematron doesn’t check for its existence (like it does for a 
mandatory choice case)


So change the implementation so it conforms to the spec.


Thanks
Mike

Andy


From: Andy Bierman [mailto:a...@yumaworks.com]
Sent: Thursday, October 11, 2018 2:06 PM
To: Michael Rehder mailto:michael.reh...@amdocs.com>>
Cc: Juergen Schoenwaelder 
mailto:j.schoenwael...@jacobs-university.de>>;
 Walker, Jason (jason_walk...@comcast.com) 
mailto:jason_walk...@comcast.com>>; 
netmod@ietf.org
Subject: Re: [netmod] WHEN statement within mandatory objects doesn't ensure 
presence of the mandatory object



On Thu, Oct 11, 2018 at 11:00 AM, Michael Rehder 
mailto:michael.reh...@amdocs.com>> wrote:
I think the wording is relevant - something can be conditional but still 
required.
It should be clarified that elements become implicitly “mandatory false” when a 
“when” statement is used.

I would like to see an enhancement to YANG to control this behavior, to allow 
the mandatory status to be enforced.
That is, support also “conditionally required” instead of only the current 
“conditionally optional”.



  leaf foo {
 when "../some-other-node = 5";
 type int32;
 mandatory true;
 }


This leaf is mandatory if the when-expr is true.
Where is the text in 7950 that says this mandatory true is ignored if when-stmt 
is present?



Thanks
Mike

Andy



From: Andy Bierman [mailto:a...@yumaworks.com]
Sent: Wednesday, October 10, 2018 2:52 PM
To: Michael Rehder mailto:michael.reh...@amdocs.com>>
Cc: Juergen Schoenwaelder 
mailto:j.schoenwael...@jacobs-university.de>>;
 Walker, Jason (jason_walk...@comcast.com) 
mailto:jason_walk...@comcast.com>>; 
netmod@ietf.org
Subject: Re: [netmod] WHEN statement within mandatory objects doesn't ensure 
presence of the mandatory object



On Wed, Oct 10, 2018 at 11:44 AM, Michael Rehder 
mailto:michael.reh...@amdocs.com>> wrote:
Sure.

I think the RFC is unclear since it seems that the semantics are consistent in 
the back-end checks.
One can read the RFC and not notice by its absence that the when clause doesn't 
require anything to be present.

 The "when" statement makes its parent data definition statement 
conditional.
Should be
The "when" statement makes its parent data definition statement conditional 
and optional.

This is not correct.

Step 1) if-feature makes the schema node conditional

Step 2) when-stmt makes instances of the schema-node conditional

Step 3) YANG validation applies to instances of data nodes (or the YANG default 
value if applicable)

Step 2 is only relevant if Step 1 is true or non-existent
Step 3 is only relevant if Step 2 is true or non-existent

Andy


I think there should be a more definite statement about this overriding any 
mandatory status of the parent data definition statement.
Like
 "Any mandatory status of the parent data definition statement (mandatory 
statement, min-element statement etc.) is overridden by this statement and made 
non-mandatory."

That would have made the side-effect of "when" on other declarations clearer.

Thanks
mike
> -Original Message-
> From: Juergen Schoenwaelder 
> [mailto:j.schoenwael...@jacobs-university.de]
> Sent: Wednesday, October 10, 2018 2:25 PM
> To: Michael Rehder 
> mailto:michael.reh...@amdocs.com>>
> Cc: Robert Wilton mailto:rwil...@cisco.com>>; Ladislav 
> Lhotka mailto:lho...@nic.cz>>;
> netmod@ietf.org; Walker, Jason 
> (jason_walk...@comcast.com)
> mailto:jason_walk...@comcast.com>>
> Subject: Re: [netmod] WHEN statement within mandatory objects doesn't
> ensure presence of the mandatory object
>
> Michael,
>
> what 

Re: [netmod] xpath expressions in JSON

2018-10-12 Thread Robert Wilton

Hi Andy,

On 11/10/2018 17:52, Andy Bierman wrote:



On Thu, Oct 11, 2018 at 9:45 AM, Robert Wilton > wrote:






Finally, I'm trying to figure out have RFC 8040 query
parameter (sect
4.8.4), which also uses XPath expressions is meant to
work. That
states:

The set of namespace declarations is the set of prefix and
       namespace pairs for all supported YANG modules,
where the prefix
       is the YANG module name and the namespace is as
defined by the
       "namespace" statement in the YANG module.

Perfect!  It seems the authors of 8040 thought of this ;-)

OK, what you propose would at least be consistent with how the
XPath is formed in sec 8040, 4.8.4?

I can live with that.  But still strongly think that WG should
think of trying to move YANG on from Xpath 1.0.



I do not agree YANG should change any statements where XPath is being 
used.
(Note that leafs like the filter are free to use whatever data type 
they want, including yang:xpath1.0).


OK, I think that I would be proposing either doing this as part of 
YANG.next, or perhaps as different leaf types.




The WG is on the right track already wrt/ XPath by creating custom 
XPath functions

like 'deref' that simplify syntax or extend functionality.


Yes, the functions partially help.

But there are bits of Xpath expressions that are not meaningful for YANG 
(e.g. NodeType checks or processing-instruction).


The fact that NodeSets are sets rather than sequences isn't particularly 
helpful (fixed in future versions of XPath).


E.g. if I wanted to check that a particular YANG boolean leaf is true 
then I might write "enabled = true" ... which is valid XPath, but 
probably doesn't do what most people expect ...
When they realize that is wrong, perhaps they will try "enabled = 
true()" instead ... which is also valid XPath, but still probably won't 
do what they expect ...

Instead they have to do 'enabled = "true"'.

And then what about comparisons for 64 bit numbers that don't work properly?

So, it seems like there are quite a lots of gotchas when using XPath for 
YANG, and it is far from an ideal language for expressing configuration 
constraints.


If YANG adoption increases, and if folks start putting more validation 
constrains into the model then I hope that we will end up with a better 
language for expressing those constraints.


Thanks,
Rob







Yet the examples in section 8.3.6 don't seem to use
namespace prefixes
in very many places, e.g. why is it
"/example-mod:event1/name='joe'"
and not "/example-mod:event1/example-mod:name='joe'"? Is
the example
wrong, or otherwise what am I missing? :-)

It seems the example is wrong!

Please can you check section 8040, 8.3.6.  Are all the examples wrong?

Thanks,
Rob



/martin
.




Andy



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


Re: [netmod] xpath expressions in JSON

2018-10-12 Thread Robert Wilton



On 12/10/2018 09:37, Martin Bjorklund wrote:

Robert Wilton  wrote:


On 11/10/2018 17:11, Martin Bjorklund wrote:

Robert Wilton  wrote:

On 11/10/2018 11:50, Martin Bjorklund wrote:

Robert Wilton  wrote:

On 11/10/2018 11:21, Martin Bjorklund wrote:

Andy Bierman  wrote:

On Wed, Oct 10, 2018 at 11:39 PM, Martin Bjorklund 
wrote:


Andy Bierman  wrote:

On Wed, Oct 10, 2018 at 6:59 PM, Reshad Rahman (rrahman) <

rrah...@cisco.com>

wrote:


On 2018-10-10, 9:59 AM, "netmod on behalf of Martin Bjorklund" <
netmod-boun...@ietf.org on behalf of m...@tail-f.com> wrote:

Ladislav Lhotka  wrote:
> Martin Bjorklund  writes:
>
> > Hi,
> >
> > While reviewing restconf-notif, I saw this example:
> >
> >{
> >   "ietf-subscribed-notifications:input": {
> >  "stream": "NETCONF",
> >  "stream-xpath-filter": "/ds:foo/",
> >  "dscp": "10"
> >   }
> >}
> >
> > Note the "stream-xpath-filter".  It has a prefix in the
> > XPath
string.
> > How are prefixes declared when JSON is used?
> >
> > The leaf "stream-xpath-filter" says:
> >
> >   o The set of namespace declarations are
> >   those
> >   in
scope on
> >  the 'stream-xpath-filter' leaf element.
> >
> > (I think I provided that text...)
> >
> > This assumes that the encoding is XML, or at leas that the

encoding

> > can somehow transfer namespace declarations.
>
> It can't. There are two options:
>
> 1. have different representations of this value in XML and
> JSON,
>analogically to instance indentifiers (sec. 6.11 in RFC
>7951).
>
> 2. use a module name rather than a prefix in XML, too.
>
> I would suggest #2.
 But that means making non-backwards compatible change to the XML
representation?


Not really. It means NETMOD WG would be creating its own special
variant

of

XPath.

Not at all.  What I propose is perfectly fine, legal XPath 1.0.

XPath 1.0 says that an XPath expression is evaluated in a context.
One item in the context is a set of mappings from  to ,
where  is used to lookup prefixes used in the XPath
expression, e.g. in "/foo:interfaces" "foo" is the prefix.

It is perfectly fine to say that the prefix mapping set is this:

   "ietf-interfaces" ->
   "urn:ietf:params:xml:ns:yang:ietf-interfaces"
   "ietf-ip" -> "urn:ietf:params:xml:ns:yang:ietf-ip"

and use that to evaluate the expression

  /ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip/ipv4




The XPath expression is normally parsed within an XML instance
document.
There are "xmlns" attributes present that map the prefix to a
namespace URI.
These mappings will not be present in the JSON at all.

A custom XPath implementation is required to magically identify the
prefix
as a module name and magically find the namespace URI for the module
name.

I disagree.  You need an XPath implementation + custom code to set up
the environment.

This is OK, but can we just use the JSON encoding instance identifier
format exactly?  I.e .RFC 7951 section 6.11.

So "/ietf-interfaces:interfaces/interface/ietf-ip:ipv4/enabled"

can trivially be expanded to:

"/ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip:ipv4/ietf-ip:enabled",

and then interpreted with the context:
"ietf-interfaces" -> "urn:ietf:params:xml:ns:yang:ietf-interfaces"
  "ietf-ip" -> "urn:ietf:params:xml:ns:yang:ietf-ip"

*this* would require a custom XPath implementation.

Why?  I.e. how is this different from stating "Custom code is needed
to connect things together"?

B/c the specification of XPath allows you to (actually, *requires* you
to) construct the set of prefix strings to url mappings.

This is "custom code to connect things".

But changing the syntax means changin the specification.

Not really.

It would just mean that the filter value is not an "Xpath"
expression.  It is a more a concise string that can be expanded into
an Xpath expression.


and it is not obvious what the rules for the "auto-assignment" of
prefixes would be.  For example:

 /ietf-interfaces//ietf-ip:address[../foo]

what is the prefix for "foo"?

OK, so here the module for "../foo" would need to be specified.

Perhaps the rule that I'm looking for is the module name may be
omitted when it matches the parent node module, and can easily be
inferred.  I.e. so that for any XPath string, it is possible to
trivially expand it without any additional schema context.

It just seems to be that requiring the long hand of
"/ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip:ipv4/ietf-ip:enabled"
seems like it will get very verbose, and I wonder whether we are
introducing yet 

Re: [netmod] xpath expressions in JSON

2018-10-12 Thread Martin Bjorklund
Robert Wilton  wrote:
> 
> 
> On 11/10/2018 17:11, Martin Bjorklund wrote:
> > Robert Wilton  wrote:
> >>
> >> On 11/10/2018 11:50, Martin Bjorklund wrote:
> >>> Robert Wilton  wrote:
>  On 11/10/2018 11:21, Martin Bjorklund wrote:
> > Andy Bierman  wrote:
> >> On Wed, Oct 10, 2018 at 11:39 PM, Martin Bjorklund 
> >> wrote:
> >>
> >>> Andy Bierman  wrote:
>  On Wed, Oct 10, 2018 at 6:59 PM, Reshad Rahman (rrahman) <
> >>> rrah...@cisco.com>
>  wrote:
> 
> > On 2018-10-10, 9:59 AM, "netmod on behalf of Martin Bjorklund" <
> > netmod-boun...@ietf.org on behalf of m...@tail-f.com> wrote:
> >
> >Ladislav Lhotka  wrote:
> >> Martin Bjorklund  writes:
> >>
> >> > Hi,
> >> >
> >> > While reviewing restconf-notif, I saw this example:
> >> >
> >> >{
> >> >   "ietf-subscribed-notifications:input": {
> >> >  "stream": "NETCONF",
> >> >  "stream-xpath-filter": "/ds:foo/",
> >> >  "dscp": "10"
> >> >   }
> >> >}
> >> >
> >> > Note the "stream-xpath-filter".  It has a prefix in the
> >> > XPath
> > string.
> >> > How are prefixes declared when JSON is used?
> >> >
> >> > The leaf "stream-xpath-filter" says:
> >> >
> >> >   o The set of namespace declarations are
> >> >   those
> >> >   in
> > scope on
> >> >  the 'stream-xpath-filter' leaf element.
> >> >
> >> > (I think I provided that text...)
> >> >
> >> > This assumes that the encoding is XML, or at leas that 
> > the
> >>> encoding
> >> > can somehow transfer namespace declarations.
> >>
> >> It can't. There are two options:
> >>
> >> 1. have different representations of this value in XML and
> >> JSON,
> >>analogically to instance indentifiers (sec. 6.11 in RFC
> >>7951).
> >>
> >> 2. use a module name rather than a prefix in XML, too.
> >>
> >> I would suggest #2.
> >  But that means making non-backwards compatible change to the 
> > XML
> > representation?
> >
>  Not really. It means NETMOD WG would be creating its own special
>  variant
> >>> of
>  XPath.
> >>> Not at all.  What I propose is perfectly fine, legal XPath 1.0.
> >>>
> >>> XPath 1.0 says that an XPath expression is evaluated in a context.
> >>> One item in the context is a set of mappings from  to ,
> >>> where  is used to lookup prefixes used in the XPath
> >>> expression, e.g. in "/foo:interfaces" "foo" is the prefix.
> >>>
> >>> It is perfectly fine to say that the prefix mapping set is this:
> >>>
> >>>   "ietf-interfaces" ->
> >>>   "urn:ietf:params:xml:ns:yang:ietf-interfaces"
> >>>   "ietf-ip" -> "urn:ietf:params:xml:ns:yang:ietf-ip"
> >>>
> >>> and use that to evaluate the expression
> >>>
> >>>  
> >>> /ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip/ipv4
> >>>
> >>>
> >>>
> >> The XPath expression is normally parsed within an XML instance
> >> document.
> >> There are "xmlns" attributes present that map the prefix to a
> >> namespace URI.
> >> These mappings will not be present in the JSON at all.
> >>
> >> A custom XPath implementation is required to magically identify the
> >> prefix
> >> as a module name and magically find the namespace URI for the module
> >> name.
> > I disagree.  You need an XPath implementation + custom code to set up
> > the environment.
>  This is OK, but can we just use the JSON encoding instance identifier
>  format exactly?  I.e .RFC 7951 section 6.11.
> 
>  So "/ietf-interfaces:interfaces/interface/ietf-ip:ipv4/enabled"
> 
>  can trivially be expanded to:
> 
>  "/ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip:ipv4/ietf-ip:enabled",
> 
>  and then interpreted with the context:
> "ietf-interfaces" -> "urn:ietf:params:xml:ns:yang:ietf-interfaces"
>   "ietf-ip" -> "urn:ietf:params:xml:ns:yang:ietf-ip"
> >>> *this* would require a custom XPath implementation.
> >> Why?  I.e. how is this different from stating "Custom code is needed
> >> to connect things together"?
> > B/c the specification of XPath allows you to