Re: [netmod] I-D Action: draft-wu-netmod-factory-default-00.txt

[Qin Wu]

Talking with NETCONF and NETMOD chairs about the relation with netmod and 
netconf, we agree to move draft-wu-netconf-restconf-factory-restore
To netmod with draft name change and reference changes, i.e.,
1.The draft name is changed into draft-wu-netmod-factory-default-00
2.The references to netconf and restconf are removed.
https://tools.ietf.org/html/draft-wu-netmod-factory-default-00
We will also present the update of this work in netmod.

-Qin (on behalf of authors)
-邮件原件-
发件人: I-D-Announce [mailto:i-d-announce-boun...@ietf.org] 代表 
internet-dra...@ietf.org
发送时间: 2018年10月19日 8:41
收件人: i-d-annou...@ietf.org
主题: I-D Action: draft-wu-netmod-factory-default-00.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.


Title   : Factory default Setting
Authors : Qin Wu
  Balazs Lengyel
  Ye Niu
Filename: draft-wu-netmod-factory-default-00.txt
Pages   : 9
Date: 2018-10-18

Abstract:
   This document defines a method to reset a YANG datastore to it's
   factory-default content.  The reset operation may be used e.g. during
   initial zero-touch configuration or when the existing configuration
   got major errors, so re-starting the configuration process from
   scratch is the best option.

   A new reset-datastore RPC is defined.  Several methods of documenting
   the factory-default content are specified.

   Optionally a new "factory-default-running" read-only datastore is
   defined, that contains the data that will be copied over to the
   running datastore at reset.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-wu-netmod-factory-default/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-wu-netmod-factory-default-00
https://datatracker.ietf.org/doc/html/draft-wu-netmod-factory-default-00


Please note that it may take a couple of minutes from the time of submission 
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
I-D-Announce mailing list
i-d-annou...@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html or 
ftp://ftp.ietf.org/ietf/1shadow-sites.txt
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] EXTERNAL: Re: WG LC draft-ietf-netmod-module-tags-02 - 10/2/18 - 10/16/18

[Alex Campbell]

Capabilities, features and deviations indicate the type of requests the router 
can respond to.

The capability advertisement may not affect the router, but the capability 
itself directly does.
The capability advertisement tells the client that the router can answer 
requests involving the capability in question.

Will clients base their behaviour on module tags, such as fetching all modules 
with a particular tag?
In that case, as a vendor, I do not understand the implications of adding or 
removing a tag and I would prefer if the RFC was clearer on that point.


From: Christian Hopps 
Sent: Thursday, 18 October 2018 11:16 p.m.
To: Alex Campbell
Cc: Christian Hopps; joel jaeggli; NETMOD Working Group
Subject: EXTERNAL: Re: [netmod] WG LC draft-ietf-netmod-module-tags-02 - 
10/2/18 - 10/16/18

A router has no use for it's capability/feature/deviation advertisements 
either; module-tags are no different in this respect.

Thanks,
Chris.

Alex Campbell  writes:

> Hi,
>
>> The server implements the tags (at least the predefined ones), and the use 
>> cases that come to my mind at least involve clients not servers.
>
> I assume that the server here is a network element implementing 
> ietf-module-tags.
>
> I still don't see why network elements should implement ietf-module-tags.
> What benefit is gained from storing the tags on the server instead of the 
> client? It seems backwards.
>
> Have I misunderstood? I assumed that ietf-module-tags was meant to be 
> implemented by network elements that are NETCONF servers - but now I see the 
> document doesn't actually specify who is meant to implement the module. Your 
> comment about newly installed routers supports my understanding however.
>
>> I'm a bit confused by this. Not having to go add e.g., an "OAM" tag to 
>> modules is exactly the point of pre-defined tags, but you questioned their 
>> value at the top of your mail.
>
> The problem with pre-defined tags is that they are never complete. I can 
> always find a useful tag that is not pre-defined.
>
>> Either way configuring a newly installed router is a given, I don't think 
>> this is the place to solve the "forgot to add all the config to my new 
>> router install" issue. :) If one is using tags in ones network then making 
>> sure the newly installed router has tags configured the way you expect is no 
>> different from making sure that you configured IS-IS correctly.
>
> The reason I find this problematic is the same as above - that the router has 
> no use for the tag data.
> It's as if my PC were to download its keyboard mapping table from my home 
> router. Then I change ISPs and have to swap the router, and suddenly my 
> keyboard doesn't work correctly.
> It would be much better to store the keyboard mapping table for my PC *on my 
> PC* instead of adding needless external dependencies.
>
> Alex
>
>
> 
> From: Christian Hopps 
> Sent: Wednesday, 17 October 2018 9:56 p.m.
> To: Alex Campbell
> Cc: Christian Hopps; joel jaeggli; NETMOD Working Group
> Subject: Re: [netmod] WG LC draft-ietf-netmod-module-tags-02 - 10/2/18 - 
> 10/16/18
>
> The point is to keep this open to however the community might end up choosing 
> to use it. The act of pre-defining tags doesn't disallow other tags being 
> defined, in fact at this point I've sent a bunch of email defending leaving 
> things as open as possible. They both can co-exist. :)
>
> Thanks,
> Chris.
>
>> On Oct 16, 2018, at 7:32 PM, Alex Campbell  
>> wrote:
>>
>> I have no issue with systems using tags to classify or organize modules, 
>> however this seems to me like something that would be specific to the system 
>> doing the classifying.
>
> Sure we support this. That's what user tag configuration is there for.
>
>> It would not be something that needs to be specified in the module itself 
>> (except perhaps as freeform description text), and it certainly would not 
>> need to involve the NETCONF server.
>> What would a server do with module classification data? (unless it is also 
>> implementing some kind of module browsing interface, in which case it might 
>> be used to supply the browser with data)
>
> The server implements the tags (at least the predefined ones), and the use 
> cases that come to my mind at least involve clients not servers. I'm not 
> saying there wouldn't be a server use case, but it's not as obvious to me.
>
> And yes implementing some kind of module browsing interface (which could 
> group modules by tags) is a fine example of how tags can be used.
>
>>
>> Hashtags - all types, that I'm aware of - are inherently freeform and fluid, 
>> changing quickly according to the desires of users. I don't think it makes 
>> sense to "hard-code" them in published RFCs or even published vendor modules 
>> or firmware.
>>
>> Tomorrow, I might want to list all modules for management plane protocols. 
>> As a network operator, should I go and update the 

Re: [netmod] xpath expressions in JSON

[Andy Bierman]

On Thu, Oct 18, 2018 at 1:32 PM, Martin Bjorklund  wrote:

> Andy Bierman  wrote:
> > On Thu, Oct 18, 2018 at 12:58 PM, Martin Bjorklund 
> wrote:
> >
> > > Andy Bierman  wrote:
> > > > Hi,
> > > >
> > > > I strongly agree that a new data type is needed (ypath1.0 or just
> ypath
> > > is
> > > > fine)
> > > > Adding new semantics or requirements to published data types is
> > > > unacceptable.
> > > >
> > > > Also, we must get the type and module containing the data type right
> on
> > > the
> > > > first try.
> > > > No moving it later because the import looks bad. That said, a "quick
> > > > 6991-bis" is unrealistic,
> > > > and a multi-year 6991-bis is unhelpful.
> > > >
> > > > Should there be a canonical format, based on module-names as
> prefixes?
> > > > Consider how to compare 2 values using this data type.
> > >
> > > Ok.  So which alternative do you prefer for stream-xpath-filter, which
> > > is supposed to work also for JSON?  The current definition doesn't
> > > work for JSON.
> > >
> > >
> >
> > I don't like calling it xpath when it is not XPath any more.
>
> But stream-xpath-filter *is* XPath.  The alternative solutions differ
> only in how the prefix mapping is defined.
>


I don't think it should be called XPath if module-names are used as
prefixes.
Alternative A using a special data type is the least objectionable I guess


Andy


> > It should be as clear as possible to readers and designers that xpath
> > means XPath and ypath is not XPath.
> >
> > I would prefer a new encoding that allows the parent node module-name to
> be
> > used somehow,
> > consistent with the JSON encoding used now.
> >
> > Perhaps each absolute-path expression starts with a module-name step and
> > relative-path
> > expressions assume the module name of the context node if there is no
> > module-name.
> >
> > Neither alternative below is a good long-term solution.
>
> Agreed, but we need to find a solution for stream-xpath-filter, or
> else we should remove it from SN.
>
> > The old problems come up again:
> >
> >   Client A writes the /foo node in XML.
> >   Client B reads the /foo node returned in JSON
> >
> > Which format is returned? Does the server magically convert the value for
> > each encoding type?
>
> Yes, just like it does with i-i and identityref.
>
> > If we bother to fix this problem at all, then we should get rid of
> reliance
> > on prefix to namespace mappings.
>
> Long-term, yes!
>
>
> /martin
>
>
> >
> >
> >
> >
> >
> > > /martin
> > >
> > >
> >
> > Andy
> >
> >
> > >
> > > >
> > > >
> > > > Andy
> > > >
> > > >
> > > > On Thu, Oct 18, 2018 at 10:42 AM, Vladimir Vassilev <
> > > > vladi...@transpacket.com> wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > Seems this discussion affects 10 draft modules using the xpath1.0
> type.
> > > > > The proposed boilerplate description text that was not added to
> some
> > > RFC
> > > > > modules like ietf-netconf-monitor...@2010-10-04.yang
> > > > >
> > > > > should be as consistent as possible (or skipped based on the
> > > > > ietf-netconf-monitoring precedent) until a better alternative is
> > > available.
> > > > > Here is an example of a better alternative.
> > > > >
> > > > >typedef ypath1.0 {
> > > > > type xpath1.0;
> > > > > description
> > > > >  "This type represents subset of XPATH 1.0 expressions
> > > > >   that apply to a data tree conforming to a YANG model.
> > > > >
> > > > >   Each encoding should allow conversion to an encoding
> > > > >   independent lexical representation where data node
> > > > >   prefixes are resolved to and substituted with module
> > > > >   names.
> > > > >
> > > > >   When a schema node is defined that uses this type, the
> > > > >   description of the schema node MUST specify the
> > > > >   context in which the expression is evaluated if it
> > > > >   is different from the default context.
> > > > >
> > > > >   The default context is as follows:
> > > > >
> > > > > o  The set of variable bindings is empty.
> > > > >
> > > > > o  The function library is the core function library, and
> > > > >the XPath functions defined in section 10 in RFC 7950.
> > > > >
> > > > > o  The context node is the leaf node.
> > > > >
> > > > >   ";
> > > > > reference
> > > > >  "XPATH: XML Path Language (XPath) Version 1.0";
> > > > >   }
> > > > >
> > > > > That said I do not object to short-term application of alternative
> A as
> > > > > long as a long-term solution is on its way for future modules.
> > > > >
> > > > > Vladimir
> > > > >
> > > > > On 10/18/18 12:30 PM, Martin Bjorklund wrote:
> > > > >
> > > > >> Hi,
> > > > >>
> > > > >> Going back to the most urgent issue, what is this WG's
> recommendation
> > > > >> for the subscribed-notifications draft in NETCONF wrt/ their
> usage of
> > > > >> yang:xpath1.0 in filters?
> > > > >>
> > > > >> To summarize:
> > > > >>
> > > > >> We already have
> > > > >>
> > > > >>  

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

[Kent Watsen]

This message concludes the successful adoption of 
draft-clemm-netmod-nmda-diff-00.  

Authors, please resubmit this draft, unchanged, other than to rename it as 
draft-ietf-netmod-nmda-diff-00.

As is generally the case, this approval signals that the working group is 
willing to work on the problem, not that the specific solution described in the 
is itself approved.  In particular, the chairs request that the use cases are 
reexamined in order to determine what format and/or formats are needed and, if 
more than one, which is the default.

Thanks,
Kent (and Lou and Joel)


-Original Message-
From: netmod  on behalf of Kent Watsen 

Date: Monday, October 1, 2018 at 2:48 PM
To: "netmod@ietf.org" 
Subject: [netmod] WG adoption poll for draft-clemm-netmod-nmda-diff-00

The IETF 102 in-room poll should really good support to adopt
this draft, and no objections.

This email starts an adoption poll for:

  
https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dclemm-2Dnetmod-2Dnmda-2Ddiff-2D00=DwICAg=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=gsKerK-Djok6lTL0A8Sm8PaSJp6FiR0S154Q4ngxing=u88P8I81zsimKgBTZg6rJeSJBMR8dk-DshFuuehBkVM=

Please indicate your support or objection to the adoption poll. 
If objecting, please state your reasons on this thread.

Kent (and Lou and Joel)

___
netmod mailing list
netmod@ietf.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod=DwICAg=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=gsKerK-Djok6lTL0A8Sm8PaSJp6FiR0S154Q4ngxing=PSOMHRPSVUZHLBlFdhmxWjwRc4VHG45k-vh2cJJjqI8=

___
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 Thu, Oct 18, 2018 at 12:58 PM, Martin Bjorklund  wrote:
> 
> > Andy Bierman  wrote:
> > > Hi,
> > >
> > > I strongly agree that a new data type is needed (ypath1.0 or just ypath
> > is
> > > fine)
> > > Adding new semantics or requirements to published data types is
> > > unacceptable.
> > >
> > > Also, we must get the type and module containing the data type right on
> > the
> > > first try.
> > > No moving it later because the import looks bad. That said, a "quick
> > > 6991-bis" is unrealistic,
> > > and a multi-year 6991-bis is unhelpful.
> > >
> > > Should there be a canonical format, based on module-names as prefixes?
> > > Consider how to compare 2 values using this data type.
> >
> > Ok.  So which alternative do you prefer for stream-xpath-filter, which
> > is supposed to work also for JSON?  The current definition doesn't
> > work for JSON.
> >
> >
> 
> I don't like calling it xpath when it is not XPath any more.

But stream-xpath-filter *is* XPath.  The alternative solutions differ
only in how the prefix mapping is defined.

> It should be as clear as possible to readers and designers that xpath
> means XPath and ypath is not XPath.
> 
> I would prefer a new encoding that allows the parent node module-name to be
> used somehow,
> consistent with the JSON encoding used now.
> 
> Perhaps each absolute-path expression starts with a module-name step and
> relative-path
> expressions assume the module name of the context node if there is no
> module-name.
> 
> Neither alternative below is a good long-term solution.

Agreed, but we need to find a solution for stream-xpath-filter, or
else we should remove it from SN.

> The old problems come up again:
> 
>   Client A writes the /foo node in XML.
>   Client B reads the /foo node returned in JSON
> 
> Which format is returned? Does the server magically convert the value for
> each encoding type?

Yes, just like it does with i-i and identityref.

> If we bother to fix this problem at all, then we should get rid of reliance
> on prefix to namespace mappings.

Long-term, yes!


/martin


> 
> 
> 
> 
> 
> > /martin
> >
> >
> 
> Andy
> 
> 
> >
> > >
> > >
> > > Andy
> > >
> > >
> > > On Thu, Oct 18, 2018 at 10:42 AM, Vladimir Vassilev <
> > > vladi...@transpacket.com> wrote:
> > >
> > > > Hi,
> > > >
> > > > Seems this discussion affects 10 draft modules using the xpath1.0 type.
> > > > The proposed boilerplate description text that was not added to some
> > RFC
> > > > modules like ietf-netconf-monitor...@2010-10-04.yang
> > > >
> > > > should be as consistent as possible (or skipped based on the
> > > > ietf-netconf-monitoring precedent) until a better alternative is
> > available.
> > > > Here is an example of a better alternative.
> > > >
> > > >typedef ypath1.0 {
> > > > type xpath1.0;
> > > > description
> > > >  "This type represents subset of XPATH 1.0 expressions
> > > >   that apply to a data tree conforming to a YANG model.
> > > >
> > > >   Each encoding should allow conversion to an encoding
> > > >   independent lexical representation where data node
> > > >   prefixes are resolved to and substituted with module
> > > >   names.
> > > >
> > > >   When a schema node is defined that uses this type, the
> > > >   description of the schema node MUST specify the
> > > >   context in which the expression is evaluated if it
> > > >   is different from the default context.
> > > >
> > > >   The default context is as follows:
> > > >
> > > > o  The set of variable bindings is empty.
> > > >
> > > > o  The function library is the core function library, and
> > > >the XPath functions defined in section 10 in RFC 7950.
> > > >
> > > > o  The context node is the leaf node.
> > > >
> > > >   ";
> > > > reference
> > > >  "XPATH: XML Path Language (XPath) Version 1.0";
> > > >   }
> > > >
> > > > That said I do not object to short-term application of alternative A as
> > > > long as a long-term solution is on its way for future modules.
> > > >
> > > > Vladimir
> > > >
> > > > On 10/18/18 12:30 PM, Martin Bjorklund wrote:
> > > >
> > > >> Hi,
> > > >>
> > > >> Going back to the most urgent issue, what is this WG's recommendation
> > > >> for the subscribed-notifications draft in NETCONF wrt/ their usage of
> > > >> yang:xpath1.0 in filters?
> > > >>
> > > >> To summarize:
> > > >>
> > > >> We already have
> > > >>
> > > >>o  instance-identifier in XML uses prefixes from the XML document
> > > >>o  instance-identifier in JSON uses module names as prefixes
> > > >>o  XPath in NETCONF filter uses prefixes from the XML document
> > > >>o  XPath in JSON query filter uses module names as prefixes
> > > >>
> > > >>
> > > >> Alternative A:
> > > >> --
> > > >>
> > > >> Use different encodings for "stream-xpath-filter" as well, depending
> > > >> on if it is XML or JSON.
> > > >>
> > > >> We would do in SN:
> > > 

Re: [netmod] xpath expressions in JSON

[Juergen Schoenwaelder]

On Thu, Oct 18, 2018 at 12:58:33PM -0700, Andy Bierman wrote:
> On Thu, Oct 18, 2018 at 12:50 PM, Juergen Schoenwaelder <
> j.schoenwael...@jacobs-university.de> wrote:
> 
> > On Thu, Oct 18, 2018 at 12:45:44PM -0700, Andy Bierman wrote:
> >
> > > No moving it later because the import looks bad. That said, a "quick
> > > 6991-bis" is unrealistic, and a multi-year 6991-bis is unhelpful.
> >
> > https://datatracker.ietf.org/doc/rfc6991/
> 
> Are you suggesting that because it only took  11 months last time we will
> not keep adding "1 more thing" over and over for 24+ months (like some
> other work items)?

There is no guarantee but as long as we start with the assumption that
what we do will be slow, we should not be surprised that things are
actually slow. ;-)

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

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

Re: [netmod] xpath expressions in JSON

[Andy Bierman]

On Thu, Oct 18, 2018 at 12:58 PM, Martin Bjorklund  wrote:

> Andy Bierman  wrote:
> > Hi,
> >
> > I strongly agree that a new data type is needed (ypath1.0 or just ypath
> is
> > fine)
> > Adding new semantics or requirements to published data types is
> > unacceptable.
> >
> > Also, we must get the type and module containing the data type right on
> the
> > first try.
> > No moving it later because the import looks bad. That said, a "quick
> > 6991-bis" is unrealistic,
> > and a multi-year 6991-bis is unhelpful.
> >
> > Should there be a canonical format, based on module-names as prefixes?
> > Consider how to compare 2 values using this data type.
>
> Ok.  So which alternative do you prefer for stream-xpath-filter, which
> is supposed to work also for JSON?  The current definition doesn't
> work for JSON.
>
>

I don't like calling it xpath when it is not XPath any more.
It should be as clear as possible to readers and designers that xpath
means XPath and ypath is not XPath.

I would prefer a new encoding that allows the parent node module-name to be
used somehow,
consistent with the JSON encoding used now.

Perhaps each absolute-path expression starts with a module-name step and
relative-path
expressions assume the module name of the context node if there is no
module-name.

Neither alternative below is a good long-term solution.

The old problems come up again:

  Client A writes the /foo node in XML.
  Client B reads the /foo node returned in JSON

Which format is returned? Does the server magically convert the value for
each encoding type?
If we bother to fix this problem at all, then we should get rid of reliance
on prefix to namespace mappings.





> /martin
>
>

Andy


>
> >
> >
> > Andy
> >
> >
> > On Thu, Oct 18, 2018 at 10:42 AM, Vladimir Vassilev <
> > vladi...@transpacket.com> wrote:
> >
> > > Hi,
> > >
> > > Seems this discussion affects 10 draft modules using the xpath1.0 type.
> > > The proposed boilerplate description text that was not added to some
> RFC
> > > modules like ietf-netconf-monitor...@2010-10-04.yang
> > >
> > > should be as consistent as possible (or skipped based on the
> > > ietf-netconf-monitoring precedent) until a better alternative is
> available.
> > > Here is an example of a better alternative.
> > >
> > >typedef ypath1.0 {
> > > type xpath1.0;
> > > description
> > >  "This type represents subset of XPATH 1.0 expressions
> > >   that apply to a data tree conforming to a YANG model.
> > >
> > >   Each encoding should allow conversion to an encoding
> > >   independent lexical representation where data node
> > >   prefixes are resolved to and substituted with module
> > >   names.
> > >
> > >   When a schema node is defined that uses this type, the
> > >   description of the schema node MUST specify the
> > >   context in which the expression is evaluated if it
> > >   is different from the default context.
> > >
> > >   The default context is as follows:
> > >
> > > o  The set of variable bindings is empty.
> > >
> > > o  The function library is the core function library, and
> > >the XPath functions defined in section 10 in RFC 7950.
> > >
> > > o  The context node is the leaf node.
> > >
> > >   ";
> > > reference
> > >  "XPATH: XML Path Language (XPath) Version 1.0";
> > >   }
> > >
> > > That said I do not object to short-term application of alternative A as
> > > long as a long-term solution is on its way for future modules.
> > >
> > > Vladimir
> > >
> > > On 10/18/18 12:30 PM, Martin Bjorklund wrote:
> > >
> > >> Hi,
> > >>
> > >> Going back to the most urgent issue, what is this WG's recommendation
> > >> for the subscribed-notifications draft in NETCONF wrt/ their usage of
> > >> yang:xpath1.0 in filters?
> > >>
> > >> To summarize:
> > >>
> > >> We already have
> > >>
> > >>o  instance-identifier in XML uses prefixes from the XML document
> > >>o  instance-identifier in JSON uses module names as prefixes
> > >>o  XPath in NETCONF filter uses prefixes from the XML document
> > >>o  XPath in JSON query filter uses module names as prefixes
> > >>
> > >>
> > >> Alternative A:
> > >> --
> > >>
> > >> Use different encodings for "stream-xpath-filter" as well, depending
> > >> on if it is XML or JSON.
> > >>
> > >> We would do in SN:
> > >>
> > >>  o  If the node is encoded in XML, the set of namespace
> > >> declarations are those in scope on the
> > >> 'stream-xpath-filter' leaf element.
> > >>
> > >>  o  If the node is encoded in JSON, 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.
> > >>
> > >> Pro: the format is consistent within each encoding.
> > >>
> > >> Con: 

Re: [netmod] xpath expressions in JSON

[Martin Bjorklund]

Andy Bierman  wrote:
> Hi,
> 
> I strongly agree that a new data type is needed (ypath1.0 or just ypath is
> fine)
> Adding new semantics or requirements to published data types is
> unacceptable.
> 
> Also, we must get the type and module containing the data type right on the
> first try.
> No moving it later because the import looks bad. That said, a "quick
> 6991-bis" is unrealistic,
> and a multi-year 6991-bis is unhelpful.
> 
> Should there be a canonical format, based on module-names as prefixes?
> Consider how to compare 2 values using this data type.

Ok.  So which alternative do you prefer for stream-xpath-filter, which
is supposed to work also for JSON?  The current definition doesn't
work for JSON.


/martin


> 
> 
> Andy
> 
> 
> On Thu, Oct 18, 2018 at 10:42 AM, Vladimir Vassilev <
> vladi...@transpacket.com> wrote:
> 
> > Hi,
> >
> > Seems this discussion affects 10 draft modules using the xpath1.0 type.
> > The proposed boilerplate description text that was not added to some RFC
> > modules like ietf-netconf-monitor...@2010-10-04.yang
> >
> > should be as consistent as possible (or skipped based on the
> > ietf-netconf-monitoring precedent) until a better alternative is available.
> > Here is an example of a better alternative.
> >
> >typedef ypath1.0 {
> > type xpath1.0;
> > description
> >  "This type represents subset of XPATH 1.0 expressions
> >   that apply to a data tree conforming to a YANG model.
> >
> >   Each encoding should allow conversion to an encoding
> >   independent lexical representation where data node
> >   prefixes are resolved to and substituted with module
> >   names.
> >
> >   When a schema node is defined that uses this type, the
> >   description of the schema node MUST specify the
> >   context in which the expression is evaluated if it
> >   is different from the default context.
> >
> >   The default context is as follows:
> >
> > o  The set of variable bindings is empty.
> >
> > o  The function library is the core function library, and
> >the XPath functions defined in section 10 in RFC 7950.
> >
> > o  The context node is the leaf node.
> >
> >   ";
> > reference
> >  "XPATH: XML Path Language (XPath) Version 1.0";
> >   }
> >
> > That said I do not object to short-term application of alternative A as
> > long as a long-term solution is on its way for future modules.
> >
> > Vladimir
> >
> > On 10/18/18 12:30 PM, Martin Bjorklund wrote:
> >
> >> Hi,
> >>
> >> Going back to the most urgent issue, what is this WG's recommendation
> >> for the subscribed-notifications draft in NETCONF wrt/ their usage of
> >> yang:xpath1.0 in filters?
> >>
> >> To summarize:
> >>
> >> We already have
> >>
> >>o  instance-identifier in XML uses prefixes from the XML document
> >>o  instance-identifier in JSON uses module names as prefixes
> >>o  XPath in NETCONF filter uses prefixes from the XML document
> >>o  XPath in JSON query filter uses module names as prefixes
> >>
> >>
> >> Alternative A:
> >> --
> >>
> >> Use different encodings for "stream-xpath-filter" as well, depending
> >> on if it is XML or JSON.
> >>
> >> We would do in SN:
> >>
> >>  o  If the node is encoded in XML, the set of namespace
> >> declarations are those in scope on the
> >> 'stream-xpath-filter' leaf element.
> >>
> >>  o  If the node is encoded in JSON, 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.
> >>
> >> Pro: the format is consistent within each encoding.
> >>
> >> Con: unclear how to handle other encodings.
> >> Con: we keep using context-depending encodings.
> >>
> >> We could probably add that CBOR uses the same representation as JSON.
> >>
> >> Example in XML:
> >>
> >> >>xmlns:if="urn:ietf:params:xml:ns:yang:ietf-interfaces"
> >>xmlns:ip="urn:ietf:params:xml:ns:yang:ietf-ip">
> >>  /if:interfaces/if:interface/ip:ipv4
> >>
> >>
> >> Example in JSON:
> >>
> >>"stream-xpath-filter":
> >>  "/ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip:ipv4"
> >>
> >>
> >>
> >> Alternative B:
> >> --
> >>
> >> Use a non-context depending encoding, with the module name as prefix.
> >>
> >> We would do in SN:
> >>
> >>  o  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.
> >>
> >> Pro: the format is independent from the protocol encoding
> >>
> >> Con: in XML, this leaf is treated differently from other XPath
> >>   expressions, 

Re: [netmod] xpath expressions in JSON

[Andy Bierman]

On Thu, Oct 18, 2018 at 12:50 PM, Juergen Schoenwaelder <
j.schoenwael...@jacobs-university.de> wrote:

> On Thu, Oct 18, 2018 at 12:45:44PM -0700, Andy Bierman wrote:
>
> > No moving it later because the import looks bad. That said, a "quick
> > 6991-bis" is unrealistic, and a multi-year 6991-bis is unhelpful.
>
> https://datatracker.ietf.org/doc/rfc6991/


Are you suggesting that because it only took  11 months last time we will
not keep adding "1 more thing" over and over for 24+ months (like some
other work items)?
If so, I hope you are right.



>
> /js
>

Andy


>
> --
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] xpath expressions in JSON

[Juergen Schoenwaelder]

On Thu, Oct 18, 2018 at 12:45:44PM -0700, Andy Bierman wrote:

> No moving it later because the import looks bad. That said, a "quick
> 6991-bis" is unrealistic, and a multi-year 6991-bis is unhelpful.

https://datatracker.ietf.org/doc/rfc6991/

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

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

Re: [netmod] xpath expressions in JSON

[Andy Bierman]

Hi,

I strongly agree that a new data type is needed (ypath1.0 or just ypath is
fine)
Adding new semantics or requirements to published data types is
unacceptable.

Also, we must get the type and module containing the data type right on the
first try.
No moving it later because the import looks bad. That said, a "quick
6991-bis" is unrealistic,
and a multi-year 6991-bis is unhelpful.

Should there be a canonical format, based on module-names as prefixes?
Consider how to compare 2 values using this data type.


Andy


On Thu, Oct 18, 2018 at 10:42 AM, Vladimir Vassilev <
vladi...@transpacket.com> wrote:

> Hi,
>
> Seems this discussion affects 10 draft modules using the xpath1.0 type.
> The proposed boilerplate description text that was not added to some RFC
> modules like ietf-netconf-monitor...@2010-10-04.yang
>
> should be as consistent as possible (or skipped based on the
> ietf-netconf-monitoring precedent) until a better alternative is available.
> Here is an example of a better alternative.
>
>typedef ypath1.0 {
> type xpath1.0;
> description
>  "This type represents subset of XPATH 1.0 expressions
>   that apply to a data tree conforming to a YANG model.
>
>   Each encoding should allow conversion to an encoding
>   independent lexical representation where data node
>   prefixes are resolved to and substituted with module
>   names.
>
>   When a schema node is defined that uses this type, the
>   description of the schema node MUST specify the
>   context in which the expression is evaluated if it
>   is different from the default context.
>
>   The default context is as follows:
>
> o  The set of variable bindings is empty.
>
> o  The function library is the core function library, and
>the XPath functions defined in section 10 in RFC 7950.
>
> o  The context node is the leaf node.
>
>   ";
> reference
>  "XPATH: XML Path Language (XPath) Version 1.0";
>   }
>
> That said I do not object to short-term application of alternative A as
> long as a long-term solution is on its way for future modules.
>
> Vladimir
>
> On 10/18/18 12:30 PM, Martin Bjorklund wrote:
>
>> Hi,
>>
>> Going back to the most urgent issue, what is this WG's recommendation
>> for the subscribed-notifications draft in NETCONF wrt/ their usage of
>> yang:xpath1.0 in filters?
>>
>> To summarize:
>>
>> We already have
>>
>>o  instance-identifier in XML uses prefixes from the XML document
>>o  instance-identifier in JSON uses module names as prefixes
>>o  XPath in NETCONF filter uses prefixes from the XML document
>>o  XPath in JSON query filter uses module names as prefixes
>>
>>
>> Alternative A:
>> --
>>
>> Use different encodings for "stream-xpath-filter" as well, depending
>> on if it is XML or JSON.
>>
>> We would do in SN:
>>
>>  o  If the node is encoded in XML, the set of namespace
>> declarations are those in scope on the
>> 'stream-xpath-filter' leaf element.
>>
>>  o  If the node is encoded in JSON, 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.
>>
>> Pro: the format is consistent within each encoding.
>>
>> Con: unclear how to handle other encodings.
>> Con: we keep using context-depending encodings.
>>
>> We could probably add that CBOR uses the same representation as JSON.
>>
>> Example in XML:
>>
>>>xmlns:if="urn:ietf:params:xml:ns:yang:ietf-interfaces"
>>xmlns:ip="urn:ietf:params:xml:ns:yang:ietf-ip">
>>  /if:interfaces/if:interface/ip:ipv4
>>
>>
>> Example in JSON:
>>
>>"stream-xpath-filter":
>>  "/ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip:ipv4"
>>
>>
>>
>> Alternative B:
>> --
>>
>> Use a non-context depending encoding, with the module name as prefix.
>>
>> We would do in SN:
>>
>>  o  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.
>>
>> Pro: the format is independent from the protocol encoding
>>
>> Con: in XML, this leaf is treated differently from other XPath
>>   expressions, such as get-config filter and nacm rules.
>>
>> Example in XML:
>>
>>
>>  /ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip:ipv4
>>
>>
>> Example in JSON:
>>
>>"stream-xpath-filter":
>>  "/ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip:ipv4"
>>
>>
>> My proposal is A.  I think it is more important with consistency
>> within each encoding than across encodings.
>>
>> (This said, I would like to have a context-independent 

Re: [netmod] WG adoption poll draft-kwatsen-netmod-artwork-folding-08

[Mahesh Jethanandani]

Support.

> On Oct 18, 2018, at 6:03 AM, Lou Berger  wrote:
> 
> All,
> 
> This is start of a two week poll on making
> draft-kwatsen-netmod-artwork-folding-08 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 addressed once the document is a WG document.
> 
> The poll ends Oct 1.
> 
> Thanks,
> 
> Lou (and co-chairs)
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

Mahesh Jethanandani
mjethanand...@gmail.com



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

Re: [netmod] xpath expressions in JSON

[Vladimir Vassilev]

Hi,

Seems this discussion affects 10 draft modules using the xpath1.0 type. 
The proposed boilerplate description text that was not added to some RFC 
modules like ietf-netconf-monitor...@2010-10-04.yang


should be as consistent as possible (or skipped based on the 
ietf-netconf-monitoring precedent) until a better alternative is 
available. Here is an example of a better alternative.


   typedef ypath1.0 {
    type xpath1.0;
    description
 "This type represents subset of XPATH 1.0 expressions
  that apply to a data tree conforming to a YANG model.

  Each encoding should allow conversion to an encoding
  independent lexical representation where data node
  prefixes are resolved to and substituted with module
  names.

  When a schema node is defined that uses this type, the
  description of the schema node MUST specify the
  context in which the expression is evaluated if it
  is different from the default context.

  The default context is as follows:

    o  The set of variable bindings is empty.

    o  The function library is the core function library, and
   the XPath functions defined in section 10 in RFC 7950.

    o  The context node is the leaf node.

  ";
    reference
 "XPATH: XML Path Language (XPath) Version 1.0";
  }

That said I do not object to short-term application of alternative A as 
long as a long-term solution is on its way for future modules.


Vladimir

On 10/18/18 12:30 PM, Martin Bjorklund wrote:

Hi,

Going back to the most urgent issue, what is this WG's recommendation
for the subscribed-notifications draft in NETCONF wrt/ their usage of
yang:xpath1.0 in filters?

To summarize:

We already have

   o  instance-identifier in XML uses prefixes from the XML document
   o  instance-identifier in JSON uses module names as prefixes
   o  XPath in NETCONF filter uses prefixes from the XML document
   o  XPath in JSON query filter uses module names as prefixes


Alternative A:
--

Use different encodings for "stream-xpath-filter" as well, depending
on if it is XML or JSON.

We would do in SN:

 o  If the node is encoded in XML, the set of namespace
declarations are those in scope on the
'stream-xpath-filter' leaf element.

 o  If the node is encoded in JSON, 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.

Pro: the format is consistent within each encoding.

Con: unclear how to handle other encodings.
Con: we keep using context-depending encodings.

We could probably add that CBOR uses the same representation as JSON.

Example in XML:

   
 /if:interfaces/if:interface/ip:ipv4
   

Example in JSON:

   "stream-xpath-filter":
 "/ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip:ipv4"



Alternative B:
--

Use a non-context depending encoding, with the module name as prefix.

We would do in SN:

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

Pro: the format is independent from the protocol encoding

Con: in XML, this leaf is treated differently from other XPath
  expressions, such as get-config filter and nacm rules.

Example in XML:

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

Example in JSON:

   "stream-xpath-filter":
 "/ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip:ipv4"


My proposal is A.  I think it is more important with consistency
within each encoding than across encodings.

(This said, I would like to have a context-independent encoding of all
YANG types in the future.  But not now.)




/martin

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


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

Re: [netmod] WG adoption poll draft-kwatsen-netmod-artwork-folding-08

[Robert Wilton]

Yes/support.

Thanks,
Rob


On 18/10/2018 14:03, Lou Berger wrote:

All,

This is start of a two week poll on making
draft-kwatsen-netmod-artwork-folding-08 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 addressed once the document is a WG document.

The poll ends Oct 1.

Thanks,

Lou (and co-chairs)

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



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

Re: [netmod] WG adoption poll draft-kwatsen-netmod-artwork-folding-08

[Qin Wu]

Yes/support.

-Qin

-Original Message-
From: Lou Berger 
Date: Thursday, October 18, 2018 at 9:11 AM
To: "netmod@ietf.org" 
Cc: "netmod-cha...@ietf.org" 
Subject: WG adoption poll draft-kwatsen-netmod-artwork-folding-08
Resent-From: 
Resent-To: , , 
Resent-Date: Thursday, October 18, 2018 at 9:11 AM

All,

This is start of a two week poll on making
draft-kwatsen-netmod-artwork-folding-08 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 addressed once the 
document is a WG document.

The poll ends Nov 1.

Thanks,

Lou (and co-chairs)

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

Re: [netmod] WG adoption poll draft-kwatsen-netmod-artwork-folding-08

[Kent Watsen]

[fixed the date in Lou's message below]

No objection.

Kent // contributor


-Original Message-
From: Lou Berger 
Date: Thursday, October 18, 2018 at 9:11 AM
To: "netmod@ietf.org" 
Cc: "netmod-cha...@ietf.org" 
Subject: WG adoption poll draft-kwatsen-netmod-artwork-folding-08
Resent-From: 
Resent-To: , , 
Resent-Date: Thursday, October 18, 2018 at 9:11 AM

All,

This is start of a two week poll on making
draft-kwatsen-netmod-artwork-folding-08 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 addressed once the document is a WG document.

The poll ends Nov 1.

Thanks,

Lou (and co-chairs)

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

Re: [netmod] WG adoption poll draft-kwatsen-netmod-artwork-folding-08

[Lou Berger]

Poll ends Nov 1 - sorry about that...


On 10/18/2018 9:03 AM, Lou Berger wrote:

All,

This is start of a two week poll on making
draft-kwatsen-netmod-artwork-folding-08 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 addressed once the document is a WG document.

The poll ends Oct 1.

Thanks,

Lou (and co-chairs)

___
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

[Reshad Rahman (rrahman)]

We can't time travel and as you mentioned option A has consistency within each 
encoding, so I'm also for option A. 

Regards,
Reshad.

On 2018-10-18, 6:30 AM, "netmod on behalf of Martin Bjorklund" 
 wrote:

Hi,

Going back to the most urgent issue, what is this WG's recommendation
for the subscribed-notifications draft in NETCONF wrt/ their usage of
yang:xpath1.0 in filters?

To summarize:

We already have

  o  instance-identifier in XML uses prefixes from the XML document
  o  instance-identifier in JSON uses module names as prefixes
  o  XPath in NETCONF filter uses prefixes from the XML document
  o  XPath in JSON query filter uses module names as prefixes


Alternative A:
--

Use different encodings for "stream-xpath-filter" as well, depending
on if it is XML or JSON.

We would do in SN:

o  If the node is encoded in XML, the set of namespace
   declarations are those in scope on the
   'stream-xpath-filter' leaf element.

o  If the node is encoded in JSON, 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.

Pro: the format is consistent within each encoding.

Con: unclear how to handle other encodings.
Con: we keep using context-depending encodings.

We could probably add that CBOR uses the same representation as JSON.

Example in XML:

  
/if:interfaces/if:interface/ip:ipv4
  

Example in JSON:

  "stream-xpath-filter":
"/ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip:ipv4"



Alternative B:
--

Use a non-context depending encoding, with the module name as prefix.

We would do in SN:

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

Pro: the format is independent from the protocol encoding

Con: in XML, this leaf is treated differently from other XPath
 expressions, such as get-config filter and nacm rules.

Example in XML:

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

Example in JSON:

  "stream-xpath-filter":
"/ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip:ipv4"


My proposal is A.  I think it is more important with consistency
within each encoding than across encodings.

(This said, I would like to have a context-independent encoding of all
YANG types in the future.  But not now.)




/martin

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


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

[netmod] WG adoption poll draft-kwatsen-netmod-artwork-folding-08

[Lou Berger]

All,

This is start of a two week poll on making
draft-kwatsen-netmod-artwork-folding-08 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 addressed once the document is a WG document.

The poll ends Oct 1.

Thanks,

Lou (and co-chairs)

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

Re: [netmod] xpath expressions in JSON

[Robert Wilton]

Given where we are, I also agree that A is the better choice.

I would also like to have a context-independent encoding of all YANG 
types in the future.


Thanks,
Rob


On 18/10/2018 11:30, Martin Bjorklund wrote:

Hi,

Going back to the most urgent issue, what is this WG's recommendation
for the subscribed-notifications draft in NETCONF wrt/ their usage of
yang:xpath1.0 in filters?

To summarize:

We already have

   o  instance-identifier in XML uses prefixes from the XML document
   o  instance-identifier in JSON uses module names as prefixes
   o  XPath in NETCONF filter uses prefixes from the XML document
   o  XPath in JSON query filter uses module names as prefixes


Alternative A:
--

Use different encodings for "stream-xpath-filter" as well, depending
on if it is XML or JSON.

We would do in SN:

 o  If the node is encoded in XML, the set of namespace
declarations are those in scope on the
'stream-xpath-filter' leaf element.

 o  If the node is encoded in JSON, 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.

Pro: the format is consistent within each encoding.

Con: unclear how to handle other encodings.
Con: we keep using context-depending encodings.

We could probably add that CBOR uses the same representation as JSON.

Example in XML:

   
 /if:interfaces/if:interface/ip:ipv4
   

Example in JSON:

   "stream-xpath-filter":
 "/ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip:ipv4"



Alternative B:
--

Use a non-context depending encoding, with the module name as prefix.

We would do in SN:

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

Pro: the format is independent from the protocol encoding

Con: in XML, this leaf is treated differently from other XPath
  expressions, such as get-config filter and nacm rules.

Example in XML:

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

Example in JSON:

   "stream-xpath-filter":
 "/ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip:ipv4"


My proposal is A.  I think it is more important with consistency
within each encoding than across encodings.

(This said, I would like to have a context-independent encoding of all
YANG types in the future.  But not now.)




/martin

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



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

Re: [netmod] xpath expressions in JSON

[Ladislav Lhotka]

On Thu, 2018-10-18 at 12:30 +0200, Martin Bjorklund wrote:
> Hi,
> 
> Going back to the most urgent issue, what is this WG's recommendation
> for the subscribed-notifications draft in NETCONF wrt/ their usage of
> yang:xpath1.0 in filters?
> 
> To summarize:
> 
> We already have
> 
>   o  instance-identifier in XML uses prefixes from the XML document
>   o  instance-identifier in JSON uses module names as prefixes
>   o  XPath in NETCONF filter uses prefixes from the XML document
>   o  XPath in JSON query filter uses module names as prefixes

Actually, schema mount uses yet another approach - prefix/namespace mapping is a
part of the data itself:

+--ro namespace* [prefix]
|  +--ro prefixyang:yang-identifier
|  +--ro uri?  inet:uri

It could work here, too.

Lada

> 
> 
> Alternative A:
> --
> 
> Use different encodings for "stream-xpath-filter" as well, depending
> on if it is XML or JSON.
> 
> We would do in SN:
> 
> o  If the node is encoded in XML, the set of namespace
>declarations are those in scope on the
>'stream-xpath-filter' leaf element.
> 
> o  If the node is encoded in JSON, 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.
> 
> Pro: the format is consistent within each encoding.
> 
> Con: unclear how to handle other encodings.
> Con: we keep using context-depending encodings.
> 
> We could probably add that CBOR uses the same representation as JSON.
> 
> Example in XML:
> 
>  xmlns:if="urn:ietf:params:xml:ns:yang:ietf-interfaces"
>   xmlns:ip="urn:ietf:params:xml:ns:yang:ietf-ip">
> /if:interfaces/if:interface/ip:ipv4
>   
> 
> Example in JSON:
> 
>   "stream-xpath-filter":
> "/ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip:ipv4"
> 
> 
> 
> Alternative B:
> --
> 
> Use a non-context depending encoding, with the module name as prefix.
> 
> We would do in SN:
> 
> o  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.
> 
> Pro: the format is independent from the protocol encoding
> 
> Con: in XML, this leaf is treated differently from other XPath
>  expressions, such as get-config filter and nacm rules.
> 
> Example in XML:
> 
>   
> /ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip:ipv4
>   
> 
> Example in JSON:
> 
>   "stream-xpath-filter":
> "/ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip:ipv4"
> 
> 
> My proposal is A.  I think it is more important with consistency
> within each encoding than across encodings.
> 
> (This said, I would like to have a context-independent encoding of all
> YANG types in the future.  But not now.)
> 
> 
> 
> 
> /martin
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

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

Re: [netmod] xpath expressions in JSON

[Martin Bjorklund]

Hi,

Going back to the most urgent issue, what is this WG's recommendation
for the subscribed-notifications draft in NETCONF wrt/ their usage of
yang:xpath1.0 in filters?

To summarize:

We already have

  o  instance-identifier in XML uses prefixes from the XML document
  o  instance-identifier in JSON uses module names as prefixes
  o  XPath in NETCONF filter uses prefixes from the XML document
  o  XPath in JSON query filter uses module names as prefixes


Alternative A:
--

Use different encodings for "stream-xpath-filter" as well, depending
on if it is XML or JSON.

We would do in SN:

o  If the node is encoded in XML, the set of namespace
   declarations are those in scope on the
   'stream-xpath-filter' leaf element.

o  If the node is encoded in JSON, 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.

Pro: the format is consistent within each encoding.

Con: unclear how to handle other encodings.
Con: we keep using context-depending encodings.

We could probably add that CBOR uses the same representation as JSON.

Example in XML:

  
/if:interfaces/if:interface/ip:ipv4
  

Example in JSON:

  "stream-xpath-filter":
"/ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip:ipv4"



Alternative B:
--

Use a non-context depending encoding, with the module name as prefix.

We would do in SN:

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

Pro: the format is independent from the protocol encoding

Con: in XML, this leaf is treated differently from other XPath
 expressions, such as get-config filter and nacm rules.

Example in XML:

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

Example in JSON:

  "stream-xpath-filter":
"/ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip:ipv4"


My proposal is A.  I think it is more important with consistency
within each encoding than across encodings.

(This said, I would like to have a context-independent encoding of all
YANG types in the future.  But not now.)




/martin

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

Re: [netmod] WG LC draft-ietf-netmod-module-tags-02 - 10/2/18 - 10/16/18

[Christian Hopps]

A router has no use for it's capability/feature/deviation advertisements 
either; module-tags are no different in this respect.

Thanks,
Chris.

Alex Campbell  writes:


Hi,


The server implements the tags (at least the predefined ones), and the use 
cases that come to my mind at least involve clients not servers.


I assume that the server here is a network element implementing 
ietf-module-tags.

I still don't see why network elements should implement ietf-module-tags.
What benefit is gained from storing the tags on the server instead of the 
client? It seems backwards.

Have I misunderstood? I assumed that ietf-module-tags was meant to be 
implemented by network elements that are NETCONF servers - but now I see the 
document doesn't actually specify who is meant to implement the module. Your 
comment about newly installed routers supports my understanding however.


I'm a bit confused by this. Not having to go add e.g., an "OAM" tag to modules 
is exactly the point of pre-defined tags, but you questioned their value at the top of 
your mail.


The problem with pre-defined tags is that they are never complete. I can always 
find a useful tag that is not pre-defined.


Either way configuring a newly installed router is a given, I don't think this is the 
place to solve the "forgot to add all the config to my new router install" 
issue. :) If one is using tags in ones network then making sure the newly installed 
router has tags configured the way you expect is no different from making sure that you 
configured IS-IS correctly.


The reason I find this problematic is the same as above - that the router has 
no use for the tag data.
It's as if my PC were to download its keyboard mapping table from my home 
router. Then I change ISPs and have to swap the router, and suddenly my 
keyboard doesn't work correctly.
It would be much better to store the keyboard mapping table for my PC *on my 
PC* instead of adding needless external dependencies.

Alex



From: Christian Hopps 
Sent: Wednesday, 17 October 2018 9:56 p.m.
To: Alex Campbell
Cc: Christian Hopps; joel jaeggli; NETMOD Working Group
Subject: Re: [netmod] WG LC draft-ietf-netmod-module-tags-02 - 10/2/18 - 
10/16/18

The point is to keep this open to however the community might end up choosing 
to use it. The act of pre-defining tags doesn't disallow other tags being 
defined, in fact at this point I've sent a bunch of email defending leaving 
things as open as possible. They both can co-exist. :)

Thanks,
Chris.


On Oct 16, 2018, at 7:32 PM, Alex Campbell  wrote:

I have no issue with systems using tags to classify or organize modules, 
however this seems to me like something that would be specific to the system 
doing the classifying.


Sure we support this. That's what user tag configuration is there for.


It would not be something that needs to be specified in the module itself 
(except perhaps as freeform description text), and it certainly would not need 
to involve the NETCONF server.
What would a server do with module classification data? (unless it is also 
implementing some kind of module browsing interface, in which case it might be 
used to supply the browser with data)


The server implements the tags (at least the predefined ones), and the use 
cases that come to my mind at least involve clients not servers. I'm not saying 
there wouldn't be a server use case, but it's not as obvious to me.

And yes implementing some kind of module browsing interface (which could group 
modules by tags) is a fine example of how tags can be used.



Hashtags - all types, that I'm aware of - are inherently freeform and fluid, changing 
quickly according to the desires of users. I don't think it makes sense to 
"hard-code" them in published RFCs or even published vendor modules or firmware.

Tomorrow, I might want to list all modules for management plane protocols. As a 
network operator, should I go and update the ietf-module-tags on all of my 
network elements? That seems silly. This should be client-side data. (And if I 
did, what happens when I add a new router and forget to update its tag data? 
Will that confuse the client?)


I'm a bit confused by this. Not having to go add e.g., an "OAM" tag to modules 
is exactly the point of pre-defined tags, but you questioned their value at the top of 
your mail.

Either way configuring a newly installed router is a given, I don't think this is the 
place to solve the "forgot to add all the config to my new router install" 
issue. :) If one is using tags in ones network then making sure the newly installed 
router has tags configured the way you expect is no different from making sure that you 
configured IS-IS correctly.

Thanks,
Chris.



Regards, Alex


From: Christian Hopps 
Sent: Wednesday, 17 October 2018 1:04 a.m.
To: Alex Campbell
Cc: Christian Hopps; joel jaeggli; NETMOD Working Group
Subject: Re: [netmod] WG LC