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

[Mahesh Jethanandani]

> On Oct 11, 2018, at 8:04 AM, Martin Bjorklund  wrote:
> 
> Mahesh Jethanandani  wrote:
>> 
>> 
>>> On Oct 10, 2018, at 11:51 PM, Martin Bjorklund  wrote:
>>> 
>>> I just which there was a one-click way (or better some repo) to get
>>> all files.
>> 
>> There is. Benoit had written it, but for the life of me I cannot
>> remember what it is called.
> 
> I meant from IANA.  3rd party mirrored repos are fine, but it would be
> nice to get them directly from IANA in a simple way.

Ok. Here is the process.

You can get the entire IANA repository by doing this:

rsync -avzH rsync.iana.org ::assignments std/iana

But if you care just about the YANG models in the IANA repository, do this:

rsync -avz --delete rsync.ietf.org::iana/yang-parameters .

> 
> 
> /martin

Mahesh Jethanandani
mjethanand...@gmail.com



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

[Benjamin Kaduk]

On Wed, Oct 10, 2018 at 03:35:28PM +0200, Martin Bjorklund wrote:
> 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.

I guess this addresses my concern; thanks.

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

Okay.

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

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

[Andy Bierman]

On Thu, Oct 11, 2018 at 11:14 AM, Michael Rehder 
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 
> *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:00 AM, Michael Rehder <
> 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 
> *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 Wed, Oct 10, 2018 at 11:44 AM, Michael Rehder <
> 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 
> > 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 

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

[Kent Watsen]

Yes, it would be good to be clear on the use cases.

It is not my intention for support human interaction, though that may occur.

The  primary question I’m hoping this work supports is “how do two datastores
differ?”, which I view as needing to return either, perhaps based on a client-
selectable parameter:

  1.  a list of xpaths where diffs occur or
  2.  a list of xpaths where diffs occur *and* both values for each diff

How the diff is consumed and, in particular, if it leads to an configuration
operation that intends to align one datastore to the other, is be a secondary
consideration IMO.

Kent // contributor

On 10/10/18, 10:20 PM, "Andy Bierman" 
mailto:a...@yumaworks.com>> wrote:



On Wed, Oct 10, 2018 at 6:39 PM, Kent Watsen 
mailto:kwat...@juniper.net>> 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 
mailto:alexander.cl...@huawei.com>>
Date: Wednesday, October 10, 2018 at 6:06 PM
To: Kent Watsen mailto:kwat...@juniper.net>>, Ladislav 
Lhotka mailto:lho...@nic.cz>>, Andy Bierman 
mailto:a...@yumaworks.com>>, Juergen Schoenwaelder 
mailto:j.schoenwael...@jacobs-university.de>>,
 "netmod@ietf.org" 
mailto: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 
> mailto:alexander.cl...@huawei.com>>; Ladislav 
> Lhotka
> mailto:lho...@nic.cz>>; Andy Bierman 
> mailto:a...@yumaworks.com>>; Juergen
> Schoenwaelder 
> mailto:j.schoenwael...@jacobs-university.de>>;
>  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 
> mailto:alexander.cl...@huawei.com>>
> Date: Monday, October 8, 2018 at 5:05 PM
> To: Ladislav Lhotka mailto:lho...@nic.cz>>, Kent Watsen 
> mailto:kwat...@juniper.net>>,
> Andy Bierman mailto:a...@yumaworks.com>>, Juergen 
> Schoenwaelder
> mailto:j.schoenwael...@jacobs-university.de>>,
>  "netmod@ietf.org"
> mailto: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 mailto:kwat...@juniper.net>>; Andy 
> > Bierman
> > mailto:a...@yumaworks.com>>; Juergen Schoenwaelder 
> >  > university.de>;
> >  netmod@ietf.org
> > Subject: Re: [netmod] WG adoption poll for
> > draft-clemm-netmod-nmda-diff-00
> >
> > Kent Watsen mailto:kwat...@juniper.net>> writes:
> >
> > > Sure, one mandatory to implement format, others nice to have.
> > > Interoperability good.  Agreed.
> > >
> > > 

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

[Michael Rehder]

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)

Thanks
Mike

From: Andy Bierman [mailto:a...@yumaworks.com]
Sent: Thursday, October 11, 2018 2:06 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: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 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 

Re: [netmod] xpath expressions in JSON

[Reshad Rahman (rrahman)]

Hi Rob,


From: "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" 
Date: Thursday, October 11, 2018 at 11:56 AM
To: "Reshad Rahman (rrahman)" 
Cc: Martin Bjorklund , "netmod@ietf.org" 
Subject: Re: [netmod] xpath expressions in JSON




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


 Section 8.3.6 of which document?
RFC 8040.

 B.3.6, got it. Was looking for 8.3.6, that’s why didn’t find it.

Regards,
Reshad.


Thanks,
Rob



Regards,
Reshad.

Thanks,
Rob











/martin







Thanks,

Rob





There is no standard XPath implementation that can just take an XML

instance document + YANG module and figure out what to do.  Custom

code is needed to connect things together.  This proposal doesn't

change this.





/martin





A normal XPath implementation will not find any namespace mapping for

the

prefixes.



An XPath expression has no concept of the "current module" inherited

from

the parent

like the JSON encoding. This is problematic for predicates



/ietf-interfaces:interfaces/interface[name='eth0']



XPath says the missing prefixes for 'interface' and 'name' are simply

missing (no namespace).

The JSON encoding says "ietf-interfaces" is used for 'interfaces'. and

'interface'.

There is no specification for the 'name' node inside a predicate.



So you must mean the full module name will be used at every node:



  
/ietf-interfaces:interfaces/ietf-interfaces:interface[ietf-interfaces:name='eth0']







/martin





Andy





 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

..



.







___
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 Thu, Oct 11, 2018 at 11:00 AM, Michael Rehder 
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 
> *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 Wed, Oct 10, 2018 at 11:44 AM, Michael Rehder <
> 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 
> > 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 

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

[Michael Rehder]

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

Thanks
Mike

From: Andy Bierman [mailto:a...@yumaworks.com]
Sent: Wednesday, October 10, 2018 2:52 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 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 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 
> > > mailto:michael.reh...@amdocs.com>>; Ladislav 
> > > Lhotka
> > > mailto:lho...@nic.cz>>; 
> > > netmod@ietf.org
> > > Cc: 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
> > >
> > > 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).
> 

Re: [netmod] xpath expressions in JSON

[Andy Bierman]

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

The WG is on the right track already wrt/ XPath by creating custom XPath
functions
like 'deref' that simplify syntax or extend functionality.



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

[Robert Wilton]

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 another Xpath format to YANG.

I agree that it is very verbose.  But do not mix XPath expressions in
leaf values (which is what this thread is about) with

Re: [netmod] xpath expressions in JSON

[Andy Bierman]

On Thu, Oct 11, 2018 at 9:16 AM, Martin Bjorklund  wrote:

> Robert Wilton  wrote:
> > Hi Reshad,
> >
> > Please see RW: inline.
> >
> >
> > On 11/10/2018 16:34, Reshad Rahman (rrahman) wrote:
> > >
> > > Hi Rob,
> > >
> > > *From: *netmod  on behalf of "Robert Wilton
> -X
> > > *(rwilton - ENSOFT LIMITED at Cisco)" 
> > > *Date: *Thursday, October 11, 2018 at 7:17 AM
> > > *To: *Martin Bjorklund 
> > > *Cc: *"netmod@ietf.org" 
> > > *Subject: *Re: [netmod] xpath expressions in JSON
> > >
> > > 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 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 

Re: [netmod] xpath expressions in JSON

[Martin Bjorklund]

Robert Wilton  wrote:
> Hi Reshad,
> 
> Please see RW: inline.
> 
> 
> On 11/10/2018 16:34, Reshad Rahman (rrahman) wrote:
> >
> > Hi Rob,
> >
> > *From: *netmod  on behalf of "Robert Wilton -X
> > *(rwilton - ENSOFT LIMITED at Cisco)" 
> > *Date: *Thursday, October 11, 2018 at 7:17 AM
> > *To: *Martin Bjorklund 
> > *Cc: *"netmod@ietf.org" 
> > *Subject: *Re: [netmod] xpath expressions in JSON
> >
> > 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.orgon
> > 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
> >
> > 

Re: [netmod] xpath expressions in JSON

[Martin Bjorklund]

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.

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

Re: [netmod] xpath expressions in JSON

[Robert Wilton]

Hi Reshad,

Please see RW: inline.


On 11/10/2018 16:34, Reshad Rahman (rrahman) wrote:


Hi Rob,

*From: *netmod  on behalf of "Robert Wilton 
-X (rwilton - ENSOFT LIMITED at Cisco)" 

*Date: *Thursday, October 11, 2018 at 7:17 AM
*To: *Martin Bjorklund 
*Cc: *"netmod@ietf.org" 
*Subject: *Re: [netmod] xpath expressions in JSON

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

Re: [netmod] xpath expressions in JSON

[Reshad Rahman (rrahman)]

Hi Rob,

From: netmod  on behalf of "Robert Wilton -X (rwilton 
- ENSOFT LIMITED at Cisco)" 
Date: Thursday, October 11, 2018 at 7:17 AM
To: Martin Bjorklund 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] xpath expressions in JSON




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"?





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 another Xpath format to YANG.
 I’m willing to live with verbosity if it avoids the need of another format.

Finally, I'm trying to figure out have RFC 8040 query parameter (sect 4.8.4), 

Re: [netmod] WG adoption poll - instance-data

[Balazs Lengyel]

  
  
Hello Kent,
If needed I can do a quick update, but 


  As you stated this is a living document
  IMHO the scope is clear: This is only a data format draft, how
it is used is only here a set of use-cases. I did not see anyone
disagreeing with this.
  
  I would like to avoid redoing this poll. 
  
  My wish (if the good fairy can fulfill it) is that the draft
is adopted, and I update it before the IETF to clarify the scope
as above.

Naturally I will consider all other comments too, but they may
  take some time to discuss.

regards Balazs

On 2018. 10. 09. 19:07, Kent Watsen
  wrote:


  
As co-chair, I have two minds:

  1) requests a fix and redo the adoption poll
  2) realize that it's a living doc and regardless
 how it begins, the WG can sort it out in time.
 i.e., we're adopting to work on the problem,
 not necessarily the specific solution.

While (1) seems more proper, given the timing of 
things, I'm willing to go for (2).   To this extent,
the comments being made now be thought to carry
the same weight as Last Call comments.  The chairs
will discuss this again when making a determination
on the adoption poll.

As contributor, can we please not call this "YANG
instance data"?  - that means something else to 
me.  This seems to be more about capturing data
about a server instances.  So maybe "YANG-based
Server Instance Data"?  (open to suggestions!)

Kent



-Original Message-
From: netmod  on behalf of Balázs Lengyel 
Date: Tuesday, October 9, 2018 at 11:06 AM
To: Martin Bjorklund 
Cc: "netmod-cha...@ietf.org" , "netmod@ietf.org" 
Subject: Re: [netmod] WG adoption poll - instance-data

OK, If the chairs are happy with that, I can update the document before 
I store it as an official netmod document.

regards Balazs

On 2018. 10. 09. 14:25, Martin Bjorklund wrote:

  
Hi,

Balázs Lengyel  wrote:


  Hello Martin,

I agree that this document shall be about defining the file format,
and server capabilities shall only be a use-case.)

I already took out a lot of text, that explicitly recommended using
instance data for documenting capabilities. Server capabilities are
only mentioned in the introduction chapter.
As you wrote: There is no _normative_  specification of how a server
would document its capabilities, because this is
what the WG requested, so I removed it.


Hmm.  Ok, if this is what the WG wants, then it is fine to just have
server capabilities as an example use case.  (I thought that the WG
wanted a normative description of server capabilities...)



  I see that I forgot to change the title and the introduction can be
reworded to make
it more clear that documenting server capabilities is just a use-case.
(I still see it as the primary use-case for instance data.)


I think all text in 2 Introduction (except the last para) in this case
should be moved to section 2.1, and new text should be written in 2.

(*if* there will be a separate doc for server capabilities, the text
in 2 should be moved to that doc instead.)



If I promise to change the title and clarify the introduction can you
support adoption?


First of all I'd like to ensure that the WG in fact just wants to do
the file format.  Since people have expressed support for adopting the
draft with the current title, I'm not so sure that this is the case.

I think you should make those changes, and I support the adoption of
the modified document.  I don't see any reason not to make these
chanegs before posting as a WG doc.


/martin





  regards Balazs

On 2018. 10. 09. 12:58, Martin Bjorklund wrote:

  
Hi,

I still think that this draft should either be split into two, one for
specifiying the generic file format (ok with examples), and one for
"Documenting Server Capabilities", or the document should just be
about the file format (+ *examples*).

[The current document mixes the two; it's a bit as if we had "The
YANG language and a model for interfaces" as one doc...]

It is clear that the document specifies a file format for YANG
instance data, which is good.  But it is not clear if the document
intends to specify how a server should document its capabilities.

The Introduction mainly talks about why it is important to document
server capabilities.  But then AFAICT there is no normative
specification of how a server would document its capabilities.


/martin


Lou Berger  wrote:


  All,

This is start of a two week poll on making
draft-lengyel-netmod-yang-instance-data-04 a working group
document. Please send email to the list indicating "yes/support" or
"no/do not support".  If indicating no, please state your reservations
with the document.  If yes, please also feel free to provide comments
you'd like to see 

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

[Martin Bjorklund]

Mahesh Jethanandani  wrote:
> 
> 
> > On Oct 10, 2018, at 11:51 PM, Martin Bjorklund  wrote:
> > 
> > I just which there was a one-click way (or better some repo) to get
> > all files.
> 
> There is. Benoit had written it, but for the life of me I cannot
> remember what it is called.

I meant from IANA.  3rd party mirrored repos are fine, but it would be
nice to get them directly from IANA in a simple way.


/martin

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

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

[Mahesh Jethanandani]

> On Oct 10, 2018, at 11:51 PM, Martin Bjorklund  wrote:
> 
> I just which there was a one-click way (or better some repo) to get
> all files.

There is. Benoit had written it, but for the life of me I cannot remember what 
it is called. Have send him a note, but he is offline till Nov.

Mahesh Jethanandani
mjethanand...@gmail.com



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

[Eric Rescorla]

That seems like it's going to have some pretty surprising consequences and
at minimum needs more information in the Security Considerations.

On Thu, Oct 11, 2018 at 12:18 AM Martin Bjorklund  wrote:

> Eric Rescorla  wrote:
> > 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
>
> Yes, but note that these XPath expressions ("parent-reference") are
> read-only (config false in the YANG model).  Thus they are set by the
> implementation, and used to inform the operator about the environment
> in which other XPath expressions are evaluated.
>
>
> /martin
>
>
> >
> > -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] xpath expressions in JSON

[Robert Wilton]

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"?




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 another Xpath format to YANG.


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.


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


Thanks,
Rob

Re: [netmod] xpath expressions in JSON

[Vladimir Vassilev]

On 10/11/18 11:43 AM, Vladimir Vassilev wrote:


+1. This is one of the two necessary changes to make the 
instance-identifier type canonical. Proposed changes RFC 7950:


OLD:

9.13.2.  Lexical Representation

   An instance-identifier value is lexically represented as a string.
   All node names in an instance-identifier value MUST be qualified with
   explicit namespace prefixes, and these prefixes MUST be declared in
   the XML namespace scope in the instance-identifier's XML element.

   Any prefixes used in the encoding are local to each instance
   encoding.  This means that the same instance-identifier may be
   encoded differently by different implementations.

9.13.3.  Canonical Form

   Since the lexical form depends on the XML context in which the value
   occurs, this type does not have a canonical form.

NEW:

9.13.2.  Lexical Representation

   An instance-identifier value is lexically represented as a string.
   All node names in an instance-identifier value MUST be qualified with
   explicit namespace prefixes where the module name is used as prefix.

   All predicates must appear in alphabetical order.


9.13.3.  Canonical Form

   Since the lexical form is encoding independent and tere is prescribed

   alphabetical order of the predicates the type has a canonical form.


The order of the keys does not need to be alphabetical. It can be the 
order of the keys specified in the YANG module but currently there is no 
requirement for order at all.


Vladimir




Vladimir







/martin





 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


___
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

[Vladimir Vassilev]

On 10/11/18 11:21 AM, Andy Bierman wrote:


So you must mean the full module name will be used at every node:

 
/ietf-interfaces:interfaces/ietf-interfaces:interface[ietf-interfaces:name='eth0']


Length is the only real problem I see with the solution. The lexical 
representation of identityref type has made a compromise accepting 
prefix instead of module name. This has its own unsolved issues but 
those could be addressed by a limitation not allowing modules with 
identical prefix statements to define homonyme data nodes and identities 
(which is not the case currently). If this is done module name can be 
replaced with prefix and the instance-identifiers will be shorter and 
encoding independent but still Xpath 1.0 compatible:


 /if:interfaces/if:interface[if:name='eth0']

Vladimir

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

Re: [netmod] xpath expressions in JSON

[Martin Bjorklund]

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.

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"?



/martin



> 
> Thanks,
> Rob
>  
> 
> >
> > There is no standard XPath implementation that can just take an XML
> > instance document + YANG module and figure out what to do.  Custom
> > code is needed to connect things together.  This proposal doesn't
> > change this.
> >
> >
> > /martin
> >
> >
> >> A normal XPath implementation will not find any namespace mapping for
> >> the
> >> prefixes.
> >>
> >> An XPath expression has no concept of the "current module" inherited
> >> from
> >> the parent
> >> like the JSON encoding. This is problematic for predicates
> >>
> >> /ietf-interfaces:interfaces/interface[name='eth0']
> >>
> >> XPath says the missing prefixes for 'interface' and 'name' are simply
> >> missing (no namespace).
> >> The JSON encoding says "ietf-interfaces" is used for 'interfaces'. and
> >> 

Re: [netmod] xpath expressions in JSON

[Robert Wilton]

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"

Thanks,
Rob
 



There is no standard XPath implementation that can just take an XML
instance document + YANG module and figure out what to do.  Custom
code is needed to connect things together.  This proposal doesn't
change this.


/martin



A normal XPath implementation will not find any namespace mapping for the
prefixes.

An XPath expression has no concept of the "current module" inherited from
the parent
like the JSON encoding. This is problematic for predicates

/ietf-interfaces:interfaces/interface[name='eth0']

XPath says the missing prefixes for 'interface' and 'name' are simply
missing (no namespace).
The JSON encoding says "ietf-interfaces" is used for 'interfaces'. and
'interface'.
There is no specification for the 'name' node inside a predicate.

So you must mean the full module name will be used at every node:

  
/ietf-interfaces:interfaces/ietf-interfaces:interface[ietf-interfaces:name='eth0']




/martin



Andy





 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 

Re: [netmod] xpath expressions in JSON

[Martin Bjorklund]

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.

There is no standard XPath implementation that can just take an XML
instance document + YANG module and figure out what to do.  Custom
code is needed to connect things together.  This proposal doesn't
change this.


/martin


> A normal XPath implementation will not find any namespace mapping for the
> prefixes.
> 
> An XPath expression has no concept of the "current module" inherited from
> the parent
> like the JSON encoding. This is problematic for predicates
> 
>/ietf-interfaces:interfaces/interface[name='eth0']
> 
> XPath says the missing prefixes for 'interface' and 'name' are simply
> missing (no namespace).
> The JSON encoding says "ietf-interfaces" is used for 'interfaces'. and
> 'interface'.
> There is no specification for the 'name' node inside a predicate.
> 
> So you must mean the full module name will be used at every node:
> 
>  
> /ietf-interfaces:interfaces/ietf-interfaces:interface[ietf-interfaces:name='eth0']
> 
> 
> 
> >
> > /martin
> >
> >
> Andy
> 
> 
> >
> > >
> > >
> > > > 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

Re: [netmod] xpath expressions in JSON

[Robert Wilton]

On 11/10/2018 10:21, Andy Bierman wrote:



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


Andy Bierman mailto:a...@yumaworks.com>> wrote:
> On Wed, Oct 10, 2018 at 6:59 PM, Reshad Rahman (rrahman)
mailto: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 mailto:lho...@nic.cz>> wrote:
> >     > Martin Bjorklund mailto:m...@tail-f.com>> 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.
A normal XPath implementation will not find any namespace mapping for 
the prefixes.


An XPath expression has no concept of the "current module" inherited 
from the parent

like the JSON encoding. This is problematic for predicates

   /ietf-interfaces:interfaces/interface[name='eth0']

XPath says the missing prefixes for 'interface' and 'name' are simply 
missing (no namespace).
The JSON encoding says "ietf-interfaces" is used for 'interfaces'. and 
'interface'.

There is no specification for the 'name' node inside a predicate.

So you must mean the full module name will be used at every node:

 
/ietf-interfaces:interfaces/ietf-interfaces:interface[ietf-interfaces:name='eth0']
Hum, that is going to make these expressions very long, and not 
particularly human readable.


The XPath 1.0 spec that YANG using is effectively obsoleted by newer 
(much more complex) versions.  I doubt that this will be liked, but my 
view is that the longer term solution here is for a bespoke "YANG Path" 
language to be specified, closely based on XPath 1.0, but fixing some of 
the issues that we have using XPath for YANG constraints (e.g. it is 
easy to get them wrong), and removing some of stuff that isn't helpful 
(e.g. node tests, processing instructions, etc).


Thanks,
Rob







/martin


Andy


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

Re: [netmod] xpath expressions in JSON

[Vladimir Vassilev]

On 10/11/18 8:39 AM, Martin Bjorklund wrote:

Andy Bierman  wrote:

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.

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


+1. This is one of the two necessary changes to make the 
instance-identifier type canonical. Proposed changes RFC 7950:


OLD:

9.13.2.  Lexical Representation

   An instance-identifier value is lexically represented as a string.
   All node names in an instance-identifier value MUST be qualified with
   explicit namespace prefixes, and these prefixes MUST be declared in
   the XML namespace scope in the instance-identifier's XML element.

   Any prefixes used in the encoding are local to each instance
   encoding.  This means that the same instance-identifier may be
   encoded differently by different implementations.

9.13.3.  Canonical Form

   Since the lexical form depends on the XML context in which the value
   occurs, this type does not have a canonical form.

NEW:

9.13.2.  Lexical Representation

   An instance-identifier value is lexically represented as a string.
   All node names in an instance-identifier value MUST be qualified with
   explicit namespace prefixes where the module name is used as prefix.

   All predicates must appear in alphabetical order.


9.13.3.  Canonical Form

   Since the lexical form is encoding independent and tere is prescribed

   alphabetical order of the predicates the type has a canonical form.


Vladimir







/martin





 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
  

Re: [netmod] xpath expressions in JSON

[Andy Bierman]

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.
A normal XPath implementation will not find any namespace mapping for the
prefixes.

An XPath expression has no concept of the "current module" inherited from
the parent
like the JSON encoding. This is problematic for predicates

   /ietf-interfaces:interfaces/interface[name='eth0']

XPath says the missing prefixes for 'interface' and 'name' are simply
missing (no namespace).
The JSON encoding says "ietf-interfaces" is used for 'interfaces'. and
'interface'.
There is no specification for the 'name' node inside a predicate.

So you must mean the full module name will be used at every node:

 
/ietf-interfaces:interfaces/ietf-interfaces:interface[ietf-interfaces:name='eth0']



>
> /martin
>
>
Andy


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

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

[Spencer Dawkins at IETF]

Hi, Martin,

On Thu, Oct 11, 2018 at 2:50 AM Martin Bjorklund  wrote:

> Hi,
>
> Spencer Dawkins  wrote:
> > 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?
>
> The WG had a couple of discussions about the title, even though this
> particular proposal hasn't come up.


Excellent - at least it wasn't a completely stupid question.

In addition to the term's meaning in Unix, "Mount" is probably used as a
verb more often in English than as a noun, so this is one of the cases
where not speaking English as my first language would have made this LESS
jarring. And that's a win for readers with other backgrounds ;-)


> I think the document is about
> more than just the mount point, so I think we should keep the current
> title.
>

Sure, and thank you for the feedback.

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

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

[Martin Bjorklund]

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

Some examples and a bit of reasoning is provided in A.2 and A.3.
Maybe add a reference in 3.3:

   Examples of "inline" and "shared-schema" can be found in Appendix A.2
   and Appendix A.3, respectively.


/martin

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

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

[Martin Bjorklund]

Hi,

Ben Campbell  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". 

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

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

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

Yes, fixed.

> 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

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

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

[Martin Bjorklund]

Hi,

Spencer Dawkins  wrote:
> 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?

The WG had a couple of discussions about the title, even though this
particular proposal hasn't come up.  I think the document is about
more than just the mount point, so I think we should keep the current
title.


/martin

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

Yes, but note that these XPath expressions ("parent-reference") are
read-only (config false in the YANG model).  Thus they are set by the
implementation, and used to inform the operator about the environment
in which other XPath expressions are evaluated.


/martin


> 
> -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] Place to download Standard YANG Modules ?

[Martin Bjorklund]

Jernej Tuljak  wrote:
> 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).

Done, and they have now fixed all these issues.

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

The IANA site is getting better.  The new process is that the RFC
editor sends the YANG module to IANA as it is before it is put into
the text format in the RFC, i.e., before indentation and page breaks
and all that.

I just which there was a one-click way (or better some repo) to get
all files.


/martin

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

[Martin Bjorklund]

Qin Wu  wrote:
> -邮件原件-
> 发件人: 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

That is a slightly different problem; how to represent an
*instance-identifier* in a RESTCONF URL.


/martin


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

[Martin Bjorklund]

Ladislav Lhotka  wrote:
> On Wed, 2018-10-10 at 19:23 -0700, Andy Bierman wrote:
> > 
> > 
> > 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.
> 
> The thing is that XPath is "XML Path Language", so using it outside XML is
> problematic.

Not necessarily.  Section 5 of the XPath 1.0 spec defins the "data
model" where an XPath expression is applied.  We could make a formal
specification of how a YANG data tree maps to this data model (pretty
straightforward...).  I think experience from implementations over the
last 8 years show that this in fact works quite well.


/martin



> 
> Lada
> 
> > 
> > > 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
> > 
> > 
> -- 
> 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]

Andy Bierman  wrote:
> 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.

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




/martin


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

[Ladislav Lhotka]

On Wed, 2018-10-10 at 19:23 -0700, Andy Bierman wrote:
> 
> 
> 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.

The thing is that XPath is "XML Path Language", so using it outside XML is
problematic.

Lada

> 
> > 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
> 
> 
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

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