Re: [netmod] xpath expressions in JSON

[Qin Wu]

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

On Mon, 2018-10-22 at 14:56 +0200, Martin Bjorklund wrote:
> Ladislav Lhotka  wrote:
> > Martin Bjorklund  writes:
> > 
> > > 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
> > 
> > Is "supported" the same as "implemented", or something else?
> 
> It should be "implemented".
> 
> > >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.
> > 
> >   Con: XPath expressions in JSON can get pretty long (I assume it's not
> >   just an instance identifier but may contain predicates etc.). We
> >   cannot use the trick with the default namespace as in YANG, so all
> >   data node names will have to carry the prefix.
> 
> Yes.
> 
> > > 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.
> > 
> > I would suggest to consider declaring prefixes & namespaces 
> > explicitly in the data, as in the schema mount document. It is 
> > independent of encoding and the expressions can be kept short. In 
> > fact, one of the namespaces can be declared as default, so this use 
> > of XPath would then be very similar to YANG.
> 
> Ok, so this is another alternative that works today, and achieves the 
> goal of being encoding-independent.  It is still context-dependent 
> though.

Yes, every module that uses XPath in data will have to deal with this. There 
may potentially be multiple independent prefix declarations (this is actually a 
con). 

> 
> BTW, when used in filters, it is nice to let an unprefixed name to 
> match any namespace; i.e., treat "foo" as syntactic sugar for
> "local-name(.) = 'foo'".  ("*:foo" is not legal...)

Hmm, I think this is a bad idea because it departs even further from the 
original XPath semantics. Such chameleon names should IMO be pretty rare, and 
if they are needed, local-name() is always available.

[Qin]: Agree with Lada, Referencing RFC8407, section 4.6.2, I think the below 
guideline is relevant.
"
The "local-name" function SHOULD NOT be used to reference local names
   outside of the YANG module that defines the must or when expression
   containing the "local-name" 

Re: [netmod] yang-data issues

[Qin Wu]

-邮件原件-
发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Kent Watsen
发送时间: 2018年10月20日 20:49
收件人: netmod@ietf.org
主题: Re: [netmod] yang-data issues

Folks,

Can we get some quick replies to this email?

[Qin]: I believe restconf collection work might benefit from this work as well. 
It follows traditional usages of rc:yang-data,
However I am not sure the benefit to remove container defined within yang-data 
extension, the restrict ion I see this,
In traditional usage of yang-data, we can add more than one containers, then 
augment-yang-data can augment from any of these containers 
defined within yang-data extension.
But with below proposal, we lose such flexibility, in my opinion.

Kent // all hats




-Original Message-
From: netmod  on behalf of Martin Bjorklund 

Date: Tuesday, September 11, 2018 at 4:45 AM
To: "netmod@ietf.org" 
Subject: [netmod] yang-data issues

Hi,

The authors of draft-ietf-netmod-yang-data-ext have been discussing the two 
remaining issues on this draft; the issue of whether a yang-data structure must 
have unique top-level node names or not, and the issue of the syntax for 
augment-yang-data.  We haven't been able to find agreement with the current 
proposal, so I have a suggestion for a slightly modified yang-data statement 
(which may have been discussed before):

The idea is to encode a yang-data extension the same way as anydata, i.e., as a 
container.  For example:

  yd:yang-data modify-subscription-datastore-error-info {
  description
"This yang-data MAY be provided as part of a subscription's RPC
error response when there is a failure of a
'modify-subscription' RPC which has been made against a
datastore.  This yang-data MUST be used if hints are to be
provides back to the subscriber.";
  leaf reason {
type identityref {
  base sn:modify-subscription-error;
}
description
  "Indicates the reason why the subscription has failed to
  be modified.";
  }
  uses hints;
}

This would be encoded as:

  
foo
42
...
  


Since the structure is always encoded as a container, it follows that it can 
have any data definition statement as substatement, with no restriction on 
naming and type of statement.  An instance of this can trivially be a complete 
instance document in XML w/o additional context, works well with JSON, and can 
appear in an error-info structure.

Such a structure can be augemented as:

  yd:augment-yang-data /sn:modify-subscription-datastore-error-info {
leaf foo { ... }
  }

The drawback is that it forces the use of an extra container in the encoding.  
OTOH, most usages of current rc:yang-data follows this
pattern:

  rc:yang-data modify-subscription-datastore-error-info {
container modify-subscription-datastore-error-info {
  ...
}
  }
  



/martin

___
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=7nlVu5dJaa8XsD0LRd0VTH301caVRUXGsa6L-UgXVRE=1o7vXH-j8Ha6xbJFTG1jjNzy9JQw7k-UWIqpeCr8qrk=

___
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

[Wubo (lana)]

Yes/support.

Bo

> -邮件原件-
> 发件人: netmod [mailto:netmod-boun...@ietf.org] 代表
> Lou Berger
> 发送时间: 2018年10月18日 21:13
> 收件人: NetMod WG 
> 抄送: NetMod WG Chairs 
> 主题: Re: [netmod] WG adoption poll draft-kwatsen-
> netmod-artwork-folding-08
> 
> 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
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] yang-data issues

[Joe Clarke]

On 10/22/18 13:41, Andy Bierman wrote:
> 
> 
> On Sat, Oct 20, 2018 at 5:48 AM, Kent Watsen  > wrote:
> 
> Folks,
> 
> Can we get some quick replies to this email?
> 
> 
> 
> At the last IETF there were people that said both yang-data and
> augment-yang-data extensions
> were needed and they wanted this work to be completed quickly.  Is that
> still the case?

Yes.  We're now seeing people that want to augment the ANIMA voucher
artifact (draft just proposed by Eliot Lear).  I have some non-IETF work
that would also benefit.

Joe

> 
> 
> IMO, NMDA and yang-library-bis offer a better solution path (which has
> been brought up before).
> If there is a need for specialized datastores like "factory-default"
> then why not have
> an abstract datastore or abstract module-set?  I do not think current
> YANG supports this
> approach very well (because modules used outside a server do not have
> yang-library)
> but that could probably be fixed with yang-instance-data
> 
> 
> Kent // all hats
> 
> 
> 
> 
> Andy
>  
> 
> 
> 
> -Original Message-
> From: netmod  > on behalf of Martin Bjorklund
> mailto:m...@tail-f.com>>
> Date: Tuesday, September 11, 2018 at 4:45 AM
> To: "netmod@ietf.org "  >
> Subject: [netmod] yang-data issues
> 
> Hi,
> 
> The authors of draft-ietf-netmod-yang-data-ext have been discussing
> the two remaining issues on this draft; the issue of whether a
> yang-data structure must have unique top-level node names or not, and
> the issue of the syntax for augment-yang-data.  We haven't been able
> to find agreement with the current proposal, so I have a suggestion
> for a slightly modified yang-data statement (which may have been
> discussed before):
> 
> The idea is to encode a yang-data extension the same way as anydata,
> i.e., as a container.  For example:
> 
>   yd:yang-data modify-subscription-datastore-error-info {
>       description
>         "This yang-data MAY be provided as part of a subscription's RPC
>         error response when there is a failure of a
>         'modify-subscription' RPC which has been made against a
>         datastore.  This yang-data MUST be used if hints are to be
>         provides back to the subscriber.";
>       leaf reason {
>         type identityref {
>           base sn:modify-subscription-error;
>         }
>         description
>           "Indicates the reason why the subscription has failed to
>           be modified.";
>       }
>       uses hints;
>     }
> 
> This would be encoded as:
> 
>   
>     foo
>     42
>     ...
>   
> 
> 
> Since the structure is always encoded as a container, it follows that
> it can have any data definition statement as substatement, with no
> restriction on naming and type of statement.  An instance of this can
> trivially be a complete instance document in XML w/o additional
> context, works well with JSON, and can appear in an error-info
> structure.
> 
> Such a structure can be augemented as:
> 
>   yd:augment-yang-data /sn:modify-subscription-datastore-error-info {
>     leaf foo { ... }
>   }
> 
> The drawback is that it forces the use of an extra container in the
> encoding.  OTOH, most usages of current rc:yang-data follows this
> pattern:
> 
>   rc:yang-data modify-subscription-datastore-error-info {
>     container modify-subscription-datastore-error-info {
>       ...
>     }
>   }
> 
> 
> 
> 
> /martin
> 
> ___
> 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=7nlVu5dJaa8XsD0LRd0VTH301caVRUXGsa6L-UgXVRE=1o7vXH-j8Ha6xbJFTG1jjNzy9JQw7k-UWIqpeCr8qrk=
> 
> 
> 
> ___
> 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] yang-data issues

[Andy Bierman]

On Sat, Oct 20, 2018 at 5:48 AM, Kent Watsen  wrote:

> Folks,
>
> Can we get some quick replies to this email?
>
>

At the last IETF there were people that said both yang-data and
augment-yang-data extensions
were needed and they wanted this work to be completed quickly.  Is that
still the case?


IMO, NMDA and yang-library-bis offer a better solution path (which has been
brought up before).
If there is a need for specialized datastores like "factory-default" then
why not have
an abstract datastore or abstract module-set?  I do not think current YANG
supports this
approach very well (because modules used outside a server do not have
yang-library)
but that could probably be fixed with yang-instance-data


Kent // all hats
>
>
>

Andy


>
>
> -Original Message-
> From: netmod  on behalf of Martin Bjorklund <
> m...@tail-f.com>
> Date: Tuesday, September 11, 2018 at 4:45 AM
> To: "netmod@ietf.org" 
> Subject: [netmod] yang-data issues
>
> Hi,
>
> The authors of draft-ietf-netmod-yang-data-ext have been discussing
> the two remaining issues on this draft; the issue of whether a
> yang-data structure must have unique top-level node names or not, and
> the issue of the syntax for augment-yang-data.  We haven't been able
> to find agreement with the current proposal, so I have a suggestion
> for a slightly modified yang-data statement (which may have been
> discussed before):
>
> The idea is to encode a yang-data extension the same way as anydata,
> i.e., as a container.  For example:
>
>   yd:yang-data modify-subscription-datastore-error-info {
>   description
> "This yang-data MAY be provided as part of a subscription's RPC
> error response when there is a failure of a
> 'modify-subscription' RPC which has been made against a
> datastore.  This yang-data MUST be used if hints are to be
> provides back to the subscriber.";
>   leaf reason {
> type identityref {
>   base sn:modify-subscription-error;
> }
> description
>   "Indicates the reason why the subscription has failed to
>   be modified.";
>   }
>   uses hints;
> }
>
> This would be encoded as:
>
>   
> foo
> 42
> ...
>   
>
>
> Since the structure is always encoded as a container, it follows that
> it can have any data definition statement as substatement, with no
> restriction on naming and type of statement.  An instance of this can
> trivially be a complete instance document in XML w/o additional
> context, works well with JSON, and can appear in an error-info
> structure.
>
> Such a structure can be augemented as:
>
>   yd:augment-yang-data /sn:modify-subscription-datastore-error-info {
> leaf foo { ... }
>   }
>
> The drawback is that it forces the use of an extra container in the
> encoding.  OTOH, most usages of current rc:yang-data follows this
> pattern:
>
>   rc:yang-data modify-subscription-datastore-error-info {
> container modify-subscription-datastore-error-info {
>   ...
> }
>   }
>
>
>
>
> /martin
>
> ___
> 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=
> 7nlVu5dJaa8XsD0LRd0VTH301caVRUXGsa6L-UgXVRE=1o7vXH-
> j8Ha6xbJFTG1jjNzy9JQw7k-UWIqpeCr8qrk=
>
> ___
> 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] I-D Action: draft-ietf-netmod-nmda-diff-00.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network Modeling WG of the IETF.

Title   : Comparison of NMDA datastores
Authors : Alexander Clemm
  Yingzhen Qu
  Jeff Tantsura
  Andy Bierman
Filename: draft-ietf-netmod-nmda-diff-00.txt
Pages   : 14
Date: 2018-10-21

Abstract:
   This document defines an RPC operation to compare management
   datastores that comply with the NMDA architecture.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-nmda-diff/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-netmod-nmda-diff-00
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-nmda-diff-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/

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

Re: [netmod] xpath expressions in JSON

[Ladislav Lhotka]

On Mon, 2018-10-22 at 14:56 +0200, Martin Bjorklund wrote:
> Ladislav Lhotka  wrote:
> > Martin Bjorklund  writes:
> > 
> > > 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
> > 
> > Is "supported" the same as "implemented", or something else?
> 
> It should be "implemented".
> 
> > >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.
> > 
> >   Con: XPath expressions in JSON can get pretty long (I assume it's not
> >   just an instance identifier but may contain predicates etc.). We
> >   cannot use the trick with the default namespace as in YANG, so all
> >   data node names will have to carry the prefix.
> 
> Yes.
> 
> > > 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.
> > 
> > I would suggest to consider declaring prefixes & namespaces explicitly
> > in the data, as in the schema mount document. It is independent of
> > encoding and the expressions can be kept short. In fact, one of the
> > namespaces can be declared as default, so this use of XPath would then
> > be very similar to YANG.
> 
> Ok, so this is another alternative that works today, and achieves the
> goal of being encoding-independent.  It is still context-dependent
> though.

Yes, every module that uses XPath in data will have to deal with this. There may
potentially be multiple independent prefix declarations (this is actually a
con). 

> 
> BTW, when used in filters, it is nice to let an unprefixed name to
> match any namespace; i.e., treat "foo" as syntactic sugar for
> "local-name(.) = 'foo'".  ("*:foo" is not legal...)

Hmm, I think this is a bad idea because it departs even further from the
original XPath semantics. Such chameleon names should IMO be pretty rare, and if
they are needed, local-name() is always available.

Lada

> 
> 
> /martin
> 
> 
> 
> 
> 
> > 
> > Lada
> > 
> > >
> > > (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
> > 
-- 

Re: [netmod] xpath expressions in JSON

[Martin Bjorklund]

Ladislav Lhotka  wrote:
> Martin Bjorklund  writes:
> 
> > 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
> 
> Is "supported" the same as "implemented", or something else?

It should be "implemented".

> >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.
> 
>   Con: XPath expressions in JSON can get pretty long (I assume it's not
>   just an instance identifier but may contain predicates etc.). We
>   cannot use the trick with the default namespace as in YANG, so all
>   data node names will have to carry the prefix.

Yes.

> > 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.
> 
> I would suggest to consider declaring prefixes & namespaces explicitly
> in the data, as in the schema mount document. It is independent of
> encoding and the expressions can be kept short. In fact, one of the
> namespaces can be declared as default, so this use of XPath would then
> be very similar to YANG.

Ok, so this is another alternative that works today, and achieves the
goal of being encoding-independent.  It is still context-dependent
though.

BTW, when used in filters, it is nice to let an unprefixed name to
match any namespace; i.e., treat "foo" as syntactic sugar for
"local-name(.) = 'foo'".  ("*:foo" is not legal...)


/martin





> 
> Lada
> 
> >
> > (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] WG adoption poll (draft-lengyel-netmod-yang-instance-data)

[Lou Berger]

This poll is now closed and the draft is adopted.  As usual, this draft 
will now be progressed through normal working group process, including 
addressing issues raised during and after adoption.


Authors,

Please submit draft-lengyel-netmod-yang-instance-data-05.txt with only 
the date updated and the file name changed to 
draft-ietf-netmod-yang-instance-file-format-00.txt.  Please note the 
file name change.  If you object to this change please propose an 
alternative.


Thank you,

Lou (and co-chairs)


On 10/8/2018 7:38 AM, 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 addressed once the document is a WG document.

The poll ends Oct 22.

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] New Version Notification for draft-wu-netmod-factory-default-01.txt

[Qin Wu]

发件人: Rohit R Ranade
发送时间: 2018年10月22日 17:39
收件人: Qin Wu; Balázs Lengyel; netmod@ietf.org
主题: RE: New Version Notification for draft-wu-netmod-factory-default-01.txt


6.   Since we have scenario of copy to multiple targets, whether we can add 
a leaf called the error-option with possible values of 
“stop-on-error/continue-on-error/rollback-on-error”   ?

   [Qin]: Same as above. Should these error-option values be part of rpc-reply 
or part of operation request? By reading edit-config,it is also not clear to me 
whether

   Error-option should be part of edit-config operation that is sent in 
rpc-request message.


[Rohit]  is an input to the edit-config rpc-request.   So I 
suggested to have a similar approach. But this multi-datastore copy will be 
tricky because if we give two targets say  /  and if after 
copy to , copy to  fails,  then how to handle this ?  Revert 
 config ?

[Qin]: Understand your concern, but I think the new operation can be handled in 
the same way as  in RFC6241, I see no error handling to be 
specified for .
In addition, rpc-reply can be used to carry these error-option information and 
indicate failure reason.

With Regards,
Rohit R


From: Qin Wu
Sent: 22 October 2018 12:25
To: Rohit R Ranade mailto:rohitrran...@huawei.com>>; 
Balázs Lengyel 
mailto:balazs.leng...@ericsson.com>>; 
netmod@ietf.org
Subject: RE: New Version Notification for draft-wu-netmod-factory-default-01.txt

Thanks Rohit, see reply inline below.

发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Rohit R Ranade
发送时间: 2018年10月22日 12:59
收件人: Balázs Lengyel; netmod@ietf.org
主题: Re: [netmod] New Version Notification for 
draft-wu-netmod-factory-default-01.txt

Some suggestions,



1.   In YANG module, the identity has name as “factory-default”, but many 
places  the name "factory-default-running" is used. I suggest we used 
“factory-default”in all places.

[Qin]: works for me.

2.   This YANG module is importing ietf-netconf module. I suggest that this 
import should be removed as this module should not have dependencies on NETCONF.

[Qin]: Good catch, thanks.

3.   The description of this YANG module, still has the reference to 
.  Whether this can be removed ?

[Qin]: Good catch, thanks.

4.   The description of the indentity “factory-default”, suggest to 
describe the identity rather than tell “how” it can be used.

[Qin]: Okay.

5.   Whether we can also add the statement that if the “target-datastore”, 
have been locked , then the reset-datastore will fail with the  
value as “in-use” ?

[Qin]: I think we can reuse  in the rpc-error element, similar to 
example in section 7.5 of RFC6241.

6.   Since we have scenario of copy to multiple targets, whether we can add 
a leaf called the error-option with possible values of 
“stop-on-error/continue-on-error/rollback-on-error”   ?

   [Qin]: Same as above. Should these error-option values be part of rpc-reply 
or part of operation request? By reading edit-config,it is also not clear to me 
whether

   Error-option should be part of edit-config operation that is sent in 
rpc-request message.

With Regards,

Rohit R

From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Balázs Lengyel
Sent: 19 October 2018 18:17
To: netmod@ietf.org
Subject: [netmod] Fwd: New Version Notification for 
draft-wu-netmod-factory-default-01.txt


Hello,

A new version of I-D, draft-wu-netmod-factory-default-01.txt has been uploaded. 
Changes include:
Removed impacts to  as the reset-datastore  RPC can anyway do the 
same thing.
Explained the difference between startup and factory-default datastores
Small corrections.

regards Balazs

 Forwarded Message 
Subject:

New Version Notification for draft-wu-netmod-factory-default-01.txt

Date:

Fri, 19 Oct 2018 05:30:05 -0700

From:

internet-dra...@ietf.org

To:

Ye Niu , Qin Wu 
, Balazs Lengyel 





A new version of I-D, draft-wu-netmod-factory-default-01.txt
has been successfully submitted by Balazs Lengyel and posted to the
IETF repository.

Name: draft-wu-netmod-factory-default
Revision: 01
Title: Factory default Setting
Document date: 2018-10-19
Group: Individual Submission
Pages: 10
URL: https://www.ietf.org/internet-drafts/draft-wu-netmod-factory-default-01.txt
Status: https://datatracker.ietf.org/doc/draft-wu-netmod-factory-default/
Htmlized: https://tools.ietf.org/html/draft-wu-netmod-factory-default-01
Htmlized: https://datatracker.ietf.org/doc/html/draft-wu-netmod-factory-default
Diff: https://www.ietf.org/rfcdiff?url2=draft-wu-netmod-factory-default-01

Abstract:
This document defines a method to reset a YANG datastore to its
factory-default content. The reset operation may be used e.g. during
initial zero-touch configuration or when the existing configuration
has major errors, so 

Re: [netmod] New Version Notification for draft-wu-netmod-factory-default-01.txt

[Rohit R Ranade]

6.   Since we have scenario of copy to multiple targets, whether we can add 
a leaf called the error-option with possible values of 
“stop-on-error/continue-on-error/rollback-on-error”   ?

   [Qin]: Same as above. Should these error-option values be part of rpc-reply 
or part of operation request? By reading edit-config,it is also not clear to me 
whether

   Error-option should be part of edit-config operation that is sent in 
rpc-request message.


[Rohit]  is an input to the edit-config rpc-request.   So I 
suggested to have a similar approach. But this multi-datastore copy will be 
tricky because if we give two targets say  /  and if after 
copy to , copy to  fails,  then how to handle this ?  Revert 
 config ?

I suggest to restrict the copy of factory datastore to a single target 
datastore for now.
With Regards,
Rohit R


From: Qin Wu
Sent: 22 October 2018 12:25
To: Rohit R Ranade ; Balázs Lengyel 
; netmod@ietf.org
Subject: RE: New Version Notification for draft-wu-netmod-factory-default-01.txt

Thanks Rohit, see reply inline below.

发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Rohit R Ranade
发送时间: 2018年10月22日 12:59
收件人: Balázs Lengyel; netmod@ietf.org
主题: Re: [netmod] New Version Notification for 
draft-wu-netmod-factory-default-01.txt

Some suggestions,



1.   In YANG module, the identity has name as “factory-default”, but many 
places  the name "factory-default-running" is used. I suggest we used 
“factory-default”in all places.

[Qin]: works for me.

2.   This YANG module is importing ietf-netconf module. I suggest that this 
import should be removed as this module should not have dependencies on NETCONF.

[Qin]: Good catch, thanks.

3.   The description of this YANG module, still has the reference to 
.  Whether this can be removed ?

[Qin]: Good catch, thanks.

4.   The description of the indentity “factory-default”, suggest to 
describe the identity rather than tell “how” it can be used.

[Qin]: Okay.

5.   Whether we can also add the statement that if the “target-datastore”, 
have been locked , then the reset-datastore will fail with the  
value as “in-use” ?

[Qin]: I think we can reuse  in the rpc-error element, similar to 
example in section 7.5 of RFC6241.

6.   Since we have scenario of copy to multiple targets, whether we can add 
a leaf called the error-option with possible values of 
“stop-on-error/continue-on-error/rollback-on-error”   ?

   [Qin]: Same as above. Should these error-option values be part of rpc-reply 
or part of operation request? By reading edit-config,it is also not clear to me 
whether

   Error-option should be part of edit-config operation that is sent in 
rpc-request message.

With Regards,

Rohit R

From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Balázs Lengyel
Sent: 19 October 2018 18:17
To: netmod@ietf.org
Subject: [netmod] Fwd: New Version Notification for 
draft-wu-netmod-factory-default-01.txt


Hello,

A new version of I-D, draft-wu-netmod-factory-default-01.txt has been uploaded. 
Changes include:
Removed impacts to  as the reset-datastore  RPC can anyway do the 
same thing.
Explained the difference between startup and factory-default datastores
Small corrections.

regards Balazs

 Forwarded Message 
Subject:

New Version Notification for draft-wu-netmod-factory-default-01.txt

Date:

Fri, 19 Oct 2018 05:30:05 -0700

From:

internet-dra...@ietf.org

To:

Ye Niu , Qin Wu 
, Balazs Lengyel 





A new version of I-D, draft-wu-netmod-factory-default-01.txt
has been successfully submitted by Balazs Lengyel and posted to the
IETF repository.

Name: draft-wu-netmod-factory-default
Revision: 01
Title: Factory default Setting
Document date: 2018-10-19
Group: Individual Submission
Pages: 10
URL: https://www.ietf.org/internet-drafts/draft-wu-netmod-factory-default-01.txt
Status: https://datatracker.ietf.org/doc/draft-wu-netmod-factory-default/
Htmlized: https://tools.ietf.org/html/draft-wu-netmod-factory-default-01
Htmlized: https://datatracker.ietf.org/doc/html/draft-wu-netmod-factory-default
Diff: https://www.ietf.org/rfcdiff?url2=draft-wu-netmod-factory-default-01

Abstract:
This document defines a method to reset a YANG datastore to its
factory-default content. The reset operation may be used e.g. during
initial zero-touch configuration or when the existing configuration
has 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.



Please note that it may take a couple of minutes from the time of submission
until the htmlized 

Re: [netmod] New Version Notification for draft-wu-netmod-factory-default-01.txt

[Qin Wu]

Thanks Rohit, see reply inline below.

发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Rohit R Ranade
发送时间: 2018年10月22日 12:59
收件人: Balázs Lengyel; netmod@ietf.org
主题: Re: [netmod] New Version Notification for 
draft-wu-netmod-factory-default-01.txt

Some suggestions,



1.   In YANG module, the identity has name as “factory-default”, but many 
places  the name "factory-default-running" is used. I suggest we used 
“factory-default”in all places.

[Qin]: works for me.

2.   This YANG module is importing ietf-netconf module. I suggest that this 
import should be removed as this module should not have dependencies on NETCONF.

[Qin]: Good catch, thanks.

3.   The description of this YANG module, still has the reference to 
.  Whether this can be removed ?

[Qin]: Good catch, thanks.

4.   The description of the indentity “factory-default”, suggest to 
describe the identity rather than tell “how” it can be used.

[Qin]: Okay.

5.   Whether we can also add the statement that if the “target-datastore”, 
have been locked , then the reset-datastore will fail with the  
value as “in-use” ?

[Qin]: I think we can reuse  in the rpc-error element, similar to 
example in section 7.5 of RFC6241.

6.   Since we have scenario of copy to multiple targets, whether we can add 
a leaf called the error-option with possible values of 
“stop-on-error/continue-on-error/rollback-on-error”   ?

   [Qin]: Same as above. Should these error-option values be part of rpc-reply 
or part of operation request? By reading edit-config,it is also not clear to me 
whether

   Error-option should be part of edit-config operation that is sent in 
rpc-request message.

With Regards,

Rohit R

From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Balázs Lengyel
Sent: 19 October 2018 18:17
To: netmod@ietf.org
Subject: [netmod] Fwd: New Version Notification for 
draft-wu-netmod-factory-default-01.txt


Hello,

A new version of I-D, draft-wu-netmod-factory-default-01.txt has been uploaded. 
Changes include:
Removed impacts to  as the reset-datastore  RPC can anyway do the 
same thing.
Explained the difference between startup and factory-default datastores
Small corrections.

regards Balazs

 Forwarded Message 
Subject:

New Version Notification for draft-wu-netmod-factory-default-01.txt

Date:

Fri, 19 Oct 2018 05:30:05 -0700

From:

internet-dra...@ietf.org

To:

Ye Niu , Qin Wu 
, Balazs Lengyel 





A new version of I-D, draft-wu-netmod-factory-default-01.txt
has been successfully submitted by Balazs Lengyel and posted to the
IETF repository.

Name: draft-wu-netmod-factory-default
Revision: 01
Title: Factory default Setting
Document date: 2018-10-19
Group: Individual Submission
Pages: 10
URL: https://www.ietf.org/internet-drafts/draft-wu-netmod-factory-default-01.txt
Status: https://datatracker.ietf.org/doc/draft-wu-netmod-factory-default/
Htmlized: https://tools.ietf.org/html/draft-wu-netmod-factory-default-01
Htmlized: https://datatracker.ietf.org/doc/html/draft-wu-netmod-factory-default
Diff: https://www.ietf.org/rfcdiff?url2=draft-wu-netmod-factory-default-01

Abstract:
This document defines a method to reset a YANG datastore to its
factory-default content. The reset operation may be used e.g. during
initial zero-touch configuration or when the existing configuration
has 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.



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.

The IETF Secretariat

--

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