date:20181023

Re: [netmod] IANA Considerations

2018-10-23 Thread Martin Bjorklund

Martin Bjorklund  wrote:
> Juergen Schoenwaelder  wrote:
> > Tom,
> > 
> > the IANA registry has this field, I assume it got introduced when IANA
> > started to maintain their own modules and needed a flag to distinguish
> > them from other modules. Martin may know more. If you think this is a
> > problem, the authors can remove 'Maintained by IANA?: N' strictly
> > following RFC 6020 and IANA will then add this bit later during the
> > IANA processing.
> 
> I don't know more.  I will check with IANA.

This column was apparanently added by IANA after being requested by
Benoit.  IANA does not require draft authors to include this column;
they will populate it themselves (if the module is intended to be
maintained by IANA this will be described in the IANA Considerations
section, and the module is probably called iana-something).

/martin

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

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

2018-10-23 Thread Jeff Tantsura

Yes/support

Cheers,
Jeff
On Oct 18, 2018, 6:12 AM -0700, 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] IANA Considerations

2018-10-23 Thread Martin Bjorklund

Juergen Schoenwaelder  wrote:
> Tom,
> 
> the IANA registry has this field, I assume it got introduced when IANA
> started to maintain their own modules and needed a flag to distinguish
> them from other modules. Martin may know more. If you think this is a
> problem, the authors can remove 'Maintained by IANA?: N' strictly
> following RFC 6020 and IANA will then add this bit later during the
> IANA processing.

I don't know more.  I will check with IANA.


/martin


> 
> /js
> 
> On Tue, Oct 23, 2018 at 04:15:04PM +, tom petch wrote:
> > draft-ietf-ccamp-mw-yang-10
> > has, in IANA Considerations,
> >   Name: ietf-microwave-radio-link
> >   Maintained by IANA?: N
> >   Namespace: urn:ietf:params:xml:ns:yang:ietf-microwave-radio-link
> >   Prefix: mrl
> >   Reference: RFC 
> > which adds a line I have not seen before, not mentioned - naturally - in
> > RFC6020 or RFC7950 nor does it appear in e.g. RFC8407.
> > 
> > It seems like 'A Good Thing' but where has it come from, what is the
> > basis for it and is there a reference for it?  It could be construed as
> > a breach of RFC6020.
> > 
> > Tom Petch
> > 
> > ___
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> 
> -- 
> 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
> 

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

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

2018-10-23 Thread Kent Watsen



Hi Martin,

> one quick comment; the header used in the examples in
> section 8 isn't equal to the header defined in section 5.1


This is intentional.  Section 5.1 says:

   The first line is the following 46-character string that MAY be
   surrounded by any number of printable characters.

The rationalization here is:

  - scripts can easily center the text with equal amounts of some
chosen character.  The script in the Appendix, which was used
to fold examples 8.1 thru 8.4, uses '=' characters.

  - manual folding is difficult to center, and hence other framing
is more suitable.  For instance, the example in Section 8.5.

Kent // contributor



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

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

2018-10-23 Thread Kent Watsen

Correct, this document only defines a file format.

A separate effort will be needed to extend `xml2rfc` and `xym` and the like.

For those that wish to pre-fold their artwork prior to submitting the XML 
(hand-crafted folding --> max readability), the `xml2rfc` will not fold it 
again.

For those that prefer to submit the original artwork in the XML (which allows 
the unfolded artwork in other formats, e.g., HTML), `xml2rfc` will use an 
automatedly folding solution (for plain-text output only), most likely using 
the script in the appendix.

K.


-Original Message-
From: netmod  on behalf of Adrian Farrel 

Reply-To: "adr...@olddog.co.uk" 
Date: Tuesday, October 23, 2018 at 12:57 PM
To: 'Martin Bjorklund' , "lho...@nic.cz" 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] WG adoption poll draft-kwatsen-netmod-artwork-folding-08

Nicely said, Martin.
The intention is that if, like Ladislav, you like to work in some long-line
format, then it works as documented and the tools can wrap.
If, like me, and maybe like Martin, you think pretty formatting is something
that improves readability, the draft also lets you do that.

A

> -Original Message-
> From: Martin Bjorklund [mailto:m...@tail-f.com]
> Sent: 23 October 2018 17:04
> To: lho...@nic.cz
> Cc: adr...@olddog.co.uk; netmod@ietf.org
> Subject: Re: [netmod] WG adoption poll draft-kwatsen-netmod-artwork-folding-
> 08
> 
> Ladislav Lhotka  wrote:
> > On Tue, 2018-10-23 at 16:27 +0200, Martin Bjorklund wrote:
> > > Ladislav Lhotka  wrote:
> > > > On Tue, 2018-10-23 at 14:45 +0100, Adrian Farrel wrote:
> > > > > Hi,
> > > > >
> > > > > 1. I think you miss the point. While example XML/JSON YANG is included
> in
> > > > > drafts, and while the authors are allowed to produce those drafts as
txt
> > > > > files,
> > > > > or while the authors want to achieve pretty-to-read formatting, this
work
> > > > > falls
> > > > > into the scope of those authors.
> > > >
> > > > The folding of long lines should be done as the very last (automatic)
step
> > > > before the document gets published. Doing it earlier means that the
source
> > > code
> > > > in this folded form can be (accidentally) further edited, which can lead
to
> > > > inconsistencies.
> > >
> > > I will use folding e.g. for instance document examples in XML and
> > > JSON.
> > >
> > > My plan is to keep the example files with manually added breaks in my
> > > repo, and as part of validation run a script that unfolds the
> > > examples, and then validate the result.  The reason for this is that I
> > > think readbility of the examples is important.
> >
> > This seems backwards to me. If you need to edit such an example, you may
> have to
> > remove the backslashes, reformat and insert them again.
> >
> > If it's not possible to fold lines according to the syntax of a given
language,
> > I'd prefer to keep the original lines as long as possible and rely on an
> > automatic procedure just before the final document is rolled out.
> 
> Fortunately, the draft allows us both to work the way we prefer.
> 
> 
> /martin
> 
> 
> >
> > Lada
> >
> > >
> > >
> > > /martin
> > >
> > >
> > >
> > > >
> > > > As long as the document is being moved around and edited, it would be
> better
> > > to
> > > > keep the source code untouched.
> > > >
> > > > Lada
> > > >
> > > > >
> > > > > 2. Yes, the authors discussed the  element and agreed that
> it
> > > will
> > > > > be in scope.
> > > > >
> > > > > However, we are all sort of waiting for xml2rfc v3 and pending
completion,
> > > we
> > > > > want to move this forward for v2 that is in use today.
> > > > >
> > > > > (More than) Happy to come back and revisit this issue when v3 is
> deployed.
> > > > >
> > > > > Thanks,
> > > > > Adrian
> > > > >
> > > > > > -Original Message-
> > > > > > From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Ladislav
> > > Lhotka
> > > > > > Sent: 23 October 2018 14:24
> > > > > > To: netmod@ietf.org
> > > > > > Subject: Re: [netmod] WG adoption poll draft-kwatsen-netmod-
> artwork-
> > > folding-
> > > > > > 08
> > > > > >
> > > > > > On Tue, 2018-10-23 at 14:40 +0200, Ladislav Lhotka wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > > > I support the adoption.
> > > > > > >
> > > > > > > Comments:
> > > > > > >
> > > > > > > 1. My general feeling is that such technicalities should be
handled by
> > > > > > >the RFC editor and/or tools rather than YANG module and RFC
> > > authors.
> > > > > > >
> > > > > > > 2. xml2rfc v3 introduced a new element, , that is
> intended
> > > > > > >for source code inclusion. This document should therefore cover
> > > this
> > > > > > >element as well (primarily?). One problem with it is that the
> > > xml2rfc
> > > > > > >tool automatically adds the  and 
> markers,
> > > > > > >which interferes with YANG convention specified in RFC 8407,
> > > > > > >sec. 3.2. I have already raised a question about this in the
> > > > > > >xml2rfc-dev mailing list.
> > > >

Re: [netmod] IANA Considerations

2018-10-23 Thread Juergen Schoenwaelder

Tom,

the IANA registry has this field, I assume it got introduced when IANA
started to maintain their own modules and needed a flag to distinguish
them from other modules. Martin may know more. If you think this is a
problem, the authors can remove 'Maintained by IANA?: N' strictly
following RFC 6020 and IANA will then add this bit later during the
IANA processing.

/js

On Tue, Oct 23, 2018 at 04:15:04PM +, tom petch wrote:
> draft-ietf-ccamp-mw-yang-10
> has, in IANA Considerations,
>   Name: ietf-microwave-radio-link
>   Maintained by IANA?: N
>   Namespace: urn:ietf:params:xml:ns:yang:ietf-microwave-radio-link
>   Prefix: mrl
>   Reference: RFC 
> which adds a line I have not seen before, not mentioned - naturally - in
> RFC6020 or RFC7950 nor does it appear in e.g. RFC8407.
> 
> It seems like 'A Good Thing' but where has it come from, what is the
> basis for it and is there a reference for it?  It could be construed as
> a breach of RFC6020.
> 
> Tom Petch
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

-- 
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] WG adoption poll draft-kwatsen-netmod-artwork-folding-08

2018-10-23 Thread Adrian Farrel

Nicely said, Martin.
The intention is that if, like Ladislav, you like to work in some long-line
format, then it works as documented and the tools can wrap.
If, like me, and maybe like Martin, you think pretty formatting is something
that improves readability, the draft also lets you do that.

A

> -Original Message-
> From: Martin Bjorklund [mailto:m...@tail-f.com]
> Sent: 23 October 2018 17:04
> To: lho...@nic.cz
> Cc: adr...@olddog.co.uk; netmod@ietf.org
> Subject: Re: [netmod] WG adoption poll draft-kwatsen-netmod-artwork-folding-
> 08
> 
> Ladislav Lhotka  wrote:
> > On Tue, 2018-10-23 at 16:27 +0200, Martin Bjorklund wrote:
> > > Ladislav Lhotka  wrote:
> > > > On Tue, 2018-10-23 at 14:45 +0100, Adrian Farrel wrote:
> > > > > Hi,
> > > > >
> > > > > 1. I think you miss the point. While example XML/JSON YANG is included
> in
> > > > > drafts, and while the authors are allowed to produce those drafts as
txt
> > > > > files,
> > > > > or while the authors want to achieve pretty-to-read formatting, this
work
> > > > > falls
> > > > > into the scope of those authors.
> > > >
> > > > The folding of long lines should be done as the very last (automatic)
step
> > > > before the document gets published. Doing it earlier means that the
source
> > > code
> > > > in this folded form can be (accidentally) further edited, which can lead
to
> > > > inconsistencies.
> > >
> > > I will use folding e.g. for instance document examples in XML and
> > > JSON.
> > >
> > > My plan is to keep the example files with manually added breaks in my
> > > repo, and as part of validation run a script that unfolds the
> > > examples, and then validate the result.  The reason for this is that I
> > > think readbility of the examples is important.
> >
> > This seems backwards to me. If you need to edit such an example, you may
> have to
> > remove the backslashes, reformat and insert them again.
> >
> > If it's not possible to fold lines according to the syntax of a given
language,
> > I'd prefer to keep the original lines as long as possible and rely on an
> > automatic procedure just before the final document is rolled out.
> 
> Fortunately, the draft allows us both to work the way we prefer.
> 
> 
> /martin
> 
> 
> >
> > Lada
> >
> > >
> > >
> > > /martin
> > >
> > >
> > >
> > > >
> > > > As long as the document is being moved around and edited, it would be
> better
> > > to
> > > > keep the source code untouched.
> > > >
> > > > Lada
> > > >
> > > > >
> > > > > 2. Yes, the authors discussed the  element and agreed that
> it
> > > will
> > > > > be in scope.
> > > > >
> > > > > However, we are all sort of waiting for xml2rfc v3 and pending
completion,
> > > we
> > > > > want to move this forward for v2 that is in use today.
> > > > >
> > > > > (More than) Happy to come back and revisit this issue when v3 is
> deployed.
> > > > >
> > > > > Thanks,
> > > > > Adrian
> > > > >
> > > > > > -Original Message-
> > > > > > From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Ladislav
> > > Lhotka
> > > > > > Sent: 23 October 2018 14:24
> > > > > > To: netmod@ietf.org
> > > > > > Subject: Re: [netmod] WG adoption poll draft-kwatsen-netmod-
> artwork-
> > > folding-
> > > > > > 08
> > > > > >
> > > > > > On Tue, 2018-10-23 at 14:40 +0200, Ladislav Lhotka wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > > > I support the adoption.
> > > > > > >
> > > > > > > Comments:
> > > > > > >
> > > > > > > 1. My general feeling is that such technicalities should be
handled by
> > > > > > >the RFC editor and/or tools rather than YANG module and RFC
> > > authors.
> > > > > > >
> > > > > > > 2. xml2rfc v3 introduced a new element, , that is
> intended
> > > > > > >for source code inclusion. This document should therefore cover
> > > this
> > > > > > >element as well (primarily?). One problem with it is that the
> > > xml2rfc
> > > > > > >tool automatically adds the  and 
> markers,
> > > > > > >which interferes with YANG convention specified in RFC 8407,
> > > > > > >sec. 3.2. I have already raised a question about this in the
> > > > > > >xml2rfc-dev mailing list.
> > > > > >
> > > > > > Update: using the "name" attribute with  does the right
> > > thing.
> > > > > >
> > > > > > 
> > > > > > ...
> > > > > > 
> > > > > >
> > > > > > results in
> > > > > >
> > > > > >  file "ietf-...@2016-03-20.yang"
> > > > > > ...
> > > > > > 
> > > > > >
> > > > > > Lada
> > > > > >
> > > > > > > Lada
> > > > > > >
> > > > > > > Lou Berger  writes:
> > > > > > >
> > > > > > > > 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
> > >

[netmod] IANA Considerations

2018-10-23 Thread tom petch

draft-ietf-ccamp-mw-yang-10
has, in IANA Considerations,
  Name: ietf-microwave-radio-link
  Maintained by IANA?: N
  Namespace: urn:ietf:params:xml:ns:yang:ietf-microwave-radio-link
  Prefix: mrl
  Reference: RFC 
which adds a line I have not seen before, not mentioned - naturally - in
RFC6020 or RFC7950 nor does it appear in e.g. RFC8407.

It seems like 'A Good Thing' but where has it come from, what is the
basis for it and is there a reference for it?  It could be construed as
a breach of RFC6020.

Tom Petch

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

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

2018-10-23 Thread Martin Bjorklund

Ladislav Lhotka  wrote:
> On Tue, 2018-10-23 at 16:27 +0200, Martin Bjorklund wrote:
> > Ladislav Lhotka  wrote:
> > > On Tue, 2018-10-23 at 14:45 +0100, Adrian Farrel wrote:
> > > > Hi,
> > > > 
> > > > 1. I think you miss the point. While example XML/JSON YANG is included 
> > > > in
> > > > drafts, and while the authors are allowed to produce those drafts as txt
> > > > files,
> > > > or while the authors want to achieve pretty-to-read formatting, this 
> > > > work
> > > > falls
> > > > into the scope of those authors.
> > > 
> > > The folding of long lines should be done as the very last (automatic) step
> > > before the document gets published. Doing it earlier means that the source
> > code
> > > in this folded form can be (accidentally) further edited, which can lead 
> > > to
> > > inconsistencies.
> > 
> > I will use folding e.g. for instance document examples in XML and
> > JSON.
> > 
> > My plan is to keep the example files with manually added breaks in my
> > repo, and as part of validation run a script that unfolds the
> > examples, and then validate the result.  The reason for this is that I
> > think readbility of the examples is important.
> 
> This seems backwards to me. If you need to edit such an example, you may have 
> to
> remove the backslashes, reformat and insert them again.
> 
> If it's not possible to fold lines according to the syntax of a given 
> language,
> I'd prefer to keep the original lines as long as possible and rely on an
> automatic procedure just before the final document is rolled out. 

Fortunately, the draft allows us both to work the way we prefer.


/martin


> 
> Lada  
> 
> > 
> > 
> > /martin
> > 
> > 
> > 
> > > 
> > > As long as the document is being moved around and edited, it would be 
> > > better
> > to
> > > keep the source code untouched.
> > > 
> > > Lada
> > > 
> > > > 
> > > > 2. Yes, the authors discussed the  element and agreed that 
> > > > it
> > will
> > > > be in scope.
> > > > 
> > > > However, we are all sort of waiting for xml2rfc v3 and pending 
> > > > completion,
> > we
> > > > want to move this forward for v2 that is in use today.
> > > > 
> > > > (More than) Happy to come back and revisit this issue when v3 is 
> > > > deployed.
> > > > 
> > > > Thanks,
> > > > Adrian
> > > > 
> > > > > -Original Message-
> > > > > From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Ladislav
> > Lhotka
> > > > > Sent: 23 October 2018 14:24
> > > > > To: netmod@ietf.org
> > > > > Subject: Re: [netmod] WG adoption poll draft-kwatsen-netmod-artwork-
> > folding-
> > > > > 08
> > > > > 
> > > > > On Tue, 2018-10-23 at 14:40 +0200, Ladislav Lhotka wrote:
> > > > > > Hi,
> > > > > > 
> > > > > > I support the adoption.
> > > > > > 
> > > > > > Comments:
> > > > > > 
> > > > > > 1. My general feeling is that such technicalities should be handled 
> > > > > > by
> > > > > >the RFC editor and/or tools rather than YANG module and RFC
> > authors.
> > > > > > 
> > > > > > 2. xml2rfc v3 introduced a new element, , that is 
> > > > > > intended
> > > > > >for source code inclusion. This document should therefore cover
> > this
> > > > > >element as well (primarily?). One problem with it is that the
> > xml2rfc
> > > > > >tool automatically adds the  and  
> > > > > > markers,
> > > > > >which interferes with YANG convention specified in RFC 8407,
> > > > > >sec. 3.2. I have already raised a question about this in the
> > > > > >xml2rfc-dev mailing list.
> > > > > 
> > > > > Update: using the "name" attribute with  does the right
> > thing.
> > > > > 
> > > > > 
> > > > > ...
> > > > > 
> > > > > 
> > > > > results in
> > > > > 
> > > > >  file "ietf-...@2016-03-20.yang"
> > > > > ...
> > > > > 
> > > > > 
> > > > > Lada
> > > > > 
> > > > > > Lada
> > > > > > 
> > > > > > Lou Berger  writes:
> > > > > > 
> > > > > > > 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
> > > > > --
> > > > > Ladislav Lhotka
> > > > > Head, CZ.NIC Labs
> > > > > PGP Key ID: 0xB8F92B08A9F76C67
> > > > > 
> > > > > ___
> > > > > netmod mailing list
> > > > > netmod@ietf.org
> > > > >

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

2018-10-23 Thread Ladislav Lhotka

On Tue, 2018-10-23 at 16:27 +0200, Martin Bjorklund wrote:
> Ladislav Lhotka  wrote:
> > On Tue, 2018-10-23 at 14:45 +0100, Adrian Farrel wrote:
> > > Hi,
> > > 
> > > 1. I think you miss the point. While example XML/JSON YANG is included in
> > > drafts, and while the authors are allowed to produce those drafts as txt
> > > files,
> > > or while the authors want to achieve pretty-to-read formatting, this work
> > > falls
> > > into the scope of those authors.
> > 
> > The folding of long lines should be done as the very last (automatic) step
> > before the document gets published. Doing it earlier means that the source
> code
> > in this folded form can be (accidentally) further edited, which can lead to
> > inconsistencies.
> 
> I will use folding e.g. for instance document examples in XML and
> JSON.
> 
> My plan is to keep the example files with manually added breaks in my
> repo, and as part of validation run a script that unfolds the
> examples, and then validate the result.  The reason for this is that I
> think readbility of the examples is important.

This seems backwards to me. If you need to edit such an example, you may have to
remove the backslashes, reformat and insert them again.

If it's not possible to fold lines according to the syntax of a given language,
I'd prefer to keep the original lines as long as possible and rely on an
automatic procedure just before the final document is rolled out. 

Lada  

> 
> 
> /martin
> 
> 
> 
> > 
> > As long as the document is being moved around and edited, it would be better
> to
> > keep the source code untouched.
> > 
> > Lada
> > 
> > > 
> > > 2. Yes, the authors discussed the  element and agreed that it
> will
> > > be in scope.
> > > 
> > > However, we are all sort of waiting for xml2rfc v3 and pending completion,
> we
> > > want to move this forward for v2 that is in use today.
> > > 
> > > (More than) Happy to come back and revisit this issue when v3 is deployed.
> > > 
> > > Thanks,
> > > Adrian
> > > 
> > > > -Original Message-
> > > > From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Ladislav
> Lhotka
> > > > Sent: 23 October 2018 14:24
> > > > To: netmod@ietf.org
> > > > Subject: Re: [netmod] WG adoption poll draft-kwatsen-netmod-artwork-
> folding-
> > > > 08
> > > > 
> > > > On Tue, 2018-10-23 at 14:40 +0200, Ladislav Lhotka wrote:
> > > > > Hi,
> > > > > 
> > > > > I support the adoption.
> > > > > 
> > > > > Comments:
> > > > > 
> > > > > 1. My general feeling is that such technicalities should be handled by
> > > > >the RFC editor and/or tools rather than YANG module and RFC
> authors.
> > > > > 
> > > > > 2. xml2rfc v3 introduced a new element, , that is intended
> > > > >for source code inclusion. This document should therefore cover
> this
> > > > >element as well (primarily?). One problem with it is that the
> xml2rfc
> > > > >tool automatically adds the  and  markers,
> > > > >which interferes with YANG convention specified in RFC 8407,
> > > > >sec. 3.2. I have already raised a question about this in the
> > > > >xml2rfc-dev mailing list.
> > > > 
> > > > Update: using the "name" attribute with  does the right
> thing.
> > > > 
> > > > 
> > > > ...
> > > > 
> > > > 
> > > > results in
> > > > 
> > > >  file "ietf-...@2016-03-20.yang"
> > > > ...
> > > > 
> > > > 
> > > > Lada
> > > > 
> > > > > Lada
> > > > > 
> > > > > Lou Berger  writes:
> > > > > 
> > > > > > 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
> > > > --
> > > > Ladislav Lhotka
> > > > Head, CZ.NIC Labs
> > > > PGP Key ID: 0xB8F92B08A9F76C67
> > > > 
> > > > ___
> > > > 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
> > 
-- 
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-kwatsen-netmod-artwork-folding-08

2018-10-23 Thread Martin Bjorklund

Ladislav Lhotka  wrote:
> On Tue, 2018-10-23 at 14:45 +0100, Adrian Farrel wrote:
> > Hi,
> > 
> > 1. I think you miss the point. While example XML/JSON YANG is included in
> > drafts, and while the authors are allowed to produce those drafts as txt
> > files,
> > or while the authors want to achieve pretty-to-read formatting, this work
> > falls
> > into the scope of those authors.
> 
> The folding of long lines should be done as the very last (automatic) step
> before the document gets published. Doing it earlier means that the source 
> code
> in this folded form can be (accidentally) further edited, which can lead to
> inconsistencies.

I will use folding e.g. for instance document examples in XML and
JSON.

My plan is to keep the example files with manually added breaks in my
repo, and as part of validation run a script that unfolds the
examples, and then validate the result.  The reason for this is that I
think readbility of the examples is important.


/martin



> 
> As long as the document is being moved around and edited, it would be better 
> to
> keep the source code untouched.
> 
> Lada
> 
> > 
> > 2. Yes, the authors discussed the  element and agreed that it 
> > will
> > be in scope.
> > 
> > However, we are all sort of waiting for xml2rfc v3 and pending completion, 
> > we
> > want to move this forward for v2 that is in use today.
> > 
> > (More than) Happy to come back and revisit this issue when v3 is deployed.
> > 
> > Thanks,
> > Adrian
> > 
> > > -Original Message-
> > > From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Ladislav Lhotka
> > > Sent: 23 October 2018 14:24
> > > To: netmod@ietf.org
> > > Subject: Re: [netmod] WG adoption poll 
> > > draft-kwatsen-netmod-artwork-folding-
> > > 08
> > > 
> > > On Tue, 2018-10-23 at 14:40 +0200, Ladislav Lhotka wrote:
> > > > Hi,
> > > > 
> > > > I support the adoption.
> > > > 
> > > > Comments:
> > > > 
> > > > 1. My general feeling is that such technicalities should be handled by
> > > >the RFC editor and/or tools rather than YANG module and RFC authors.
> > > > 
> > > > 2. xml2rfc v3 introduced a new element, , that is intended
> > > >for source code inclusion. This document should therefore cover this
> > > >element as well (primarily?). One problem with it is that the xml2rfc
> > > >tool automatically adds the  and  markers,
> > > >which interferes with YANG convention specified in RFC 8407,
> > > >sec. 3.2. I have already raised a question about this in the
> > > >xml2rfc-dev mailing list.
> > > 
> > > Update: using the "name" attribute with  does the right thing.
> > > 
> > > 
> > > ...
> > > 
> > > 
> > > results in
> > > 
> > >  file "ietf-...@2016-03-20.yang"
> > > ...
> > > 
> > > 
> > > Lada
> > > 
> > > > Lada
> > > > 
> > > > Lou Berger  writes:
> > > > 
> > > > > 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
> > > --
> > > Ladislav Lhotka
> > > Head, CZ.NIC Labs
> > > PGP Key ID: 0xB8F92B08A9F76C67
> > > 
> > > ___
> > > netmod mailing list
> > > netmod@ietf.org
> > > https://www.ietf.org/mailman/listinfo/netmod
> -- 
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> 

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

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

2018-10-23 Thread Ladislav Lhotka

On Tue, 2018-10-23 at 14:45 +0100, Adrian Farrel wrote:
> Hi,
> 
> 1. I think you miss the point. While example XML/JSON YANG is included in
> drafts, and while the authors are allowed to produce those drafts as txt
> files,
> or while the authors want to achieve pretty-to-read formatting, this work
> falls
> into the scope of those authors.

The folding of long lines should be done as the very last (automatic) step
before the document gets published. Doing it earlier means that the source code
in this folded form can be (accidentally) further edited, which can lead to
inconsistencies.

As long as the document is being moved around and edited, it would be better to
keep the source code untouched.

Lada

> 
> 2. Yes, the authors discussed the  element and agreed that it will
> be in scope.
> 
> However, we are all sort of waiting for xml2rfc v3 and pending completion, we
> want to move this forward for v2 that is in use today.
> 
> (More than) Happy to come back and revisit this issue when v3 is deployed.
> 
> Thanks,
> Adrian
> 
> > -Original Message-
> > From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Ladislav Lhotka
> > Sent: 23 October 2018 14:24
> > To: netmod@ietf.org
> > Subject: Re: [netmod] WG adoption poll draft-kwatsen-netmod-artwork-folding-
> > 08
> > 
> > On Tue, 2018-10-23 at 14:40 +0200, Ladislav Lhotka wrote:
> > > Hi,
> > > 
> > > I support the adoption.
> > > 
> > > Comments:
> > > 
> > > 1. My general feeling is that such technicalities should be handled by
> > >the RFC editor and/or tools rather than YANG module and RFC authors.
> > > 
> > > 2. xml2rfc v3 introduced a new element, , that is intended
> > >for source code inclusion. This document should therefore cover this
> > >element as well (primarily?). One problem with it is that the xml2rfc
> > >tool automatically adds the  and  markers,
> > >which interferes with YANG convention specified in RFC 8407,
> > >sec. 3.2. I have already raised a question about this in the
> > >xml2rfc-dev mailing list.
> > 
> > Update: using the "name" attribute with  does the right thing.
> > 
> > 
> > ...
> > 
> > 
> > results in
> > 
> >  file "ietf-...@2016-03-20.yang"
> > ...
> > 
> > 
> > Lada
> > 
> > > Lada
> > > 
> > > Lou Berger  writes:
> > > 
> > > > 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
> > --
> > Ladislav Lhotka
> > Head, CZ.NIC Labs
> > PGP Key ID: 0xB8F92B08A9F76C67
> > 
> > ___
> > 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] "input"/"output" in tree diagrams

2018-10-23 Thread Martin Bjorklund

Hi,

Jernej Tuljak  wrote:
> Hi,
> 
> am I reading RFC8340 correctly by assuming "input" and "output" nodes
> are not to be part of tree diagrams and that instead input/output
> parameters are now children to the "rpc" or "action" node,
> distinguished solely via -w/ro flags?

I hope not, or that was not the intention anyway.

>   rpcs:
>     +---x get-schema
>    +---w identifier! string
>    +---w version?    string
>    +---w format? identityref
>    +--ro data?

pyang outputs

+---x get-schema
   +---w input
   |  +---w identifierstring
   |  +---w version?  string
   |  +---w format?   identityref
   +--ro output
  +--ro data?   


> Only "input parameters" and "output parameters" are mentioned, which
> seems to suggest data node children of "input" and "output", but not
> themselves. It also says nothing about which flag they receive, if
> they are intended to appear.

Yes I can see how this could be clarified.


/martin

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

[netmod] "input"/"output" in tree diagrams

2018-10-23 Thread Jernej Tuljak


Hi,

am I reading RFC8340 correctly by assuming "input" and "output" nodes 
are not to be part of tree diagrams and that instead input/output 
parameters are now children to the "rpc" or "action" node, distinguished 
solely via -w/ro flags?


  rpcs:
    +---x get-schema
   +---w identifier! string
   +---w version?    string
   +---w format? identityref
   +--ro data?

Only "input parameters" and "output parameters" are mentioned, which 
seems to suggest data node children of "input" and "output", but not 
themselves. It also says nothing about which flag they receive, if they 
are intended to appear.


Jernej

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

Re: [netmod] xpath expressions in JSON

2018-10-23 Thread Juergen Schoenwaelder

On Tue, Oct 23, 2018 at 03:42:35PM +0200, Martin Bjorklund wrote:

> > I would suggest to extend the definition of the "xpath1.0" type with the
> > corresponding specification of the default XPath context.
> 
> Yes, something for 6991bis.
> 
> Meanwhile, for SN, we can add this already there for stream-xpath-filter.

I am not sure whether a new type definition is needed or just some
clarification of the current xpath1.0 definition. Perhaps a new
definition plus deprecation of the xpath1.0 definition is the right
thing to do. I have added this to my list of possible changes to
RFC 6991.

/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] WG adoption poll draft-kwatsen-netmod-artwork-folding-08

2018-10-23 Thread Adrian Farrel

Hi,

1. I think you miss the point. While example XML/JSON YANG is included in
drafts, and while the authors are allowed to produce those drafts as txt files,
or while the authors want to achieve pretty-to-read formatting, this work falls
into the scope of those authors.

2. Yes, the authors discussed the  element and agreed that it will
be in scope.

However, we are all sort of waiting for xml2rfc v3 and pending completion, we
want to move this forward for v2 that is in use today.

(More than) Happy to come back and revisit this issue when v3 is deployed.

Thanks,
Adrian

> -Original Message-
> From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Ladislav Lhotka
> Sent: 23 October 2018 14:24
> To: netmod@ietf.org
> Subject: Re: [netmod] WG adoption poll draft-kwatsen-netmod-artwork-folding-
> 08
> 
> On Tue, 2018-10-23 at 14:40 +0200, Ladislav Lhotka wrote:
> > Hi,
> >
> > I support the adoption.
> >
> > Comments:
> >
> > 1. My general feeling is that such technicalities should be handled by
> >the RFC editor and/or tools rather than YANG module and RFC authors.
> >
> > 2. xml2rfc v3 introduced a new element, , that is intended
> >for source code inclusion. This document should therefore cover this
> >element as well (primarily?). One problem with it is that the xml2rfc
> >tool automatically adds the  and  markers,
> >which interferes with YANG convention specified in RFC 8407,
> >sec. 3.2. I have already raised a question about this in the
> >xml2rfc-dev mailing list.
> 
> Update: using the "name" attribute with  does the right thing.
> 
> 
> ...
> 
> 
> results in
> 
>  file "ietf-...@2016-03-20.yang"
> ...
> 
> 
> Lada
> 
> >
> > Lada
> >
> > Lou Berger  writes:
> >
> > > 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
> --
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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

Re: [netmod] xpath expressions in JSON

2018-10-23 Thread Martin Bjorklund

Ladislav Lhotka  wrote:
> On Tue, 2018-10-23 at 12:16 +0200, Juergen Schoenwaelder wrote:
> > On Tue, Oct 23, 2018 at 10:39:22AM +0100, Robert Wilton wrote:
> > > Hi Juergen,
> > > 
> > > Is this the same as Martin's alternative B proposed previously 
> > > (attached)? 
> > > Or are you suggesting a different alternative?
> > > 
> > 
> > Likely the same, but I admit that I do not understand Martin's
> > comment:
> > 
> >   Con: in XML, this leaf is treated differently from other XPath
> >expressions, such as get-config filter and nacm rules.
> > 
> > If the context has ietf-interfaces pre-populated and you receive
> > if:ietf-interfaces with proper XML namespace bindings, one could add
> > the prefix if to the namespace declarations. One might even use (if
> > the server signals that it supports prepopulated namespaces) the
> > module name prefixed xpath expressions in say get-data.
> 
> This may be the best option: the "verbose" prefix/namespace bindings will be
> available in all encodings, which doesn't prevent users of the XML encoding to
> define additional ones.

Yes, and we can define a canonical format (with module names), and it
is backwards compatible.  The only problem is verbosity, but I think
that is unavoidable.

> I would suggest to extend the definition of the "xpath1.0" type with the
> corresponding specification of the default XPath context.

Yes, something for 6991bis.

Meanwhile, for SN, we can add this already there for stream-xpath-filter.


/martin



> 
> Lada
> 
> > 
> > The only downside really is the verbosity but I value compatibility
> > with xpath and no ambiguity or corner cases where things can clash
> > higher than compactness. And a client that is capable to parse xpath
> > and yang-library aware may do the expansion locally or if we work out
> > the details, a server may signal its ability to do the expansion as
> > well (not sure though that all this is effort well invested since N
> > different ways to send around xpath expressions increases costs on all
> > sides and is asking for interoperability problems. Hence, I rather go
> > with longish xpath expressions for the sake of simplicity and
> > interoperability.
> > 
> > /js
> > 
> -- 
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> 

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

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

2018-10-23 Thread Ladislav Lhotka

On Tue, 2018-10-23 at 14:40 +0200, Ladislav Lhotka wrote:
> Hi,
> 
> I support the adoption.
> 
> Comments:
> 
> 1. My general feeling is that such technicalities should be handled by
>the RFC editor and/or tools rather than YANG module and RFC authors.
> 
> 2. xml2rfc v3 introduced a new element, , that is intended
>for source code inclusion. This document should therefore cover this
>element as well (primarily?). One problem with it is that the xml2rfc
>tool automatically adds the  and  markers,
>which interferes with YANG convention specified in RFC 8407,
>sec. 3.2. I have already raised a question about this in the
>xml2rfc-dev mailing list.

Update: using the "name" attribute with  does the right thing.


...


results in

 file "ietf-...@2016-03-20.yang"
...


Lada 

> 
> Lada
> 
> Lou Berger  writes:
> 
> > 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
-- 
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-kwatsen-netmod-artwork-folding-08

2018-10-23 Thread Ladislav Lhotka

Hi,

I support the adoption.

Comments:

1. My general feeling is that such technicalities should be handled by
   the RFC editor and/or tools rather than YANG module and RFC authors.

2. xml2rfc v3 introduced a new element, , that is intended
   for source code inclusion. This document should therefore cover this
   element as well (primarily?). One problem with it is that the xml2rfc
   tool automatically adds the  and  markers,
   which interferes with YANG convention specified in RFC 8407,
   sec. 3.2. I have already raised a question about this in the
   xml2rfc-dev mailing list.

Lada

Lou Berger  writes:

> 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

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

2018-10-23 Thread Ladislav Lhotka

On Tue, 2018-10-23 at 12:16 +0200, Juergen Schoenwaelder wrote:
> On Tue, Oct 23, 2018 at 10:39:22AM +0100, Robert Wilton wrote:
> > Hi Juergen,
> > 
> > Is this the same as Martin's alternative B proposed previously (attached)? 
> > Or are you suggesting a different alternative?
> > 
> 
> Likely the same, but I admit that I do not understand Martin's
> comment:
> 
>   Con: in XML, this leaf is treated differently from other XPath
>expressions, such as get-config filter and nacm rules.
> 
> If the context has ietf-interfaces pre-populated and you receive
> if:ietf-interfaces with proper XML namespace bindings, one could add
> the prefix if to the namespace declarations. One might even use (if
> the server signals that it supports prepopulated namespaces) the
> module name prefixed xpath expressions in say get-data.

This may be the best option: the "verbose" prefix/namespace bindings will be
available in all encodings, which doesn't prevent users of the XML encoding to
define additional ones.

I would suggest to extend the definition of the "xpath1.0" type with the
corresponding specification of the default XPath context.

Lada

> 
> The only downside really is the verbosity but I value compatibility
> with xpath and no ambiguity or corner cases where things can clash
> higher than compactness. And a client that is capable to parse xpath
> and yang-library aware may do the expansion locally or if we work out
> the details, a server may signal its ability to do the expansion as
> well (not sure though that all this is effort well invested since N
> different ways to send around xpath expressions increases costs on all
> sides and is asking for interoperability problems. Hence, I rather go
> with longish xpath expressions for the sake of simplicity and
> interoperability.
> 
> /js
> 
-- 
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

2018-10-23 Thread Juergen Schoenwaelder

On Tue, Oct 23, 2018 at 10:39:22AM +0100, Robert Wilton wrote:
> Hi Juergen,
> 
> Is this the same as Martin's alternative B proposed previously (attached)? 
> Or are you suggesting a different alternative?
>

Likely the same, but I admit that I do not understand Martin's
comment:

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

If the context has ietf-interfaces pre-populated and you receive
if:ietf-interfaces with proper XML namespace bindings, one could add
the prefix if to the namespace declarations. One might even use (if
the server signals that it supports prepopulated namespaces) the
module name prefixed xpath expressions in say get-data.

The only downside really is the verbosity but I value compatibility
with xpath and no ambiguity or corner cases where things can clash
higher than compactness. And a client that is capable to parse xpath
and yang-library aware may do the expansion locally or if we work out
the details, a server may signal its ability to do the expansion as
well (not sure though that all this is effort well invested since N
different ways to send around xpath expressions increases costs on all
sides and is asking for interoperability problems. Hence, I rather go
with longish xpath expressions for the sake of simplicity and
interoperability.

/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

2018-10-23 Thread Robert Wilton


Hi Juergen,

Is this the same as Martin's alternative B proposed previously 
(attached)?  Or are you suggesting a different alternative?


Thanks,
Rob


On 23/10/2018 10:28, Juergen Schoenwaelder wrote:

On Tue, Oct 23, 2018 at 11:20:54AM +0200, Ladislav Lhotka wrote:

Note that the namespace information needn't be sent along with every XPath
expression as it would probably be the case in the XML encoding of option A.
Only if a new namespace is being used, the "namespace" list has to be updated.


Can we pre-populate the context with namespaces, for example,
controlled via an extension of yang library? Perhaps we can simply
pre-polutate contexts with all module names? Yes, I know this makes
xpath expressions rather verbose but on the other hand it takes away
guesswork and (client) tools may do expansion of an unprefixed
expression into a proper namespace prefixed expression.

/js



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

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

Re: [netmod] xpath expressions in JSON

2018-10-23 Thread Juergen Schoenwaelder

On Tue, Oct 23, 2018 at 11:20:54AM +0200, Ladislav Lhotka wrote:
> 
> Note that the namespace information needn't be sent along with every XPath
> expression as it would probably be the case in the XML encoding of option A.
> Only if a new namespace is being used, the "namespace" list has to be 
> updated. 
>

Can we pre-populate the context with namespaces, for example,
controlled via an extension of yang library? Perhaps we can simply
pre-polutate contexts with all module names? Yes, I know this makes
xpath expressions rather verbose but on the other hand it takes away
guesswork and (client) tools may do expansion of an unprefixed
expression into a proper namespace prefixed expression.

/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

2018-10-23 Thread Ladislav Lhotka

On Tue, 2018-10-23 at 10:10 +0100, Robert Wilton wrote:
> 
> On 23/10/2018 08:36, Ladislav Lhotka wrote:
> > Martin Bjorklund  writes:
> > 
> > > Qin Wu  wrote:
> > > > -邮件原件-
> > > > 发件人: 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
> >

Re: [netmod] xpath expressions in JSON

2018-10-23 Thread Robert Wilton




On 23/10/2018 08:36, Ladislav Lhotka wrote:

Martin Bjorklund  writes:


Qin Wu  wrote:

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

   
 /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" function.  Example of a "local-name"
function that should not be used:

   /*[local-name()='foo']

This guideline is for must/when expressions *within* YANG modules.

I'm talking about a different use case, namely filtering.  It is
pretty convenient for users to send a filter:

   /interfaces/interface[name='eth0'/ipv4

This is impossible if we want to call it XPath. With an explicit
namespace/prefix declaration, for example

   "namespace": [
 {
   "prefix": "if",
   "uri": "urn:ietf:params:xml:ns:yang:ietf-interfaces",
   "default": true
 },

Re: [netmod] xpath expressions in JSON

2018-10-23 Thread Martin Bjorklund

Ladislav Lhotka  wrote:
> On Tue, 2018-10-23 at 10:23 +0200, Martin Bjorklund wrote:
> > Ladislav Lhotka  wrote:
> > > Martin Bjorklund  writes:
> > 
> > > 
> > 
> > > > Qin Wu  wrote:
> > 
> > > >> -邮件原件-
> > 
> > > >> 发件人: 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:
> > 
> > > >> > > >
> > 
> > > >> > > >   
> > 
> > > >> > > >

Re: [netmod] xpath expressions in JSON

2018-10-23 Thread Ladislav Lhotka

On Tue, 2018-10-23 at 10:23 +0200, Martin Bjorklund wrote:
> Ladislav Lhotka  wrote:
> > Martin Bjorklund  writes:
> 
> > 
> 
> > > Qin Wu  wrote:
> 
> > >> -邮件原件-
> 
> > >> 发件人: 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

Re: [netmod] xpath expressions in JSON

2018-10-23 Thread Martin Bjorklund

Ladislav Lhotka  wrote:
> Martin Bjorklund  writes:
> 
> > Qin Wu  wrote:
> >> -邮件原件-
> >> 发件人: 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

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

2018-10-23 Thread Martin Bjorklund

Hi,

I support the adoption of this document, and I intend to help by
reviewing it.

(one quick comment; the header used in the examples in section 8 isn't
equal to the header defined in section 5.1)


/martin


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

2018-10-23 Thread Ladislav Lhotka

Martin Bjorklund  writes:

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

Re: [netmod] yang-data issues

2018-10-23 Thread Ladislav Lhotka

On Mon, 2018-10-22 at 10:41 -0700, 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?
> 
> 
> 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 agree, this has been my proposal all along. YANG should be able to cover such
uses out of the box. Extensions like yang-data only make the whole thing more
complicated.

Sometimes it it not even necessary to introduce an ad hoc datastore, a "schema"
entry from yang-library-bis could be sufficient.

> 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

In many cases yang-library(-bis) can be used without the metadata provided by
yang-instance-data. For example, my yangson library uses YANG library data
(JSON) for specifying the complete data model:

https://yangson.labs.nic.cz/cmdline.html

Pyang uses NETCONF hello (XML) for the same purpose.

Lada

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

2018-10-23 Thread Martin Bjorklund

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

Re: [netmod] IANA Considerations

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

Re: [netmod] IANA Considerations

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

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

Re: [netmod] IANA Considerations

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

[netmod] IANA Considerations

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

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

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

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

Re: [netmod] "input"/"output" in tree diagrams

[netmod] "input"/"output" in tree diagrams

Re: [netmod] xpath expressions in JSON

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

Re: [netmod] xpath expressions in JSON

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

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

Re: [netmod] xpath expressions in JSON

Re: [netmod] xpath expressions in JSON

Re: [netmod] xpath expressions in JSON

Re: [netmod] xpath expressions in JSON

Re: [netmod] xpath expressions in JSON

Re: [netmod] xpath expressions in JSON

Re: [netmod] xpath expressions in JSON

Re: [netmod] xpath expressions in JSON

Re: [netmod] xpath expressions in JSON

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

Re: [netmod] xpath expressions in JSON

Re: [netmod] yang-data issues

Re: [netmod] xpath expressions in JSON

32 matches

Site Navigation

Mail list logo

Footer information