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

[Ladislav Lhotka]

On Wed, 2018-10-10 at 18:44 +, Michael Rehder 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.

Data nodes in YANG are optional by default and become mandatory only in certain
cases (in RFC 6020 these cases were specified in section 3.1). In contrast,
RELAX NG  patterns are mandatory by default and  is used to
make them optional.

Lada

> 
> 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 
> > Cc: Robert Wilton ; Ladislav Lhotka ;
> > netmod@ietf.org; Walker, Jason (jason_walk...@comcast.com)
> > 
> > Subject: Re: [netmod] WHEN statement within mandatory objects doesn't
> > ensure presence of the mandatory object
> > 
> > Michael,
> > 
> > what matters here is what the YANG specification (RFC 7950) says. Is there a
> > reason to believe the IPAddresses list in your example can be absent or have
> > no
> > elements based on what RFC 7950 says? Or do we talk about a shortcoming of
> > RFC 6110?
> > 
> > /js
> > 
> > On Wed, Oct 10, 2018 at 06:17:26PM +, Michael Rehder wrote:
> > > If the list has a "when" clause the RNG file actually produces a
> > > "OneOrMore"
> > which has a choice of  or the list so it actually doesn't enforce the
> > presence at least one row of the list (unless I'm mistaken in my reading).
> > >   
> > > 
> > >   
> > >   
> > > 
> > >   
> > > 
> > > 
> > >   
> > > 
> > >   
> > > 
> > > A leaf/container would be a simpler example but would result in the same
> > lack of enforcement of the mandatory status of an element with a "when"
> > clause.
> > > This RNG seems consistent with the Schematron rules that "when" makes
> > something optional.
> > > 
> > > I think a workaround would be choice with mandatory true and a when clause
> > on the cases. This would ensure that at least one case is present since the
> > mandatory clause implements a Schematron existence constraint.
> > > Thanks
> > > Mike
> > > > -Original Message-
> > > > From: Robert Wilton [mailto:rwil...@cisco.com]
> > > > Sent: Wednesday, October 10, 2018 11:33 AM
> > > > To: Michael Rehder ; Ladislav Lhotka
> > > > ; netmod@ietf.org
> > > > Cc: Walker, Jason (jason_walk...@comcast.com)
> > > > 
> > > > Subject: Re: [netmod] WHEN statement within mandatory objects
> > > > doesn't ensure presence of the mandatory object
> > > > 
> > > > Hi Mike,
> > > > 
> > > > I think that the YANG below already enforces what you want, or
> > > > otherwise I don't follow your issue.
> > > > 
> > > > The YANG below is valid in two cases:
> > > > 
> > > > (1) AssignmentMechanism = DHCP, and IPAddresses is not present in
> > > > the config (due to the when statement).
> > > > (2) AssignmentMechanism = Static, IPAddresses exists and has at
> > > > least one element (due to min-elements 1).
> > > > 
> > > > Thanks,
> > > > Rob
> > > > 
> > > > 
> > > > On 10/10/2018 16:23, Michael Rehder wrote:
> > > > > Container "foo" would be mandatory if not for the "when" child
> > > > > element.
> > > > > With the "when" child element, the logic becomes "inverted" and
> > > > > the
> > > > constraint is a negative one of "disallowed under certain condition".
> > > > > The UC is for enforcement in REST API payloads.
> > > > > For a practical example:
> > > > > 
> > > > >   leaf AssignmentMechanism {
> > > > >  type enumeration {
> > > > >enum "DHCP";
> > > > >enum "Static";
> > > > >  }
> > > > >  mandatory true;
> > > > >  description "The address assignment mechanism.";
> > > > >}
> > > > >list IPAddresses {
> > > > >  when "../AssignmentMechanism = 'Static'";
> > > > >  key Address;
> > > > >  min-elements 1;
> > > > > 
> > > > >  leaf Address {
> > > > >type capit:IPv4Address;
> > > > >description "An ipv4 address.";
> > > > > 

[netmod] Suresh Krishnan's No Objection on draft-ietf-netmod-schema-mount-11: (with COMMENT)

[Suresh Krishnan]

Suresh Krishnan 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:
--

Section 3.3.

I think it would be nice to have some examples to illustrate the differences
between inline and shared-schema and some guidance to pick between the two.


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

Re: [netmod] xpath expressions in JSON

[Qin Wu]

-邮件原件-
发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Ladislav Lhotka
发送时间: 2018年10月10日 20:41
收件人: Martin Bjorklund; netmod@ietf.org
主题: Re: [netmod] xpath expressions in JSON

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).

[Qin]: This has been brought up before:
https://www.ietf.org/mail-archive/web/netconf/current/msg15501.html

2. use a module name rather than a prefix in XML, too.

I would suggest #2.

Lada

>
> How is this supposed to work with JSON?
>
>
> /martin
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

--
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

___
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] xpath expressions in JSON

[Andy Bierman]

On Wed, Oct 10, 2018 at 6:59 PM, Reshad Rahman (rrahman) 
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.


> Hmm, so you mean change the leaf "stream-xpath-filter" to say:
>
>  o  The set of namespace declarations has one member for each
> YANG module supported by the server.  This member maps
> from the YANG module name to the YANG module namespace.
>
> This means that in the XPath expression, the module name
> serves as the prefix.
>
>  and then also give an example of this.
>
> This is probably what we need to do in all places where yang:xpath1.0
> is used, going forward.  Maybe even define a new type
> yang:xpath1.0-2 (name?) with the set of namespace declarations
> built-in.
>


We should avoid making off-the-shelf implementations of standards like
XPath unusable.
At the very least this should be only available if the server supports it
(with a capability URI)



>  So we need an update to RFC7951?
>
> Regards,
> Reshad.
>
>

Andy


>
> /martin
>
>
>
>
>
> >
> > Lada
> >
> > >
> > > How is this supposed to work with JSON?
> > >
> > >
> > > /martin
> > >
> > > ___
> > > netmod mailing list
> > > netmod@ietf.org
> > > https://www.ietf.org/mailman/listinfo/netmod
> >
> > --
> > Ladislav Lhotka
> > Head, CZ.NIC Labs
> > PGP Key ID: 0xB8F92B08A9F76C67
> >
>
> ___
> 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] WG adoption poll for draft-clemm-netmod-nmda-diff-00

[Andy Bierman]

On Wed, Oct 10, 2018 at 6:39 PM, Kent Watsen  wrote:

> Hi Alex, no objection.
>
> My support withdraw appears to put me in the rough, which is fine from a
> process perspective.  But make no mistake, I think that it's bizaar for a
> "diff" to not show both values.  Andy's idea to augment in an 'old-value'
> node seems like a step in the right direction.
>
>
The requirements and use-cases have not really been discussed first.
If the use-case is for humans to compare the datastores (e.g., a
side-by-side diff like an I-D)
then the format would be very different than if the use-case was more
programmatic
(e.g., look for no diffs, look for an edit completed, patch a local copy).


> Kent // contributor
>

Andy


>
>
> -Original Message-
> From: Alexander Clemm 
> Date: Wednesday, October 10, 2018 at 6:06 PM
> To: Kent Watsen , Ladislav Lhotka ,
> Andy Bierman , Juergen Schoenwaelder <
> j.schoenwael...@jacobs-university.de>, "netmod@ietf.org" 
> Subject: RE: [netmod] WG adoption poll for draft-clemm-netmod-nmda-diff-00
>
> Which format to make mandatory sounds like something we can discuss in
> Bangkok.  The reason YANG-patch was chosen is reuse, although it is
> certainly conceivable to develop another format.  (Per discussion on the
> list we will put the hooks in place to allow for other options.)  Either
> way, this seems to be one of the technical details that need to be decided,
> not something that would make or break support as a whole?
> --- Alex
>
> > -Original Message-
> > From: Kent Watsen [mailto:kwat...@juniper.net]
> > Sent: Tuesday, October 09, 2018 10:17 AM
> > To: Alexander Clemm ; Ladislav Lhotka
> > ; Andy Bierman ; Juergen
> > Schoenwaelder ; netmod@ietf.org
> > Subject: Re: [netmod] WG adoption poll for draft-clemm-netmod-nmda-diff-
> 00
> >
> > I agree that a mandatory to implement format is desirable.
> >
> > I disagree that YANG-Patch is the right format, for reasons stated
> before.  I feel
> > that a compromise of this sort for a mandatory-to-implement is wrong.
> >
> > If this is what the WG wants, I withdraw my support.
> >
> > Kent // contributor
> >
> >
> >
> > -Original Message-
> > From: Alexander Clemm 
> > Date: Monday, October 8, 2018 at 5:05 PM
> > To: Ladislav Lhotka , Kent Watsen ,
> > Andy Bierman , Juergen Schoenwaelder
> > , "netmod@ietf.org"
> > 
> > Subject: RE: [netmod] WG adoption poll for draft-clemm-netmod-nmda-diff-
> 00
> >
> > I would second the request for one format (which is mandatory to
> support),
> > which must be specified.  YANG-Patch is the logical candidate IMHO.
> >
> > To allow selection of other formats using an input parameter makes
> sense, but
> > adds some complexity from there:  How to know which formats are
> supported?
> > (Add a list of supported formats somewhere?)   Or simply rely on
> augmentation
> > for those implementations that want it?
> >
> > --- Alex
> >
> > > -Original Message-
> > > From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Ladislav
> > > Lhotka
> > > Sent: Friday, October 05, 2018 12:50 AM
> > > To: Kent Watsen ; Andy Bierman
> > > ; Juergen Schoenwaelder  > > university.de>; netmod@ietf.org
> > > Subject: Re: [netmod] WG adoption poll for
> > > draft-clemm-netmod-nmda-diff-00
> > >
> > > Kent Watsen  writes:
> > >
> > > > Sure, one mandatory to implement format, others nice to have.
> > > > Interoperability good.  Agreed.
> > > >
> > > > But why YANG-patch and not something built for the purpose (e.g.,
> > > > YANG-diff) that, in particular, provides an actual diff as opposed
> > > > to a data-tree operation that only shows one of the two values?
> > >
> > > Such a format can be developed independently, I would support it.
> > >
> > > Lada
> > >
> > > >
> > > > Kent // contributor
> > > >
> > > >
> > > > On 10/4/18, 3:27 PM, "Andy Bierman"
> > > mailto:a...@yumaworks.com>> wrote:
> > > >
> > > > On Thu, Oct 4, 2018 at 12:07 PM, Juergen Schoenwaelder
> > > mailto:j.schoenwaelder@jacobs-
> > > university.de>> wrote:
> > > > Folks, the more formats there are, the less interoperability we get..
> > > > If there are multiple formats, is there a mandatory to implement
> > > > format? Does the mandatory to implement format depend on the
> > > > protocol that is being used?
> > > >
> > > > I prefer one format or if necessary I am fine with one mandatory to
> > > > implement format. An open ended collection of implementation
> > > > specific formats is super flexible but defeats the purpose of a
> > > > standard, namely interoperability.
> > > >
> > > > I agree there needs to be 1 mandatory-to-implement format.
> > > >
> > > > IMO this needs to be YANG Patch because it is more precise then
> > > > constructing an XML tree with operation attributes in it (e.g., how
> > > > else do you represent a delete or a move?) Also, YANG Push is using
> > > > YANG Patch format and common code for push and diff would be
> possible.
> > > >
> > > > I think other formats should be allowed.
> > > > 

Re: [netmod] xpath expressions in JSON

[Reshad Rahman (rrahman)]

On 2018-10-10, 9:59 AM, "netmod on behalf of Martin Bjorklund" 
 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?

Hmm, so you mean change the leaf "stream-xpath-filter" to say:

 o  The set of namespace declarations has one member for each
YANG module supported by the server.  This member maps
from the YANG module name to the YANG module namespace.

This means that in the XPath expression, the module name
serves as the prefix.

 and then also give an example of this.

This is probably what we need to do in all places where yang:xpath1.0
is used, going forward.  Maybe even define a new type
yang:xpath1.0-2 (name?) with the set of namespace declarations
built-in.
 So we need an update to RFC7951?

Regards,
Reshad.


/martin





> 
> Lada
> 
> >
> > How is this supposed to work with JSON?
> >
> >
> > /martin
> >
> > ___
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> 
> -- 
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
> 

___
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] WG adoption poll for draft-clemm-netmod-nmda-diff-00

[Kent Watsen]

Hi Alex, no objection.

My support withdraw appears to put me in the rough, which is fine from a 
process perspective.  But make no mistake, I think that it's bizaar for a 
"diff" to not show both values.  Andy's idea to augment in an 'old-value' node 
seems like a step in the right direction.

Kent // contributor


-Original Message-
From: Alexander Clemm 
Date: Wednesday, October 10, 2018 at 6:06 PM
To: Kent Watsen , Ladislav Lhotka , Andy 
Bierman , Juergen Schoenwaelder 
, "netmod@ietf.org" 
Subject: RE: [netmod] WG adoption poll for draft-clemm-netmod-nmda-diff-00

Which format to make mandatory sounds like something we can discuss in Bangkok. 
 The reason YANG-patch was chosen is reuse, although it is certainly 
conceivable to develop another format.  (Per discussion on the list we will put 
the hooks in place to allow for other options.)  Either way, this seems to be 
one of the technical details that need to be decided, not something that would 
make or break support as a whole?  
--- Alex

> -Original Message-
> From: Kent Watsen [mailto:kwat...@juniper.net]
> Sent: Tuesday, October 09, 2018 10:17 AM
> To: Alexander Clemm ; Ladislav Lhotka
> ; Andy Bierman ; Juergen
> Schoenwaelder ; netmod@ietf.org
> Subject: Re: [netmod] WG adoption poll for draft-clemm-netmod-nmda-diff-00
> 
> I agree that a mandatory to implement format is desirable.
> 
> I disagree that YANG-Patch is the right format, for reasons stated before.  I 
> feel
> that a compromise of this sort for a mandatory-to-implement is wrong.
> 
> If this is what the WG wants, I withdraw my support.
> 
> Kent // contributor
> 
> 
> 
> -Original Message-
> From: Alexander Clemm 
> Date: Monday, October 8, 2018 at 5:05 PM
> To: Ladislav Lhotka , Kent Watsen ,
> Andy Bierman , Juergen Schoenwaelder
> , "netmod@ietf.org"
> 
> Subject: RE: [netmod] WG adoption poll for draft-clemm-netmod-nmda-diff-00
> 
> I would second the request for one format (which is mandatory to support),
> which must be specified.  YANG-Patch is the logical candidate IMHO.
> 
> To allow selection of other formats using an input parameter makes sense, but
> adds some complexity from there:  How to know which formats are supported?
> (Add a list of supported formats somewhere?)   Or simply rely on augmentation
> for those implementations that want it?
> 
> --- Alex
> 
> > -Original Message-
> > From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Ladislav
> > Lhotka
> > Sent: Friday, October 05, 2018 12:50 AM
> > To: Kent Watsen ; Andy Bierman
> > ; Juergen Schoenwaelder  > university.de>; netmod@ietf.org
> > Subject: Re: [netmod] WG adoption poll for
> > draft-clemm-netmod-nmda-diff-00
> >
> > Kent Watsen  writes:
> >
> > > Sure, one mandatory to implement format, others nice to have.
> > > Interoperability good.  Agreed.
> > >
> > > But why YANG-patch and not something built for the purpose (e.g.,
> > > YANG-diff) that, in particular, provides an actual diff as opposed
> > > to a data-tree operation that only shows one of the two values?
> >
> > Such a format can be developed independently, I would support it.
> >
> > Lada
> >
> > >
> > > Kent // contributor
> > >
> > >
> > > On 10/4/18, 3:27 PM, "Andy Bierman"
> > mailto:a...@yumaworks.com>> wrote:
> > >
> > > On Thu, Oct 4, 2018 at 12:07 PM, Juergen Schoenwaelder
> > mailto:j.schoenwaelder@jacobs-
> > university.de>> wrote:
> > > Folks, the more formats there are, the less interoperability we get.
> > > If there are multiple formats, is there a mandatory to implement
> > > format? Does the mandatory to implement format depend on the
> > > protocol that is being used?
> > >
> > > I prefer one format or if necessary I am fine with one mandatory to
> > > implement format. An open ended collection of implementation
> > > specific formats is super flexible but defeats the purpose of a
> > > standard, namely interoperability.
> > >
> > > I agree there needs to be 1 mandatory-to-implement format.
> > >
> > > IMO this needs to be YANG Patch because it is more precise then
> > > constructing an XML tree with operation attributes in it (e.g., how
> > > else do you represent a delete or a move?) Also, YANG Push is using
> > > YANG Patch format and common code for push and diff would be possible.
> > >
> > > I think other formats should be allowed.
> > > This is very tool-specific. I could see how somebody might want a
> > > textual patch of the XML representation to produce the new XML
> > representation.
> > >
> > >
> > > /js
> > >
> > > Andy
> > >
> > >
> > > On Thu, Oct 04, 2018 at 05:41:22PM +, Kent Watsen wrote:
> > >> We agree that the diff-format should be client-selectable, modulo
> > >> what the
> > server supports.  yang-patch and edit-config both are viable.  Should
> > we document them both?
> > >>
> > >> That said, since neither edit-config nor yang-patch are diffing
> > >> formats, so
> > much as formats for converting one data tree to another, would it make
> > sense to 

Re: [netmod] WG adoption poll for draft-clemm-netmod-nmda-diff-00

[Alexander Clemm]

Which format to make mandatory sounds like something we can discuss in Bangkok. 
 The reason YANG-patch was chosen is reuse, although it is certainly 
conceivable to develop another format.  (Per discussion on the list we will put 
the hooks in place to allow for other options.)  Either way, this seems to be 
one of the technical details that need to be decided, not something that would 
make or break support as a whole?  
--- Alex

> -Original Message-
> From: Kent Watsen [mailto:kwat...@juniper.net]
> Sent: Tuesday, October 09, 2018 10:17 AM
> To: Alexander Clemm ; Ladislav Lhotka
> ; Andy Bierman ; Juergen
> Schoenwaelder ; netmod@ietf.org
> Subject: Re: [netmod] WG adoption poll for draft-clemm-netmod-nmda-diff-00
> 
> I agree that a mandatory to implement format is desirable.
> 
> I disagree that YANG-Patch is the right format, for reasons stated before.  I 
> feel
> that a compromise of this sort for a mandatory-to-implement is wrong.
> 
> If this is what the WG wants, I withdraw my support.
> 
> Kent // contributor
> 
> 
> 
> -Original Message-
> From: Alexander Clemm 
> Date: Monday, October 8, 2018 at 5:05 PM
> To: Ladislav Lhotka , Kent Watsen ,
> Andy Bierman , Juergen Schoenwaelder
> , "netmod@ietf.org"
> 
> Subject: RE: [netmod] WG adoption poll for draft-clemm-netmod-nmda-diff-00
> 
> I would second the request for one format (which is mandatory to support),
> which must be specified.  YANG-Patch is the logical candidate IMHO.
> 
> To allow selection of other formats using an input parameter makes sense, but
> adds some complexity from there:  How to know which formats are supported?
> (Add a list of supported formats somewhere?)   Or simply rely on augmentation
> for those implementations that want it?
> 
> --- Alex
> 
> > -Original Message-
> > From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Ladislav
> > Lhotka
> > Sent: Friday, October 05, 2018 12:50 AM
> > To: Kent Watsen ; Andy Bierman
> > ; Juergen Schoenwaelder  > university.de>; netmod@ietf.org
> > Subject: Re: [netmod] WG adoption poll for
> > draft-clemm-netmod-nmda-diff-00
> >
> > Kent Watsen  writes:
> >
> > > Sure, one mandatory to implement format, others nice to have.
> > > Interoperability good.  Agreed.
> > >
> > > But why YANG-patch and not something built for the purpose (e.g.,
> > > YANG-diff) that, in particular, provides an actual diff as opposed
> > > to a data-tree operation that only shows one of the two values?
> >
> > Such a format can be developed independently, I would support it.
> >
> > Lada
> >
> > >
> > > Kent // contributor
> > >
> > >
> > > On 10/4/18, 3:27 PM, "Andy Bierman"
> > mailto:a...@yumaworks.com>> wrote:
> > >
> > > On Thu, Oct 4, 2018 at 12:07 PM, Juergen Schoenwaelder
> > mailto:j.schoenwaelder@jacobs-
> > university.de>> wrote:
> > > Folks, the more formats there are, the less interoperability we get.
> > > If there are multiple formats, is there a mandatory to implement
> > > format? Does the mandatory to implement format depend on the
> > > protocol that is being used?
> > >
> > > I prefer one format or if necessary I am fine with one mandatory to
> > > implement format. An open ended collection of implementation
> > > specific formats is super flexible but defeats the purpose of a
> > > standard, namely interoperability.
> > >
> > > I agree there needs to be 1 mandatory-to-implement format.
> > >
> > > IMO this needs to be YANG Patch because it is more precise then
> > > constructing an XML tree with operation attributes in it (e.g., how
> > > else do you represent a delete or a move?) Also, YANG Push is using
> > > YANG Patch format and common code for push and diff would be possible.
> > >
> > > I think other formats should be allowed.
> > > This is very tool-specific. I could see how somebody might want a
> > > textual patch of the XML representation to produce the new XML
> > representation.
> > >
> > >
> > > /js
> > >
> > > Andy
> > >
> > >
> > > On Thu, Oct 04, 2018 at 05:41:22PM +, Kent Watsen wrote:
> > >> We agree that the diff-format should be client-selectable, modulo
> > >> what the
> > server supports.  yang-patch and edit-config both are viable.  Should
> > we document them both?
> > >>
> > >> That said, since neither edit-config nor yang-patch are diffing
> > >> formats, so
> > much as formats for converting one data tree to another, would it make
> > sense to define an actual diffing format?  I would think that a diff
> > would provide both values, not just a new value.
> > >>
> > >> Kent // contributor
> > >>
> > >>
> > >> -Original Message-
> > >> From: netmod
> > >> mailto:netmod-boun...@ietf.org>> on behalf
> > >> of Ladislav Lhotka mailto:lho...@nic.cz>>
> > >> Organization: CZ.NIC
> > >> Date: Thursday, October 4, 2018 at 1:11 PM
> > >> To: Robert Wilton mailto:rwil...@cisco.com>>,
> > >> "netmod@ietf.org"
> > >> mailto:netmod@ietf.org>>
> > >> Subject: Re: [netmod] WG adoption poll for
> > >> 

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

[Ben Campbell]

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.

§5, last paragraph: Why is the SHOULD NOT not a MUST NOT? Would it ever make
sense to violate this?

§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? If so, it should probably match that of the
containing document.

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.)


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

[netmod] Spencer Dawkins' Yes on draft-ietf-netmod-schema-mount-11: (with COMMENT)

[Spencer Dawkins]

Spencer Dawkins has entered the following ballot position for
draft-ietf-netmod-schema-mount-11: Yes

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:
--

I really like that you've provided this capability.

It might be that I've spent too much time doing Unix, but I wonder if "Yang
Schema Mount Point" would be a clearer title?


___
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

[Andy Bierman]

On Wed, Oct 10, 2018 at 11:44 AM, Michael Rehder 
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 
> > Cc: Robert Wilton ; Ladislav Lhotka ;
> > netmod@ietf.org; Walker, Jason (jason_walk...@comcast.com)
> > 
> > Subject: Re: [netmod] WHEN statement within mandatory objects doesn't
> > ensure presence of the mandatory object
> >
> > Michael,
> >
> > what matters here is what the YANG specification (RFC 7950) says. Is
> there a
> > reason to believe the IPAddresses list in your example can be absent or
> have no
> > elements based on what RFC 7950 says? Or do we talk about a shortcoming
> of
> > RFC 6110?
> >
> > /js
> >
> > On Wed, Oct 10, 2018 at 06:17:26PM +, Michael Rehder wrote:
> > > If the list has a "when" clause the RNG file actually produces a
> "OneOrMore"
> > which has a choice of  or the list so it actually doesn't enforce
> the
> > presence at least one row of the list (unless I'm mistaken in my
> reading).
> > >   
> > > 
> > >   
> > >   
> > > 
> > >   
> > > 
> > > 
> > >   
> > > 
> > >   
> > >
> > > A leaf/container would be a simpler example but would result in the
> same
> > lack of enforcement of the mandatory status of an element with a "when"
> > clause.
> > >
> > > This RNG seems consistent with the Schematron rules that "when" makes
> > something optional.
> > >
> > >
> > > I think a workaround would be choice with mandatory true and a when
> clause
> > on the cases. This would ensure that at least one case is present since
> the
> > mandatory clause implements a Schematron existence constraint.
> > >
> > > Thanks
> > > Mike
> > > > -Original Message-
> > > > From: Robert Wilton [mailto:rwil...@cisco.com]
> > > > Sent: Wednesday, October 10, 2018 11:33 AM
> > > > To: Michael Rehder ; Ladislav Lhotka
> > > > ; netmod@ietf.org
> > > > Cc: Walker, Jason (jason_walk...@comcast.com)
> > > > 
> > > > Subject: Re: [netmod] WHEN statement within mandatory objects
> > > > doesn't ensure presence of the mandatory object
> > > >
> > > > Hi Mike,
> > > >
> > > > I think that the YANG below already enforces what you want, or
> > > > otherwise I don't follow your issue.
> > > >
> > > > The YANG below is valid in two cases:
> > > >
> > > > (1) AssignmentMechanism = DHCP, and IPAddresses is not present in
> > > > the config (due to the when statement).
> > > > (2) AssignmentMechanism = Static, IPAddresses exists and has at
> > > > least one element (due to min-elements 1).
> > > >
> > > > Thanks,
> > > > Rob
> > > >
> > > >
> > > > On 10/10/2018 16:23, Michael Rehder wrote:
> > > > > Container "foo" would be mandatory if not for the "when" child
> element.
> > > > > With the "when" child element, the logic becomes "inverted" and
> > > > > the
> > > > constraint is a negative one of "disallowed under certain condition".
> > > > >
> > > > > The UC is for enforcement in REST API payloads.
> > > > > For a practical example:
> > > > >
> > > > >   leaf AssignmentMechanism {
> > > > >  type enumeration {
> > > > >enum "DHCP";
> > > > >enum "Static";
> > > > >  }
> > > > >  mandatory true;
> > > > >  description "The address assignment mechanism.";
> > > > >}
> > > > >list IPAddresses {
> > > > >  when "../AssignmentMechanism = 'Static'";
> > > > >  key Address;
> > > > >  min-elements 1;
> > > > >
> > > > >  

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

[Michael Rehder]

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.

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 
> Cc: Robert Wilton ; Ladislav Lhotka ;
> netmod@ietf.org; Walker, Jason (jason_walk...@comcast.com)
> 
> Subject: Re: [netmod] WHEN statement within mandatory objects doesn't
> ensure presence of the mandatory object
> 
> Michael,
> 
> what matters here is what the YANG specification (RFC 7950) says. Is there a
> reason to believe the IPAddresses list in your example can be absent or have 
> no
> elements based on what RFC 7950 says? Or do we talk about a shortcoming of
> RFC 6110?
> 
> /js
> 
> On Wed, Oct 10, 2018 at 06:17:26PM +, Michael Rehder wrote:
> > If the list has a "when" clause the RNG file actually produces a "OneOrMore"
> which has a choice of  or the list so it actually doesn't enforce the
> presence at least one row of the list (unless I'm mistaken in my reading).
> >   
> > 
> >   
> >   
> > 
> >   
> > 
> > 
> >   
> > 
> >   
> >
> > A leaf/container would be a simpler example but would result in the same
> lack of enforcement of the mandatory status of an element with a "when"
> clause.
> >
> > This RNG seems consistent with the Schematron rules that "when" makes
> something optional.
> >
> >
> > I think a workaround would be choice with mandatory true and a when clause
> on the cases. This would ensure that at least one case is present since the
> mandatory clause implements a Schematron existence constraint.
> >
> > Thanks
> > Mike
> > > -Original Message-
> > > From: Robert Wilton [mailto:rwil...@cisco.com]
> > > Sent: Wednesday, October 10, 2018 11:33 AM
> > > To: Michael Rehder ; Ladislav Lhotka
> > > ; netmod@ietf.org
> > > Cc: Walker, Jason (jason_walk...@comcast.com)
> > > 
> > > Subject: Re: [netmod] WHEN statement within mandatory objects
> > > doesn't ensure presence of the mandatory object
> > >
> > > Hi Mike,
> > >
> > > I think that the YANG below already enforces what you want, or
> > > otherwise I don't follow your issue.
> > >
> > > The YANG below is valid in two cases:
> > >
> > > (1) AssignmentMechanism = DHCP, and IPAddresses is not present in
> > > the config (due to the when statement).
> > > (2) AssignmentMechanism = Static, IPAddresses exists and has at
> > > least one element (due to min-elements 1).
> > >
> > > Thanks,
> > > Rob
> > >
> > >
> > > On 10/10/2018 16:23, Michael Rehder wrote:
> > > > Container "foo" would be mandatory if not for the "when" child element.
> > > > With the "when" child element, the logic becomes "inverted" and
> > > > the
> > > constraint is a negative one of "disallowed under certain condition".
> > > >
> > > > The UC is for enforcement in REST API payloads.
> > > > For a practical example:
> > > >
> > > >   leaf AssignmentMechanism {
> > > >  type enumeration {
> > > >enum "DHCP";
> > > >enum "Static";
> > > >  }
> > > >  mandatory true;
> > > >  description "The address assignment mechanism.";
> > > >}
> > > >list IPAddresses {
> > > >  when "../AssignmentMechanism = 'Static'";
> > > >  key Address;
> > > >  min-elements 1;
> > > >
> > > >  leaf Address {
> > > >type capit:IPv4Address;
> > > >description "An ipv4 address.";
> > > >  }
> > > > }
> > > >
> > > > There is no way in the IPAddresses list to enforce that there is
> > > > at least one IP
> > > Address when the assignment method is "Static".
> > > > One could put a "must" on "AssignmentMechanism" to ensure at least
> > > > one
> > > element of the IPAddresses list when "Static", but I don't see this
> > > as a good schema design, to have the controlling attribute check 
> > > controlled
> attributes.
> > > >
> > > > I appreciate that this semantic can't be changed in YANG at this point.
> > > > 

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

[Juergen Schoenwaelder]

Michael,

what matters here is what the YANG specification (RFC 7950) says. Is
there a reason to believe the IPAddresses list in your example can be
absent or have no elements based on what RFC 7950 says? Or do we talk
about a shortcoming of RFC 6110?

/js

On Wed, Oct 10, 2018 at 06:17:26PM +, Michael Rehder wrote:
> If the list has a "when" clause the RNG file actually produces a "OneOrMore" 
> which has a choice of  or the list so it actually doesn't enforce the 
> presence at least one row of the list (unless I'm mistaken in my reading).
>   
> 
>   
>   
> 
>   
> 
> 
>   
> 
>   
> 
> A leaf/container would be a simpler example but would result in the same lack 
> of enforcement of the mandatory status of an element with a "when" clause.
> 
> This RNG seems consistent with the Schematron rules that "when" makes 
> something optional.
> 
> 
> I think a workaround would be choice with mandatory true and a when clause on 
> the cases. This would ensure that at least one case is present since the 
> mandatory clause implements a Schematron existence constraint.
> 
> Thanks
> Mike
> > -Original Message-
> > From: Robert Wilton [mailto:rwil...@cisco.com]
> > Sent: Wednesday, October 10, 2018 11:33 AM
> > To: Michael Rehder ; Ladislav Lhotka
> > ; netmod@ietf.org
> > Cc: Walker, Jason (jason_walk...@comcast.com)
> > 
> > Subject: Re: [netmod] WHEN statement within mandatory objects doesn't
> > ensure presence of the mandatory object
> > 
> > Hi Mike,
> > 
> > I think that the YANG below already enforces what you want, or otherwise I
> > don't follow your issue.
> > 
> > The YANG below is valid in two cases:
> > 
> > (1) AssignmentMechanism = DHCP, and IPAddresses is not present in the config
> > (due to the when statement).
> > (2) AssignmentMechanism = Static, IPAddresses exists and has at least one
> > element (due to min-elements 1).
> > 
> > Thanks,
> > Rob
> > 
> > 
> > On 10/10/2018 16:23, Michael Rehder wrote:
> > > Container "foo" would be mandatory if not for the "when" child element.
> > > With the "when" child element, the logic becomes "inverted" and the
> > constraint is a negative one of "disallowed under certain condition".
> > >
> > > The UC is for enforcement in REST API payloads.
> > > For a practical example:
> > >
> > >   leaf AssignmentMechanism {
> > >  type enumeration {
> > >enum "DHCP";
> > >enum "Static";
> > >  }
> > >  mandatory true;
> > >  description "The address assignment mechanism.";
> > >}
> > >list IPAddresses {
> > >  when "../AssignmentMechanism = 'Static'";
> > >  key Address;
> > >  min-elements 1;
> > >
> > >  leaf Address {
> > >type capit:IPv4Address;
> > >description "An ipv4 address.";
> > >  }
> > > }
> > >
> > > There is no way in the IPAddresses list to enforce that there is at least 
> > > one IP
> > Address when the assignment method is "Static".
> > > One could put a "must" on "AssignmentMechanism" to ensure at least one
> > element of the IPAddresses list when "Static", but I don't see this as a 
> > good
> > schema design, to have the controlling attribute check controlled 
> > attributes.
> > >
> > > I appreciate that this semantic can't be changed in YANG at this point.
> > > Could the "when" statement have a modifying child element to state that 
> > > the
> > mandatory status of the element is to be enforced?
> > > Like
> > >  container foo {
> > >when "condition" {
> > >enforce-mandatory-status;
> > >}
> > >
> > > There is already back-end for existential checks for mandatory choice so 
> > > this
> > seems reasonably consistent to me.
> > > I appreciate there are existing issues for "when" but I don't see why this
> > would make things any worse.
> > > In fact by promoting a better dependency "direction" between schema
> > elements,  think it could simplify things (so I naively think :) ).
> > >
> > > Thanks
> > > Mike
> > >> -Original Message-
> > >> From: Ladislav Lhotka [mailto:lho...@nic.cz]
> > >> Sent: Wednesday, October 10, 2018 10:28 AM
> > >> To: Michael Rehder ; netmod@ietf.org
> > >> Subject: Re: [netmod] WHEN statement within mandatory objects doesn't
> > >> ensure presence of the mandatory object
> > >>
> > >> Michael Rehder  writes:
> > >>
> > >>> I have a question about “when” and mandatory objects.
> > >>>
> > >>> It seems to me that the implemented semantics of “when” are really
> > >> “optional when”, in that the enclosing object can be absent even
> > >> though it is mandatory and the “when” clause holds true.
> > >>> The RFC could be clearer about this.
> > >>>
> > >>> Example
> > >>>

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

[Michael Rehder]

If the list has a "when" clause the RNG file actually produces a "OneOrMore" 
which has a choice of  or the list so it actually doesn't enforce the 
presence at least one row of the list (unless I'm mistaken in my reading).
  

  
  

  


  

  

A leaf/container would be a simpler example but would result in the same lack 
of enforcement of the mandatory status of an element with a "when" clause.

This RNG seems consistent with the Schematron rules that "when" makes something 
optional.


I think a workaround would be choice with mandatory true and a when clause on 
the cases. This would ensure that at least one case is present since the 
mandatory clause implements a Schematron existence constraint.

Thanks
Mike
> -Original Message-
> From: Robert Wilton [mailto:rwil...@cisco.com]
> Sent: Wednesday, October 10, 2018 11:33 AM
> To: Michael Rehder ; Ladislav Lhotka
> ; netmod@ietf.org
> Cc: Walker, Jason (jason_walk...@comcast.com)
> 
> Subject: Re: [netmod] WHEN statement within mandatory objects doesn't
> ensure presence of the mandatory object
> 
> Hi Mike,
> 
> I think that the YANG below already enforces what you want, or otherwise I
> don't follow your issue.
> 
> The YANG below is valid in two cases:
> 
> (1) AssignmentMechanism = DHCP, and IPAddresses is not present in the config
> (due to the when statement).
> (2) AssignmentMechanism = Static, IPAddresses exists and has at least one
> element (due to min-elements 1).
> 
> Thanks,
> Rob
> 
> 
> On 10/10/2018 16:23, Michael Rehder wrote:
> > Container "foo" would be mandatory if not for the "when" child element.
> > With the "when" child element, the logic becomes "inverted" and the
> constraint is a negative one of "disallowed under certain condition".
> >
> > The UC is for enforcement in REST API payloads.
> > For a practical example:
> >
> >   leaf AssignmentMechanism {
> >  type enumeration {
> >enum "DHCP";
> >enum "Static";
> >  }
> >  mandatory true;
> >  description "The address assignment mechanism.";
> >}
> >list IPAddresses {
> >  when "../AssignmentMechanism = 'Static'";
> >  key Address;
> >  min-elements 1;
> >
> >  leaf Address {
> >type capit:IPv4Address;
> >description "An ipv4 address.";
> >  }
> > }
> >
> > There is no way in the IPAddresses list to enforce that there is at least 
> > one IP
> Address when the assignment method is "Static".
> > One could put a "must" on "AssignmentMechanism" to ensure at least one
> element of the IPAddresses list when "Static", but I don't see this as a good
> schema design, to have the controlling attribute check controlled attributes.
> >
> > I appreciate that this semantic can't be changed in YANG at this point.
> > Could the "when" statement have a modifying child element to state that the
> mandatory status of the element is to be enforced?
> > Like
> >  container foo {
> >when "condition" {
> >enforce-mandatory-status;
> >}
> >
> > There is already back-end for existential checks for mandatory choice so 
> > this
> seems reasonably consistent to me.
> > I appreciate there are existing issues for "when" but I don't see why this
> would make things any worse.
> > In fact by promoting a better dependency "direction" between schema
> elements,  think it could simplify things (so I naively think :) ).
> >
> > Thanks
> > Mike
> >> -Original Message-
> >> From: Ladislav Lhotka [mailto:lho...@nic.cz]
> >> Sent: Wednesday, October 10, 2018 10:28 AM
> >> To: Michael Rehder ; netmod@ietf.org
> >> Subject: Re: [netmod] WHEN statement within mandatory objects doesn't
> >> ensure presence of the mandatory object
> >>
> >> Michael Rehder  writes:
> >>
> >>> I have a question about “when” and mandatory objects.
> >>>
> >>> It seems to me that the implemented semantics of “when” are really
> >> “optional when”, in that the enclosing object can be absent even
> >> though it is mandatory and the “when” clause holds true.
> >>> The RFC could be clearer about this.
> >>>
> >>> Example
> >>>
> >>> leaf color {
> >>>   enumeration  {
> >>>  enum “blue”;
> >>>  enum “black”;
> >>>   }
> >>>   mandatory true;
> >>> }
> >>> container foo {
> >>>when ../color = ‘blue’;
> >>>etc.
> >>> }
> >>>
> >>> “foo” is optional due to the presence of the “when” statement even
> >>> though the object is mandatory (same is true for mandatory leaf,
> >>> min-elements=1 list etc.).
> >> Maybe you intended to have, e.g., a "mandatory true" leaf inside
> >> "container foo"?
> >>
> >>> This is considered valid XML for the above
> >>>  

Re: [netmod] Eric Rescorla's Discuss on draft-ietf-netmod-schema-mount-11: (with DISCUSS)

[Eric Rescorla]

I'm sorry but I don't understand this.

Does the externally visible behavior of any mounted module depend in any
way on these XPATH references

-Ekr




On Wed, Oct 10, 2018 at 6:38 AM Martin Bjorklund  wrote:

> Eric Rescorla  wrote:
> > On Wed, Oct 10, 2018 at 5:32 AM Martin Bjorklund  wrote:
> >
> > > Hi,
> > >
> > > Eric Rescorla  wrote:
> > > > Eric Rescorla has entered the following ballot position for
> > > > draft-ietf-netmod-schema-mount-11: Discuss
> > > >
> > > > 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/
> > > >
> > > >
> > > >
> > > >
> --
> > > > DISCUSS:
> > > >
> --
> > > >
> > > > Rich version of this review at:
> > > > https://mozphab-ietf.devsvcdev.mozaws.net/D3506
> > > >
> > > >
> > > >
> > > > DETAIL
> > > > S 4.
> > > > >
> > > > >  It is worth emphasizing that the nodes specified in
> > > > >  "parent-reference" leaf-list are available in the mounted
> schema
> > > only
> > > > >  for XPath evaluations.  In particular, they cannot be accessed
> > > there
> > > > >  via network management protocols such as NETCONF [RFC6241] or
> > > > >  RESTCONF [RFC8040].
> > > >
> > > > What are the security implications of this XPath reference outside
> the
> > > > mount jail? Specifically, how does it interact with the access
> control
> > > > for the enclosing module.
> > >
> > > There is no such interaction, since access control comes into play
> > > when some external entity accesses the data through some management
> > > protocol, and the nodes from the "parent-reference" expressions cannot
> > > be accessed via management protocols.
> > >
> > > The last sentence of the quoted paragraph was supposed to make this
> > > clear, but it seems we might need some additional explanation?
> > >
> >
> > Yes, I think so. I guess I'm not clear on what the XPath expressions are
> > for if they
> > can't be accessed via the management protocols. How can they be used?
>
> These are XPath expressions defined in the YANG models themselves,
> such as "must" expressions or "leafrefs".   The description of
> "parent-reference" refer to them as:
>
>[...] XPath
>expressions whose context nodes are defined in the
>mounted schema
>
>
>
> /martin
>
___
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

[Ladislav Lhotka]

On Wed, 2018-10-10 at 15:23 +, Michael Rehder wrote:
> Container "foo" would be mandatory if not for the "when" child element.  
> With the "when" child element, the logic becomes "inverted" and the constraint
> is a negative one of "disallowed under certain condition".
> 
> The UC is for enforcement in REST API payloads. 
> For a practical example:
> 
>  leaf AssignmentMechanism {
> type enumeration {
>   enum "DHCP";
>   enum "Static";
> }
> mandatory true;
> description "The address assignment mechanism.";
>   }
>   list IPAddresses {
> when "../AssignmentMechanism = 'Static'";
> key Address;
> min-elements 1;
> 
> leaf Address {
>   type capit:IPv4Address;
>   description "An ipv4 address.";
> }
>}
> 
> There is no way in the IPAddresses list to enforce that there is at least one
> IP Address when the assignment method is "Static".


Why do you think there is no way? For example, according to sec. 10.28 of RFC
6110, then "min-elements 1" statement is mapped to the RELAX NG pattern



which enforces the presence of at least one entry of IPAddresses.

>From the DSDL point of view, the problem is rather the opposite: at least one
entry will be required during RELAX NG validation even if AssignmentMechanism is
"DHCP".

Lada

> One could put a "must" on "AssignmentMechanism" to ensure at least one element
> of the IPAddresses list when "Static", but I don't see this as a good schema
> design, to have the controlling attribute check controlled attributes.
> 
> I appreciate that this semantic can't be changed in YANG at this point.
> Could the "when" statement have a modifying child element to state that the
> mandatory status of the element is to be enforced?
> Like
> container foo {
>   when "condition" {
>   enforce-mandatory-status;
>   }
> 
> There is already back-end for existential checks for mandatory choice so this
> seems reasonably consistent to me.
> I appreciate there are existing issues for "when" but I don't see why this
> would make things any worse.
> In fact by promoting a better dependency "direction" between schema
> elements,  think it could simplify things (so I naively think :) ).
> 
> Thanks
> Mike
> > -Original Message-
> > From: Ladislav Lhotka [mailto:lho...@nic.cz]
> > Sent: Wednesday, October 10, 2018 10:28 AM
> > To: Michael Rehder ; netmod@ietf.org
> > Subject: Re: [netmod] WHEN statement within mandatory objects doesn't
> > ensure presence of the mandatory object
> > 
> > Michael Rehder  writes:
> > 
> > > I have a question about “when” and mandatory objects.
> > > 
> > > It seems to me that the implemented semantics of “when” are really
> > “optional when”, in that the enclosing object can be absent even though it
> > is
> > mandatory and the “when” clause holds true.
> > > The RFC could be clearer about this.
> > > 
> > > Example
> > > 
> > >leaf color {
> > >  enumeration  {
> > > enum “blue”;
> > > enum “black”;
> > >  }
> > >  mandatory true;
> > >}
> > >container foo {
> > >   when ../color = ‘blue’;
> > >   etc.
> > >}
> > > 
> > > “foo” is optional due to the presence of the “when” statement even
> > > though the object is mandatory (same is true for mandatory leaf,
> > > min-elements=1 list etc.).
> > 
> > Maybe you intended to have, e.g., a "mandatory true" leaf inside "container
> > foo"?
> > 
> > > This is considered valid XML for the above
> > > blue
> > 
> > Yes, it is, under current YANG rules, no matter what "etc." stands for. Note
> > that
> > evaluation of the XPath expression in this case (with "foo" missing)
> > requires the
> > peculiar procedure of sec. 7.21.5 in RFC 7950.
> > 
> > > In my view this makes conditionally variant schemas “loose” in their
> > > enforcement (some scenarios can use choice but it doesn’t cover
> > > everything).
> > > 
> > > I think that mandatory should be respected for the enclosing objects
> > > of a “when” statement.  That is, a mandatory object must be present
> > > when its “when” clause holds true and a Schematron statement should
> > > enforce that.
> > 
> > In fact, this is one case where the DSDL mapping (RFC 6110) deviates from
> > YANG 1.0. Nodes that mandatory aren't enclosed in the RELAX NG 
> > pattern, and are then required no matter what any "when"
> > statements say (because RELAX NG validation comes before Schematron).
> > 
> > > What is the rationale behind the current YANG rules behavior, that the
> > > “when” Schematron mapping doesn’t check for presence of the enclosing
> > > mandatory object?
> > 
> > FWIW, I have been repeatedly protesting against this behaviour but without
> > much luck. See for example
> > 
> > https://www.ietf.org/mail-archive/web/netmod/current/msg14012.html
> > 
> > As a result, "when" is the 

Re: [netmod] [Gen-art] Genart telechat review of draft-ietf-netmod-schema-mount-11

[Alissa Cooper]

Joel, thanks for your reviews. Martin, thanks for your responses. I entered a 
No Objection ballot.

I do think the new text in Section 1 helps clarify the scope of the server’s 
responsibility (for me, at least).

Alissa

> On Oct 4, 2018, at 8:35 AM, Joel M. Halpern  wrote:
> 
> I had thought we had discussed sufficient edits.  When I looked at the diff, 
> what I saw helped some, but still left me concerned.
> Yours,
> Joel
> 
> On 10/4/18 6:06 AM, Martin Bjorklund wrote:
>> Hi,
>> Joel Halpern  wrote:
>>> Reviewer: Joel Halpern
>>> Review result: Ready with Issues
>>> 
>>> I am the assigned Gen-ART reviewer for this draft. The General Area
>>> Review Team (Gen-ART) reviews all IETF documents being processed
>>> by the IESG for the IETF Chair. Please wait for direction from your
>>> document shepherd or AD before posting a new version of the draft.
>>> 
>>> For more information, please see the FAQ at
>>> 
>>> .
>>> 
>>> Document: draft-ietf-netmod-schema-mount-??
>>> Reviewer: Joel Halpern
>>> Review Date: 2018-10-03
>>> IETF LC End Date: 2018-06-29
>>> IESG Telechat date: 2018-10-11
>>> 
>>> Summary: This document seems to meet the specific requirements for 
>>> publication
>>> as a proposed standard.
>>> 
>>> Major issues:
>>> It is still this reviewer's opinion that for a reader who has not been
>>> involved in the discussion in the working group, the document is quite
>>> unclear and confusing.   For somewhat more details, please see my 
>>> previous
>>> review at
>>> 
>>> https://datatracker.ietf.org/doc/review-ietf-netmod-schema-mount-10-genart-lc-halpern-2018-06-28/
>> I'm sorry to hear that you find it confusing.  I was under the
>> impression that the edits that we made after your previous review were
>> sufficient.
>> /martin
>>> 
>>> Minor issues:
>>> N/A
>>> 
>>> Nits/editorial comments:
>>> N/A
>>> 
>>> 
>>> ___
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>>> 
> 
> ___
> Gen-art mailing list
> gen-...@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art

___
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

[Robert Wilton]

Hi Mike,

I think that the YANG below already enforces what you want, or otherwise 
I don't follow your issue.


The YANG below is valid in two cases:

(1) AssignmentMechanism = DHCP, and IPAddresses is not present in the 
config (due to the when statement).
(2) AssignmentMechanism = Static, IPAddresses exists and has at least 
one element (due to min-elements 1).


Thanks,
Rob


On 10/10/2018 16:23, Michael Rehder wrote:

Container "foo" would be mandatory if not for the "when" child element.
With the "when" child element, the logic becomes "inverted" and the constraint is a 
negative one of "disallowed under certain condition".

The UC is for enforcement in REST API payloads.
For a practical example:

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

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

There is no way in the IPAddresses list to enforce that there is at least one IP Address 
when the assignment method is "Static".
One could put a "must" on "AssignmentMechanism" to ensure at least one element of the 
IPAddresses list when "Static", but I don't see this as a good schema design, to have the 
controlling attribute check controlled attributes.

I appreciate that this semantic can't be changed in YANG at this point.
Could the "when" statement have a modifying child element to state that the 
mandatory status of the element is to be enforced?
Like
 container foo {
   when "condition" {
   enforce-mandatory-status;
   }

There is already back-end for existential checks for mandatory choice so this 
seems reasonably consistent to me.
I appreciate there are existing issues for "when" but I don't see why this 
would make things any worse.
In fact by promoting a better dependency "direction" between schema elements,  
think it could simplify things (so I naively think :) ).

Thanks
Mike

-Original Message-
From: Ladislav Lhotka [mailto:lho...@nic.cz]
Sent: Wednesday, October 10, 2018 10:28 AM
To: Michael Rehder ; netmod@ietf.org
Subject: Re: [netmod] WHEN statement within mandatory objects doesn't
ensure presence of the mandatory object

Michael Rehder  writes:


I have a question about “when” and mandatory objects.

It seems to me that the implemented semantics of “when” are really

“optional when”, in that the enclosing object can be absent even though it is
mandatory and the “when” clause holds true.

The RFC could be clearer about this.

Example

leaf color {
  enumeration  {
 enum “blue”;
 enum “black”;
  }
  mandatory true;
}
container foo {
   when ../color = ‘blue’;
   etc.
}

“foo” is optional due to the presence of the “when” statement even
though the object is mandatory (same is true for mandatory leaf,
min-elements=1 list etc.).

Maybe you intended to have, e.g., a "mandatory true" leaf inside "container
foo"?


This is considered valid XML for the above
 blue

Yes, it is, under current YANG rules, no matter what "etc." stands for. Note 
that
evaluation of the XPath expression in this case (with "foo" missing) requires 
the
peculiar procedure of sec. 7.21.5 in RFC 7950.


In my view this makes conditionally variant schemas “loose” in their
enforcement (some scenarios can use choice but it doesn’t cover
everything).

I think that mandatory should be respected for the enclosing objects
of a “when” statement.  That is, a mandatory object must be present
when its “when” clause holds true and a Schematron statement should
enforce that.

In fact, this is one case where the DSDL mapping (RFC 6110) deviates from
YANG 1.0. Nodes that mandatory aren't enclosed in the RELAX NG 
pattern, and are then required no matter what any "when"
statements say (because RELAX NG validation comes before Schematron).


What is the rationale behind the current YANG rules behavior, that the
“when” Schematron mapping doesn’t check for presence of the enclosing
mandatory object?

FWIW, I have been repeatedly protesting against this behaviour but without
much luck. See for example

https://www.ietf.org/mail-archive/web/netmod/current/msg14012.html

As a result, "when" is the trickiest feature in YANG by far.

Lada


thanks
Mike Rehder

--
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

“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 

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

[Michael Rehder]

Container "foo" would be mandatory if not for the "when" child element.  
With the "when" child element, the logic becomes "inverted" and the constraint 
is a negative one of "disallowed under certain condition".

The UC is for enforcement in REST API payloads. 
For a practical example:

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

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

There is no way in the IPAddresses list to enforce that there is at least one 
IP Address when the assignment method is "Static".
One could put a "must" on "AssignmentMechanism" to ensure at least one element 
of the IPAddresses list when "Static", but I don't see this as a good schema 
design, to have the controlling attribute check controlled attributes.

I appreciate that this semantic can't be changed in YANG at this point.
Could the "when" statement have a modifying child element to state that the 
mandatory status of the element is to be enforced?
Like
container foo {
  when "condition" {
  enforce-mandatory-status;
  }

There is already back-end for existential checks for mandatory choice so this 
seems reasonably consistent to me.
I appreciate there are existing issues for "when" but I don't see why this 
would make things any worse.
In fact by promoting a better dependency "direction" between schema elements,  
think it could simplify things (so I naively think :) ).

Thanks
Mike
> -Original Message-
> From: Ladislav Lhotka [mailto:lho...@nic.cz]
> Sent: Wednesday, October 10, 2018 10:28 AM
> To: Michael Rehder ; netmod@ietf.org
> Subject: Re: [netmod] WHEN statement within mandatory objects doesn't
> ensure presence of the mandatory object
> 
> Michael Rehder  writes:
> 
> > I have a question about “when” and mandatory objects.
> >
> > It seems to me that the implemented semantics of “when” are really
> “optional when”, in that the enclosing object can be absent even though it is
> mandatory and the “when” clause holds true.
> > The RFC could be clearer about this.
> >
> > Example
> >
> >leaf color {
> >  enumeration  {
> > enum “blue”;
> > enum “black”;
> >  }
> >  mandatory true;
> >}
> >container foo {
> >   when ../color = ‘blue’;
> >   etc.
> >}
> >
> > “foo” is optional due to the presence of the “when” statement even
> > though the object is mandatory (same is true for mandatory leaf,
> > min-elements=1 list etc.).
> 
> Maybe you intended to have, e.g., a "mandatory true" leaf inside "container
> foo"?
> 
> > This is considered valid XML for the above
> > blue
> 
> Yes, it is, under current YANG rules, no matter what "etc." stands for. Note 
> that
> evaluation of the XPath expression in this case (with "foo" missing) requires 
> the
> peculiar procedure of sec. 7.21.5 in RFC 7950.
> 
> >
> > In my view this makes conditionally variant schemas “loose” in their
> > enforcement (some scenarios can use choice but it doesn’t cover
> > everything).
> >
> > I think that mandatory should be respected for the enclosing objects
> > of a “when” statement.  That is, a mandatory object must be present
> > when its “when” clause holds true and a Schematron statement should
> > enforce that.
> 
> In fact, this is one case where the DSDL mapping (RFC 6110) deviates from
> YANG 1.0. Nodes that mandatory aren't enclosed in the RELAX NG 
> pattern, and are then required no matter what any "when"
> statements say (because RELAX NG validation comes before Schematron).
> 
> >
> > What is the rationale behind the current YANG rules behavior, that the
> > “when” Schematron mapping doesn’t check for presence of the enclosing
> > mandatory object?
> 
> FWIW, I have been repeatedly protesting against this behaviour but without
> much luck. See for example
> 
> https://www.ietf.org/mail-archive/web/netmod/current/msg14012.html
> 
> As a result, "when" is the trickiest feature in YANG by far.
> 
> Lada
> 
> >
> > thanks
> > Mike Rehder
> 
> --
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
“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

[Ladislav Lhotka]

Michael Rehder  writes:

> I have a question about “when” and mandatory objects.
>
> It seems to me that the implemented semantics of “when” are really “optional 
> when”, in that the enclosing object can be absent even though it is mandatory 
> and the “when” clause holds true.
> The RFC could be clearer about this.
>
> Example
>
>leaf color {
>  enumeration  {
> enum “blue”;
> enum “black”;
>  }
>  mandatory true;
>}
>container foo {
>   when ../color = ‘blue’;
>   etc.
>}
>
> “foo” is optional due to the presence of the “when” statement even
> though the object is mandatory (same is true for mandatory leaf,
> min-elements=1 list etc.).

Maybe you intended to have, e.g., a "mandatory true" leaf inside
"container foo"?

> This is considered valid XML for the above
> blue

Yes, it is, under current YANG rules, no matter what "etc." stands
for. Note that evaluation of the XPath expression in this case (with
"foo" missing) requires the peculiar procedure of sec. 7.21.5 in RFC
7950.

>
> In my view this makes conditionally variant schemas “loose” in their
> enforcement (some scenarios can use choice but it doesn’t cover
> everything).
>
> I think that mandatory should be respected for the enclosing objects
> of a “when” statement.  That is, a mandatory object must be present
> when its “when” clause holds true and a Schematron statement should
> enforce that.

In fact, this is one case where the DSDL mapping (RFC 6110) deviates
from YANG 1.0. Nodes that mandatory aren't enclosed in the RELAX NG
 pattern, and are then required no matter what any "when"
statements say (because RELAX NG validation comes before Schematron).  

>
> What is the rationale behind the current YANG rules behavior, that the
> “when” Schematron mapping doesn’t check for presence of the enclosing
> mandatory object?

FWIW, I have been repeatedly protesting against this behaviour but
without much luck. See for example

https://www.ietf.org/mail-archive/web/netmod/current/msg14012.html

As a result, "when" is the trickiest feature in YANG by far.

Lada

>
> thanks
> Mike Rehder

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

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

Re: [netmod] xpath expressions in JSON

[Martin Bjorklund]

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.

Hmm, so you mean change the leaf "stream-xpath-filter" to say:

 o  The set of namespace declarations has one member for each
YANG module supported by the server.  This member maps
from the YANG module name to the YANG module namespace.

This means that in the XPath expression, the module name
serves as the prefix.

 and then also give an example of this.

This is probably what we need to do in all places where yang:xpath1.0
is used, going forward.  Maybe even define a new type
yang:xpath1.0-2 (name?) with the set of namespace declarations
built-in.


/martin





> 
> Lada
> 
> >
> > How is this supposed to work with JSON?
> >
> >
> > /martin
> >
> > ___
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> 
> -- 
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
> 

___
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

[Sterne, Jason (Nokia - CA/Ottawa)]

Hi Mike,
Please see below.
Jason

From: netmod  On Behalf Of Michael Rehder
Sent: Tuesday, October 9, 2018 1:51 PM
To: netmod@ietf.org
Subject: [netmod] WHEN statement within mandatory objects doesn't ensure 
presence of the mandatory object

I have a question about “when” and mandatory objects.

It seems to me that the implemented semantics of “when” are really “optional 
when”, in that the enclosing object can be absent even though it is mandatory 
and the “when” clause holds true.
The RFC could be clearer about this.

Example

   leaf color {
 enumeration  {
enum “blue”;
enum “black”;
 }
 mandatory true;
   }
   container foo {
  when ../color = ‘blue’;
  etc.
   }

“foo” is optional due to the presence of the “when” statement even though the 
object is mandatory (same is true for mandatory leaf, min-elements=1 list etc.).
[>>JTS: ]  What do you mean by "the object is mandatory" ?  I see that leaf 
color is mandatory (so it must have a value of either black or blue).  But the 
container foo is not mandatory.

This is considered valid XML for the above
blue

In my view this makes conditionally variant schemas “loose” in their 
enforcement (some scenarios can use choice but it doesn’t cover everything).

I think that mandatory should be respected for the enclosing objects of a 
“when” statement.
That is, a mandatory object must be present when its “when” clause holds true 
and a Schematron statement should enforce that.
[>>JTS: ] We can't change that definition now. I don't know all the details of 
the rationale but "when" is defined such that its parent data definition 
statement is only valid when the condition in the "when" is true. But that 
doesn't mean that parent node is mandatory. In other words -> a "when" can only 
remove a node (from the schema), it can't enforce that a node exists (in 
instance data).

What is the rationale behind the current YANG rules behavior, that the “when” 
Schematron mapping doesn’t check for presence of the enclosing mandatory object?

thanks
Mike Rehder


“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] Eric Rescorla's Discuss on draft-ietf-netmod-schema-mount-11: (with DISCUSS)

[Martin Bjorklund]

Eric Rescorla  wrote:
> On Wed, Oct 10, 2018 at 5:32 AM Martin Bjorklund  wrote:
> 
> > Hi,
> >
> > Eric Rescorla  wrote:
> > > Eric Rescorla has entered the following ballot position for
> > > draft-ietf-netmod-schema-mount-11: Discuss
> > >
> > > 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/
> > >
> > >
> > >
> > > --
> > > DISCUSS:
> > > --
> > >
> > > Rich version of this review at:
> > > https://mozphab-ietf.devsvcdev.mozaws.net/D3506
> > >
> > >
> > >
> > > DETAIL
> > > S 4.
> > > >
> > > >  It is worth emphasizing that the nodes specified in
> > > >  "parent-reference" leaf-list are available in the mounted schema
> > only
> > > >  for XPath evaluations.  In particular, they cannot be accessed
> > there
> > > >  via network management protocols such as NETCONF [RFC6241] or
> > > >  RESTCONF [RFC8040].
> > >
> > > What are the security implications of this XPath reference outside the
> > > mount jail? Specifically, how does it interact with the access control
> > > for the enclosing module.
> >
> > There is no such interaction, since access control comes into play
> > when some external entity accesses the data through some management
> > protocol, and the nodes from the "parent-reference" expressions cannot
> > be accessed via management protocols.
> >
> > The last sentence of the quoted paragraph was supposed to make this
> > clear, but it seems we might need some additional explanation?
> >
> 
> Yes, I think so. I guess I'm not clear on what the XPath expressions are
> for if they
> can't be accessed via the management protocols. How can they be used?

These are XPath expressions defined in the YANG models themselves,
such as "must" expressions or "leafrefs".   The description of
"parent-reference" refer to them as:

   [...] XPath
   expressions whose context nodes are defined in the
   mounted schema



/martin

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

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

[Martin Bjorklund]

Hi,

Benjamin Kaduk  wrote:
> Benjamin Kaduk 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:
> --
> 
> Whenever we introduce a new namespace "sub-hierarchy" there is some level
> of risk about surpirses with respect to the security properties of the
> combined system.  I appreciate that the mounted schemas are "jailed" into
> their own subtree except for the specific exceptions for XPath access,
> which helps a lot.  But there may still be potential for surprise with
> respect to, e.g., access control on mounted schemas, if an administrator
> previously assumed that such controls would only be needed at the
> top-level.  The document itself doesn't give me a great picture of to what
> extent these risks and the possible consequences of the new nested
> structure have been considered; I'd be happy to hear if they've been
> thought about a lot already and the conclusion was that the situation is so
> boring that nothing needs to be mentioned in the document.

The intention was that this is covered in Section 7, Interaction with
the Network Configuration Access Control Model (NACM).

But it is probably a good idea to explicitly mention this in the
Security Considerations section as well (together with your last point
below).  So maybe add a paragraph at the end of Section 11:

  It is important to take the security considerations for all nodes in
  the mounted schemas into account, and control access to these nodes
  by using the mechanism described in Section 7.
  
> Section 3.3
> 
>If multiple mount points with the same name are defined in the same
>module - either directly or because the mount point is defined in a
>grouping and the grouping is used multiple times - then the
>corresponding "mount-point" entry applies equally to all such mount
>points.
> 
> Does this mean that the multiple mount points must serve the same
> data/contents, or just that they must use the same schema?
> (Is this related to "inline" vs. "shared-schema"?)

No, this document intentionally doesn't assume anything about the
source of the instance data (as explained in section 1).  So the
answer is that they just use the same schema.

> Section 3.4
> 
> So this means that there can be multiple
> ietf-yang-schema-mount:schema-mounts:mount-point nodes at different
> locations in the hierarchy?  When I was first reading the document, the
> design seemed fairly clean with just a single list of mount-points at the
> "top-level" that tracks everything, but this kind of recursion seems like
> it would make implementation potentially quite complex.  What kind of
> implementation experience do we have that can replace my half-informed
> suppositions about complexity?

I agree with you that multiple levels of mounting probably can be
complex.  But there is nothing in the design of schema mount that
prohibits this.  In fact, it "falls out for free" from the design.

A 2-level example is a physical device with LNEs
(draft-ietf-rtgwg-lne-model) which has NIs
(draft-ietf-rtgwg-ni-model).

> Section 4
> 
>Therefore, schema mount also allows for such references.  For every
>mount point in the "shared-schema" case, it is possible to specify a
>leaf-list named "parent-reference" that contains zero or more XPath
>1.0 expressions.  [...]
> 
> editorial: """the "shared-schema" case""" reads oddly to me; it might be
> clearer to refer to schemas mounted using "shared-schema" instead.  As in,
> """For every mount point under "shared-schema", [...]"""

We use the wording "in the 'shared-schema' case" in a couple of
places.  I don't think "mount point under 'shared-schema'" is
correct.

> Can we get a reference added for XPath?

Sure, I will add this.

> It's still a little unclear to me exactly how a node in the mounted tree
> constructs an XPath expression to refer to the parent-reference
> nodes

It's rather the other way around.  If a node in the mounted schema has
an XPath expression that refers to a node that is not part of the
jailed mounted schema, that node can be brought in by the
parent-reference expressions.   An example of this is given in A.3
where an "outgoing-interface" (which is a reference to
/if:interfaces/if:interface/if:name) works thanks to the
parent-reference.

>, but
> I did not read very far down the reference chain and 

Re: [netmod] Eric Rescorla's Discuss on draft-ietf-netmod-schema-mount-11: (with DISCUSS)

[Eric Rescorla]

On Wed, Oct 10, 2018 at 5:32 AM Martin Bjorklund  wrote:

> Hi,
>
> Eric Rescorla  wrote:
> > Eric Rescorla has entered the following ballot position for
> > draft-ietf-netmod-schema-mount-11: Discuss
> >
> > 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/
> >
> >
> >
> > --
> > DISCUSS:
> > --
> >
> > Rich version of this review at:
> > https://mozphab-ietf.devsvcdev.mozaws.net/D3506
> >
> >
> >
> > DETAIL
> > S 4.
> > >
> > >  It is worth emphasizing that the nodes specified in
> > >  "parent-reference" leaf-list are available in the mounted schema
> only
> > >  for XPath evaluations.  In particular, they cannot be accessed
> there
> > >  via network management protocols such as NETCONF [RFC6241] or
> > >  RESTCONF [RFC8040].
> >
> > What are the security implications of this XPath reference outside the
> > mount jail? Specifically, how does it interact with the access control
> > for the enclosing module.
>
> There is no such interaction, since access control comes into play
> when some external entity accesses the data through some management
> protocol, and the nodes from the "parent-reference" expressions cannot
> be accessed via management protocols.
>
> The last sentence of the quoted paragraph was supposed to make this
> clear, but it seems we might need some additional explanation?
>

Yes, I think so. I guess I'm not clear on what the XPath expressions are
for if they
can't be accessed via the management protocols. How can they be used?

-Ekr


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

Re: [netmod] xpath expressions in JSON

[Ladislav Lhotka]

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.

Lada

>
> How is this supposed to work with JSON?
>
>
> /martin
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

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

Re: [netmod] Eric Rescorla's Discuss on draft-ietf-netmod-schema-mount-11: (with DISCUSS)

[Martin Bjorklund]

Hi,

Eric Rescorla  wrote:
> Eric Rescorla has entered the following ballot position for
> draft-ietf-netmod-schema-mount-11: Discuss
> 
> 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/
> 
> 
> 
> --
> DISCUSS:
> --
> 
> Rich version of this review at:
> https://mozphab-ietf.devsvcdev.mozaws.net/D3506
> 
> 
> 
> DETAIL
> S 4.
> >   
> >  It is worth emphasizing that the nodes specified in
> >  "parent-reference" leaf-list are available in the mounted schema only
> >  for XPath evaluations.  In particular, they cannot be accessed there
> >  via network management protocols such as NETCONF [RFC6241] or
> >  RESTCONF [RFC8040].
> 
> What are the security implications of this XPath reference outside the
> mount jail? Specifically, how does it interact with the access control
> for the enclosing module.

There is no such interaction, since access control comes into play
when some external entity accesses the data through some management
protocol, and the nodes from the "parent-reference" expressions cannot
be accessed via management protocols.

The last sentence of the quoted paragraph was supposed to make this
clear, but it seems we might need some additional explanation?



/martin

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

[netmod] xpath expressions in JSON

[Martin Bjorklund]

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.

How is this supposed to work with JSON?


/martin

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

Re: [netmod] Place to download Standard YANG Modules ?

[Jernej Tuljak]

Martin Bjorklund je 10/8/2018 ob 2:53 PM napisal:

Hi,


Balazs Lengyel  wrote:

Hello,

What is the best way to download standard Yang Modules? I know the
official answer is to download all the standards then extract the
modules, however this is a "bit" cumbersome. Is there any better way?
We had a git earlier. How up to date is that?

You can download them from IANA:

https://www.iana.org/assignments/yang-parameters/yang-parameters.xhtml

But there are two problems:

  1) you have to download one at the time
  2) some of them have lost all indentation
 (e.g. 
https://www.iana.org/assignments/yang-parameters/ietf-vouc...@2018-04-06.yang)


[on 2), I have it on my list to talk to them]



If you do talk to them, also mention that 
"ietf-network-topology-st...@2018-02-26.yang" in their list is actually 
just "ietf-network-topol...@2018-02-26.yang" renamed, and that 
"ietf-vouc...@2018-04-06.yang" does not have the same revision as the 
module that is part of RFC8366 (2018-05-09). Also, in at least two 
instances, I managed to somehow download a blank module file, which then 
magically downloaded properly after a retry.


Benoit went through the trouble of gathering modules from different 
sources and his blog entry includes standard modules [1]. I dare say 
that this blog entry is a much more reliable source compared to the IANA 
site.


[1] - https://www.claise.be/2018/06/ietf-yang-modules-statistiques/


Or you can get them from some 3rd party place like yang-catalog, or
pyang.



Pyang git repo has the files without revisions in their name, which is 
somewhat awkward.


Jernej



/martin



It would be wonderful if this could be described in the Netmod WG
wiki.

(And sorry, no but I am not volunteering :-(   )

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


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

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

[Ladislav Lhotka]

On Tue, 2018-10-09 at 17:24 +, Kent Watsen wrote:
> As Martin points out, this is how XML works.
> 
> As a result, XML instance documents are poster-child examples for why long
> lines occur sometimes, and where the artwork-folding draft shines when placing
> said examples into drafts.
> 
> Lada, good point, but would there be a layer violation?

Which layers do you mean? XML and YANG parser on top of it? An XML processor is
expected to pass the whitespace unchanged to the application (except for EOL
normalization), and it is up to the YANG parser how the data is interpreted.

Lada

> 
> Kent // contributor
> 
> 
> 
> 
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

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