Re: [netmod] JSON encoding of anyxml

[Ladislav Lhotka]

Martin Bjorklund  writes:

> Andy Bierman  wrote:
>> On Tue, Nov 10, 2015 at 6:16 AM, Robert Varga  wrote:
>> 
>> > Hello,
>> >
>> > I am not favor of it, either, but RFC6020 is here and is being widely
>> > deployed. So is RESTCONF+JSON, which is favored by application developers
>> > in the field today, as is NETCONF devices producing anyxml. We do need a
>> > reasonable way of bridging the two -- no matter whether it is configuration
>> > or operational data.
>> >
>> >
>> 
>> I do not agree that the use of anyxml as arbitrary XML is deployed at all.
>> I do not agree that all the "extra XML bits" that are causing so much
>> concern
>> are ever saved in a datastore.  Martin says we need anyxml for RPC input
>> and output. Maybe. This seems proprietary, since no NETCONF/RESTCONF
>> operation depends on anything except elements and attributes.
>
> Specifically, we need anyxml for ietf-netconf, since NETCONF is
> supposedly data modeling language agnostic.
>
> One option could be to deprecte anyxml (or remove it) in YANG 1.1, and
> if we ever do a new version of NETCONF, we use anydata instead.

The simplest solution in this case would be to use a standard XML schema
language - XSD or RELAX NG.

Lada

>
>
> /martin
>
>
>
>> If the JSON looks like a leaf, then no tool is going to analyse the string
>> to see if it a well-formed XML instance document, so it can be re-parsed.
>> Unless a JSON array or object is started, the tool will not
>> think it is dealing with any child nodes.
>> 
>> There are lots of things that NETCONF can do that are trimmed out of
>> RESTCONF.
>> JSON representation or raw XML seems really low priority to me.
>> Are there any use-cases? What processing instructions, character entities,
>> etc.
>> are being used in the wild already?  None? Don't we have enough real
>> problems to
>> solve without rat-holing over corner-cases all the time?
>> 
>> 
>> Andy
>> 
>> 
>> 
>> 
>> > At any rate, a simple string is not going to cut it, as it does not retain
>> > modeling context nor encoding details of the data being transported --
>> > rendering reliable automated translation impossible.
>> >
>> > Bye,
>> > Robert
>> >
>> > On 11/10/2015 03:19 AM, Andy Bierman wrote:
>> >
>> > Hi,
>> >
>> > I am not in favor of anything XML or JSON specific in YANG.
>> > In reality, nobody uses anyxml as a configuration data node,
>> > so an improper roundtrip translation from JSON to XML
>> > is not going to happen.
>> >
>> > Encoding anyxml as a string is not going to happen either.
>> > Not sure what the difference between 'anyxml' and 'type string'
>> > is at that point.
>> >
>> > Why does YANG even need a special type of leaf that is a blob of XML?
>> > Can't a single-quoted string serve that purpose?
>> >
>> >
>> > Andy
>> >
>> >
>> > On Mon, Nov 9, 2015 at 2:39 PM, Robert Varga < n...@hq.sk>
>> > wrote:
>> >
>> >> On 11/05/2015 09:56 AM, Ladislav Lhotka wrote:
>> >>
>> >>> Given the resolution of Y34 in YANG 1.1, Martin's proposal to encode
>>  >anyxml as a string that has XML inside makes sense.
>> 
>> >>> The possibility of sending arbitrary (non-YANG) data in the native
>> >>> encoding can occassionally be useful, and even more so in JSON. For
>> >>> example, I have to work with a JSON-based format for specifying DNSSEC
>> >>> signing policies. While my plan is to eventually replace this format with
>> >>> YANG-modelled data, it would help me, as an interim solution, to simply
>> >>> send the data in the legacy format. That's why I want to retain the
>> >>> existing rules for JSON encoding of anyxml, unless something else is
>> >>> available. Sending XML documents as strings is still possible although 
>> >>> IMO
>> >>> next to useless.
>> >>>
>> >>
>> >> I fear requiring JSON in anyxml will render RESTCONF-to-NETCONF proxies
>> >> non-transparent in case the sender (a NETCONF NE) and receiver (an 
>> >> RESTCONF
>> >> application) have out-of-band knowledge of the data being sent over 
>> >> anyxml.
>> >> Given the proxy does not have this knowledge, it cannot reliably deal with
>> >> lists, as they lack a container element in XML encoding.
>> >>
>> >> Can we perhaps indicate the encoding of the anyxml data chunk in JSON as
>> >> a separate well-known attribute?
>> >>
>> >> Bye,
>> >> Robert
>> >>
>> >> ___
>> >> 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, CZ.NIC Labs
PGP Key ID: E74E8C0C

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

Re: [netmod] Modelling ports that can support multiple physical layer standards

[Robert Wilton]

Hi William,

I'm not that familiar with Broadband physical layer standards, but I 
have an interest in figuring out some of the physical layer and 
interface layer relationships in YANG.


There are a couple of things that are not clear to me from your email, 
so I have two questions:


1) Am I right to presume that the "type" of the port is fixed, and can't 
be changed by the handshake mechanism?
2) I don't quite understand your last sentence regarding only one 
interface-level enable/disable leaf.  I would have thought that this 
would be a benefit.  Please can you elaborate.



There is possibly a third way to model this, which is to have an 
augmentation of a choice statement, i.e.:
1. Your base model would define a choice statement representing the 
physical-layer 'color'.
2. Each physical layer 'color' would be a separate augmentation of the 
choice statement.


Using this design ensures that the model can only ever have a single 
physical-layer at a given time, and yet still makes it clear which 
physical-layer is in use and also allows for different configuration 
nodes for each color.


I've used this structure for modelling layer 2 encapsulation in the IDs 
that I've put forward:
E.g. see "choice encaps-type" in draft-wilton-netmod-intf-ext-yang-01 
for the base model, and two instances of


'augment "/if:interfaces/if:interface/if-cmn:encapsulation/if-cmn:encaps-type"'

in draft-wilton-netmod-intf-vlan-yang-01 for two example augmentation 
cover a basic VLAN layer 2 encapsulation, and a more flexible layer 2 
encapsulation.  Other layer 2 encapsulations could also be defined for 
PPP, cHDLC, FR, ATM, etc in separate drafts.


Perhaps this choice + augmentation design would also work well in your case?

Thanks,
Rob


On 11/11/2015 09:28, William Lupton wrote:

All,

We would much appreciate comments and suggestions on the question 
posed below.


Thanks,
William Lupton
(Software Architect, Broadband Forum)



In the Broadband Forum we need to model a port that can support 
several physical layer standards, but only one at a time. An initial 
handshake mechanism determines which of these standards will actually 
be used. We have been trying to decide how best to model this 
according to the letter and spirit of RFCs 6020, 6087, 7223 etc.


Consider a port, a handshake mechanism "color-selector" and two 
physical layer standards "green" and "red". Each of these is modelled 
via a YANG module of the same name ("port" probably uses the 
ietf-entity module). Here are the approaches that we have considered:


* Option 1 "direct augment" *

color-selector, green and red all directly augment 
/if:interfaces/if:interface. An instance of each of them is associated 
with the port. See part of the tree here (YANG on request).


module: ietf-interfaces
+--rw interfaces
   | +--rw interface* [name]
   |   +--rw namestring
   |   +--rw description?string
   |   +--rw typeidentityref
   |   +--rw enabled?boolean
   |   +--rw link-up-down-trap-enable?   enumeration {if-mib}?
   |   +--rw color-sel:line
   |   +--rw green:line
   |   +--rw red:line

Note that this means that each port needs three separate interface 
objects. For each additional possible supported physical layer 
standard, an additional interface object would be needed.


* Option 2 "indirect augment" *

An additional if-multicolor module directly augments 
/if:interfaces/if:interface. An instance of if-multicolor is 
associated with the port. if-multicolor has a supported-type leaf-list 
that indicates the physical layer standards that are supported by the 
port (green and red in this case). color-selector, green and red are 
similar to before but this time they augment 
/if:interfaces/if:interface/multi:line, and the green and red "when" 
(existence) criteria are tied to if-multicolor's supported-type 
leaf-list rather than to their own type leaf. See part of the tree 
here (YANG on request).


module: ietf-interfaces
+--rw interfaces
   | +--rw interface* [name]
   |   +--rw namestring
   |   +--rw description?string
   |   +--rw typeidentityref
   |   +--rw enabled?boolean
   |   +--rw link-up-down-trap-enable?   enumeration {if-mib}?
   |   +--rw multi:line
   |   +--rw multi:supported-type*   identityref
   |   +--rw color-sel:line
   |   +--rw green:line
   |   +--rw red:line

The nice thing about this approach is that it models the port in a way 
that is close to how it actually _is_. Each port needs only a single 
interface that's directly associated with the handshake mechanism and 
the supported physical layer standards.


A possible disadvantage of this approach is that it is a bit less well 
aligned with RFC 7223, e.g there is only one interface-level 
enable/disable that has to be "shared" by color-selector, green and 

Re: [netmod] JSON encoding of anyxml

[Ladislav Lhotka]

Robert Varga  writes:

> On 11/05/2015 09:56 AM, Ladislav Lhotka wrote:
>>> Given the resolution of Y34 in YANG 1.1, Martin's proposal to encode
>>> >anyxml as a string that has XML inside makes sense.
>> The possibility of sending arbitrary (non-YANG) data in the native encoding 
>> can occassionally be useful, and even more so in JSON. For example, I have 
>> to work with a JSON-based format for specifying DNSSEC signing policies. 
>> While my plan is to eventually replace this format with YANG-modelled data, 
>> it would help me, as an interim solution, to simply send the data in the 
>> legacy format. That's why I want to retain the existing rules for JSON 
>> encoding of anyxml, unless something else is available. Sending XML 
>> documents as strings is still possible although IMO next to useless.
>
> I fear requiring JSON in anyxml will render RESTCONF-to-NETCONF proxies 
> non-transparent in case the sender (a NETCONF NE) and receiver (an 
> RESTCONF application) have out-of-band knowledge of the data being sent 
> over anyxml. Given the proxy does not have this knowledge, it cannot 
> reliably deal with lists, as they lack a container element in XML
> encoding.

My view of anyxml is that it is a "controlled loophole" that allows
arbitrary non-YANG stuff to be sent. The only requirement is that it
won't break the syntax of the document in which it is embedded - and
this of course depends on the encoding used. It should be used scarcely,
and yes, it generally isn't interoperable and
encoding-transparent. Whenever it is needed, the implementations should
deal with these issues on an ad hoc basis.

So far it has mostly been used in specifications (NETCONF, yang-patch,
zerotouch), i.e. outside the network management context, where YANG
serves as an encoding-independent schema language.

I think it *may* occassionally be useful but it is also true that it can
always be substituted with a string or binary leaf. The only advantage of
sending such data in the "native" encoding is that it can be parsed in
one go.

>
> Can we perhaps indicate the encoding of the anyxml data chunk in JSON as 
> a separate well-known attribute?

I don't think this could be useful because I believe such schema-less
chunks really make sense only if their encoding is the same as that of
the outer document.

Lada

>
> Bye,
> Robert

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

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

[netmod] Modelling ports that can support multiple physical layer standards

[William Lupton]

All,

We would much appreciate comments and suggestions on the question posed below.

Thanks,
William Lupton
(Software Architect, Broadband Forum)



In the Broadband Forum we need to model a port that can support several 
physical layer standards, but only one at a time. An initial handshake 
mechanism determines which of these standards will actually be used. We have 
been trying to decide how best to model this according to the letter and spirit 
of RFCs 6020, 6087, 7223 etc.

Consider a port, a handshake mechanism "color-selector" and two physical layer 
standards "green" and "red". Each of these is modelled via a YANG module of the 
same name ("port" probably uses the ietf-entity module). Here are the 
approaches that we have considered:

 Option 1 "direct augment" 

color-selector, green and red all directly augment /if:interfaces/if:interface. 
An instance of each of them is associated with the port. See part of the tree 
here (YANG on request).

module: ietf-interfaces
   +--rw interfaces
   |  +--rw interface* [name]
   | +--rw namestring
   | +--rw description?string
   | +--rw typeidentityref
   | +--rw enabled?boolean
   | +--rw link-up-down-trap-enable?   enumeration {if-mib}?
   | +--rw color-sel:line
   | +--rw green:line
   | +--rw red:line

Note that this means that each port needs three separate interface objects. For 
each additional possible supported physical layer standard, an additional 
interface object would be needed.

 Option 2 "indirect augment" 

An additional if-multicolor module directly augments 
/if:interfaces/if:interface. An instance of if-multicolor is associated with 
the port. if-multicolor has a supported-type leaf-list that indicates the 
physical layer standards that are supported by the port (green and red in this 
case). color-selector, green and red are similar to before but this time they 
augment /if:interfaces/if:interface/multi:line, and the green and red "when" 
(existence) criteria are tied to if-multicolor's supported-type leaf-list 
rather than to their own type leaf. See part of the tree here (YANG on request).

module: ietf-interfaces
   +--rw interfaces
   |  +--rw interface* [name]
   | +--rw namestring
   | +--rw description?string
   | +--rw typeidentityref
   | +--rw enabled?boolean
   | +--rw link-up-down-trap-enable?   enumeration {if-mib}?
   | +--rw multi:line
   |+--rw multi:supported-type*   identityref
   |+--rw color-sel:line
   |+--rw green:line
   |+--rw red:line

The nice thing about this approach is that it models the port in a way that is 
close to how it actually _is_. Each port needs only a single interface that's 
directly associated with the handshake mechanism and the supported physical 
layer standards.

A possible disadvantage of this approach is that it is a bit less well aligned 
with RFC 7223, e.g there is only one interface-level enable/disable that has to 
be "shared" by color-selector, green and red.___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] JSON encoding of anyxml

[Juergen Schoenwaelder]

On Wed, Nov 11, 2015 at 11:54:58AM +0100, Ladislav Lhotka wrote:
> 
> > On 11 Nov 2015, at 09:07, Juergen Schoenwaelder 
> >  wrote:
> > 
> > On Wed, Nov 11, 2015 at 07:34:23AM +0100, Martin Bjorklund wrote:
> >> Andy Bierman  wrote:
> >>> On Tue, Nov 10, 2015 at 6:16 AM, Robert Varga  wrote:
> >>> 
>  Hello,
>  
>  I am not favor of it, either, but RFC6020 is here and is being widely
>  deployed. So is RESTCONF+JSON, which is favored by application developers
>  in the field today, as is NETCONF devices producing anyxml. We do need a
>  reasonable way of bridging the two -- no matter whether it is 
>  configuration
>  or operational data.
>  
>  
> >>> 
> >>> I do not agree that the use of anyxml as arbitrary XML is deployed at all.
> >>> I do not agree that all the "extra XML bits" that are causing so much
> >>> concern
> >>> are ever saved in a datastore.  Martin says we need anyxml for RPC input
> >>> and output. Maybe. This seems proprietary, since no NETCONF/RESTCONF
> >>> operation depends on anything except elements and attributes.
> >> 
> >> Specifically, we need anyxml for ietf-netconf, since NETCONF is
> >> supposedly data modeling language agnostic.
> >> 
> >> One option could be to deprecte anyxml (or remove it) in YANG 1.1, and
> >> if we ever do a new version of NETCONF, we use anydata instead.
> >> 
> > 
> > We are effectively deprecating anyxml in YANG 1.1. We have reached
> > agreement on Y34-05 and I do not see any new arguments popping up.
> 
> There is nothing in 6020bis indicating that "anyxml" is being deprecated.
>

I wrote 'effectively deprecated' and here is the text in 6020bis.

   Since the use of anyxml limits the manipulation of the content, it is
   RECOMMENDED that the "anyxml" statement not be used to define
   configuration data.

   It should be noted that in YANG version 1, anyxml was the only
   statement that could model an unknown hierarchy of data.  In many
   cases this unknown hierarchy of data is actually modelled in YANG,
   but the exact YANG model is not known at design time.  In these
   situations, it is RECOMMENDED to use anydata (Section 7.10) instead
   of anyxml.

There is more text in Y34-05 that will go into the guidelines. I call
this "effectively deprecated", you can call it differently if you
want. Frankly, this thread is about how to encode anyxml in JSON not
about the YANG 1.1 issue Y34. You may not like Y34-05 but this is what
we ended up with.

/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] JSON encoding of anyxml

[Juergen Schoenwaelder]

On Wed, Nov 11, 2015 at 08:31:14AM -0800, Andy Bierman wrote:
> On Wed, Nov 11, 2015 at 7:32 AM, Juergen Schoenwaelder <
> j.schoenwael...@jacobs-university.de> wrote:
> 
> > On Wed, Nov 11, 2015 at 03:14:13PM +0100, Ladislav Lhotka wrote:
> > >
> > > > On 11 Nov 2015, at 14:59, Juergen Schoenwaelder <
> > j.schoenwael...@jacobs-university.de> wrote:
> > > >
> > > > On Wed, Nov 11, 2015 at 02:53:49PM +0100, Ladislav Lhotka wrote:
> > > >>
> > > >>> On 11 Nov 2015, at 14:44, Juergen Schoenwaelder <
> > j.schoenwael...@jacobs-university.de> wrote:
> > > >>>
> > > >>> On Wed, Nov 11, 2015 at 02:24:15PM +0100, Ladislav Lhotka wrote:
> > > 
> > > >
> > > > I wrote 'effectively deprecated' and here is the text in 6020bis.
> > > >
> > > > Since the use of anyxml limits the manipulation of the content, it
> > is
> > > > RECOMMENDED that the "anyxml" statement not be used to define
> > > > configuration data.
> > > >
> > > > It should be noted that in YANG version 1, anyxml was the only
> > > > statement that could model an unknown hierarchy of data.  In many
> > > > cases this unknown hierarchy of data is actually modelled in YANG,
> > > > but the exact YANG model is not known at design time.  In these
> > > > situations, it is RECOMMENDED to use anydata (Section 7.10) instead
> > > > of anyxml.
> > > 
> > >  The first paragraph is for config data and the second for data that
> > can modelled with YANG. If we want to deprecate "anyxml" for use with data
> > that are neither of these, 6020bis should say so. I'd be fine with that.
> > > 
> > > >>>
> > > >>> The guidelines will say that any usage of anyxml in the IETF will be
> > > >>> carefully checked by YANG doctors. See Y34 for all details.
> > > >>>
> > > > There is more text in Y34-05 that will go into the guidelines. I
> > call
> > > > this "effectively deprecated", you can call it differently if you
> > > > want. Frankly, this thread is about how to encode anyxml in JSON
> > not
> > > > about the YANG 1.1 issue Y34. You may not like Y34-05 but this is
> > what
> > > > we ended up with.
> > > 
> > >  I am strongly against encoding serialized XML as JSON strings. It
> > is IMO totally useless and the spec would have to deal with awkward
> > complications because it is not true that arbitrary XML-encoded anyxml
> > content can be used without changes in JSON encoding.
> > > 
> > >  Perhaps the best solution would be to state that JSON encoding is
> > incompatible with data models that use "anyxml".
> > > 
> > > >>>
> > > >>> Perhaps we can only settle this by doing an opinion poll since
> > > >>> debating this forever is not useful. So what are the options?
> > > >>>
> > > >>> a) The JSON encoding does not define anyxml is not encoded at all. If
> > > >>>  you use anyxml in a data model, the content will not appear in JSON
> > > >>>  encodings.
> > > >>>
> > > >>> b) The JSON encoding defines that anyxml data is encoded as a string
> > > >>>  containing XML.
> > > >>>
> > > >>> c) The JSON encoding defines that anyxml is encoded in whatever way
> > > >>>  the implementor finds useful.
> > > >>>
> > > >>> d) If the anyxml content is actually valid anydata content, encode it
> > > >>>  using anydata rules. Content that is not valid anydata content is
> > > >>>  not encoded at all.
> > > >>>
> > > >>> Any options missing?
> > > >>
> > > >> Yes, the one that's in yang-json-06:
> > > >>
> > > >> e) An anyxml instance is encoded as a JSON name/value pair which MUST
> > > >>   satisfy I-JSON constraints.  Otherwise it is unrestricted, i.e., the
> > > >>   value can be an object, array, number, string or one of the literals
> > > >>   "true", "false" and "null".
> > > >>
> > > >> My preference is e), and then a).
> > > >>
> > > >
> > > > Is e) not the same as c)? I assume that the JSON encoding will always
> > > > be valid JSON (or I-JSON to be precise). So it seems the only
> > refinement
> > > > of e) is the toplevel.
> > >
> > > c) sounds like the same data can be encoded in different ways depending
> > on what the implementor finds useful, e.g. encode all numbers as strings.
> > >
> >
> > But e) says the same, I fail to see the difference here.
> >
> >
> IMO the only option is (f)
> 
>  f) If the anyxml content is actually valid anydata content, encode it
> using anydata rules. Content that is not valid anydata content is
> either not encoded at all, or encoded in an implementation-specific
> manner

This is essentially the same as d).

> Nobody has answered my question about the "WEB banner" type of object.
> The only reports we have ever heard on this sort of object indicate that
> a leaf is used, NOT ANYXML!  Nobody seems to be using anyxml to store WEB
> page snippets in their configuration.  Clearly a leaf is interoperable for
> both XML and JSON, plus NETCONF or RESTCONF.  But we keep insisting
> the YANG to JSON mapping needs to support this 

Re: [netmod] JSON encoding of anyxml

[Juergen Schoenwaelder]

On Wed, Nov 11, 2015 at 03:14:13PM +0100, Ladislav Lhotka wrote:
> 
> > On 11 Nov 2015, at 14:59, Juergen Schoenwaelder 
> >  wrote:
> > 
> > On Wed, Nov 11, 2015 at 02:53:49PM +0100, Ladislav Lhotka wrote:
> >> 
> >>> On 11 Nov 2015, at 14:44, Juergen Schoenwaelder 
> >>>  wrote:
> >>> 
> >>> On Wed, Nov 11, 2015 at 02:24:15PM +0100, Ladislav Lhotka wrote:
>  
> > 
> > I wrote 'effectively deprecated' and here is the text in 6020bis.
> > 
> > Since the use of anyxml limits the manipulation of the content, it is
> > RECOMMENDED that the "anyxml" statement not be used to define
> > configuration data.
> > 
> > It should be noted that in YANG version 1, anyxml was the only
> > statement that could model an unknown hierarchy of data.  In many
> > cases this unknown hierarchy of data is actually modelled in YANG,
> > but the exact YANG model is not known at design time.  In these
> > situations, it is RECOMMENDED to use anydata (Section 7.10) instead
> > of anyxml.
>  
>  The first paragraph is for config data and the second for data that can 
>  modelled with YANG. If we want to deprecate "anyxml" for use with data 
>  that are neither of these, 6020bis should say so. I'd be fine with that.
>  
> >>> 
> >>> The guidelines will say that any usage of anyxml in the IETF will be
> >>> carefully checked by YANG doctors. See Y34 for all details.
> >>> 
> > There is more text in Y34-05 that will go into the guidelines. I call
> > this "effectively deprecated", you can call it differently if you
> > want. Frankly, this thread is about how to encode anyxml in JSON not
> > about the YANG 1.1 issue Y34. You may not like Y34-05 but this is what
> > we ended up with.
>  
>  I am strongly against encoding serialized XML as JSON strings. It is IMO 
>  totally useless and the spec would have to deal with awkward 
>  complications because it is not true that arbitrary XML-encoded anyxml 
>  content can be used without changes in JSON encoding. 
>  
>  Perhaps the best solution would be to state that JSON encoding is 
>  incompatible with data models that use "anyxml".
>  
> >>> 
> >>> Perhaps we can only settle this by doing an opinion poll since
> >>> debating this forever is not useful. So what are the options?
> >>> 
> >>> a) The JSON encoding does not define anyxml is not encoded at all. If
> >>>  you use anyxml in a data model, the content will not appear in JSON
> >>>  encodings.
> >>> 
> >>> b) The JSON encoding defines that anyxml data is encoded as a string
> >>>  containing XML.
> >>> 
> >>> c) The JSON encoding defines that anyxml is encoded in whatever way
> >>>  the implementor finds useful.
> >>> 
> >>> d) If the anyxml content is actually valid anydata content, encode it
> >>>  using anydata rules. Content that is not valid anydata content is
> >>>  not encoded at all.
> >>> 
> >>> Any options missing?
> >> 
> >> Yes, the one that's in yang-json-06:
> >> 
> >> e) An anyxml instance is encoded as a JSON name/value pair which MUST
> >>   satisfy I-JSON constraints.  Otherwise it is unrestricted, i.e., the
> >>   value can be an object, array, number, string or one of the literals
> >>   "true", "false" and "null".
> >> 
> >> My preference is e), and then a).
> >> 
> > 
> > Is e) not the same as c)? I assume that the JSON encoding will always
> > be valid JSON (or I-JSON to be precise). So it seems the only refinement
> > of e) is the toplevel.
> 
> c) sounds like the same data can be encoded in different ways depending on 
> what the implementor finds useful, e.g. encode all numbers as strings.
>

But e) says the same, I fail to see the difference here.

/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] JSON encoding of anyxml

[Andy Bierman]

On Wed, Nov 11, 2015 at 7:32 AM, Juergen Schoenwaelder <
j.schoenwael...@jacobs-university.de> wrote:

> On Wed, Nov 11, 2015 at 03:14:13PM +0100, Ladislav Lhotka wrote:
> >
> > > On 11 Nov 2015, at 14:59, Juergen Schoenwaelder <
> j.schoenwael...@jacobs-university.de> wrote:
> > >
> > > On Wed, Nov 11, 2015 at 02:53:49PM +0100, Ladislav Lhotka wrote:
> > >>
> > >>> On 11 Nov 2015, at 14:44, Juergen Schoenwaelder <
> j.schoenwael...@jacobs-university.de> wrote:
> > >>>
> > >>> On Wed, Nov 11, 2015 at 02:24:15PM +0100, Ladislav Lhotka wrote:
> > 
> > >
> > > I wrote 'effectively deprecated' and here is the text in 6020bis.
> > >
> > > Since the use of anyxml limits the manipulation of the content, it
> is
> > > RECOMMENDED that the "anyxml" statement not be used to define
> > > configuration data.
> > >
> > > It should be noted that in YANG version 1, anyxml was the only
> > > statement that could model an unknown hierarchy of data.  In many
> > > cases this unknown hierarchy of data is actually modelled in YANG,
> > > but the exact YANG model is not known at design time.  In these
> > > situations, it is RECOMMENDED to use anydata (Section 7.10) instead
> > > of anyxml.
> > 
> >  The first paragraph is for config data and the second for data that
> can modelled with YANG. If we want to deprecate "anyxml" for use with data
> that are neither of these, 6020bis should say so. I'd be fine with that.
> > 
> > >>>
> > >>> The guidelines will say that any usage of anyxml in the IETF will be
> > >>> carefully checked by YANG doctors. See Y34 for all details.
> > >>>
> > > There is more text in Y34-05 that will go into the guidelines. I
> call
> > > this "effectively deprecated", you can call it differently if you
> > > want. Frankly, this thread is about how to encode anyxml in JSON
> not
> > > about the YANG 1.1 issue Y34. You may not like Y34-05 but this is
> what
> > > we ended up with.
> > 
> >  I am strongly against encoding serialized XML as JSON strings. It
> is IMO totally useless and the spec would have to deal with awkward
> complications because it is not true that arbitrary XML-encoded anyxml
> content can be used without changes in JSON encoding.
> > 
> >  Perhaps the best solution would be to state that JSON encoding is
> incompatible with data models that use "anyxml".
> > 
> > >>>
> > >>> Perhaps we can only settle this by doing an opinion poll since
> > >>> debating this forever is not useful. So what are the options?
> > >>>
> > >>> a) The JSON encoding does not define anyxml is not encoded at all. If
> > >>>  you use anyxml in a data model, the content will not appear in JSON
> > >>>  encodings.
> > >>>
> > >>> b) The JSON encoding defines that anyxml data is encoded as a string
> > >>>  containing XML.
> > >>>
> > >>> c) The JSON encoding defines that anyxml is encoded in whatever way
> > >>>  the implementor finds useful.
> > >>>
> > >>> d) If the anyxml content is actually valid anydata content, encode it
> > >>>  using anydata rules. Content that is not valid anydata content is
> > >>>  not encoded at all.
> > >>>
> > >>> Any options missing?
> > >>
> > >> Yes, the one that's in yang-json-06:
> > >>
> > >> e) An anyxml instance is encoded as a JSON name/value pair which MUST
> > >>   satisfy I-JSON constraints.  Otherwise it is unrestricted, i.e., the
> > >>   value can be an object, array, number, string or one of the literals
> > >>   "true", "false" and "null".
> > >>
> > >> My preference is e), and then a).
> > >>
> > >
> > > Is e) not the same as c)? I assume that the JSON encoding will always
> > > be valid JSON (or I-JSON to be precise). So it seems the only
> refinement
> > > of e) is the toplevel.
> >
> > c) sounds like the same data can be encoded in different ways depending
> on what the implementor finds useful, e.g. encode all numbers as strings.
> >
>
> But e) says the same, I fail to see the difference here.
>
>
IMO the only option is (f)

 f) If the anyxml content is actually valid anydata content, encode it
using anydata rules. Content that is not valid anydata content is
either not encoded at all, or encoded in an implementation-specific
manner


Nobody has answered my question about the "WEB banner" type of object.
The only reports we have ever heard on this sort of object indicate that
a leaf is used, NOT ANYXML!  Nobody seems to be using anyxml to store WEB
page snippets in their configuration.  Clearly a leaf is interoperable for
both XML and JSON, plus NETCONF or RESTCONF.  But we keep insisting
the YANG to JSON mapping needs to support this use of anyxml.

We use anyxml in RPC parameters in ietf-netconf, but the XML
is not expected to be mixed-mode XML.  Only elements and attributes
are used.


/js
>

Andy


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

Re: [netmod] Modelling ports that can support multiple physical layer standards

[Juergen Schoenwaelder]

On Wed, Nov 11, 2015 at 09:28:57AM +, William Lupton wrote:
> All,
> 
> We would much appreciate comments and suggestions on the question posed below.
>

[...]

Good question. Is this question comparable to IEEE 802.3 interfaces
and Medium Attachment Units (MAUs)? In the past, I think we have seen
different approaches and I am not sure there is agreement on a common
approach. For 802.3 MAUs, MAU details were modeled in data models
extending a single interface. For other technologies, interface
layering seemed to be more appropriate. It would be nice if there
would a common understanding how to model interface specifics
consistently but I am afraid we have no common model. The
ietf-interfaces module essentially allows both approaches. It leaves
it open, however, to decide which approach is appropriate.

/js

PS: A pure layering approach would treat an IP interface as an
interface layered on top of say an IEEE 802.3 interface but
the ietf-ip module does not really force this since many
implementations do not expose this layering. If I would do
a clean slate design, I would likely, from a architectural
point of view, go with a layering approach.

-- 
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] Modelling ports that can support multiple physical layer standards

[William Lupton]

Rob, Thanks! Please see inline. Cheers, William.

> On 11 Nov 2015, at 10:49, Robert Wilton  wrote:
> 
> Hi William,
> 
> I'm not that familiar with Broadband physical layer standards, but I have an 
> interest in figuring out some of the physical layer and interface layer 
> relationships in YANG.
> 
> There are a couple of things that are not clear to me from your email, so I 
> have two questions:
> 
> 1) Am I right to presume that the "type" of the port is fixed, and can't be 
> changed by the handshake mechanism?

I'd say "no" in the sense that the port is initially a color-selector port, and 
then (after the colour selection) will be either a green port or a red port. 
These are all types (interface types).

> 2) I don't quite understand your last sentence regarding only one 
> interface-level enable/disable leaf.  I would have thought that this would be 
> a benefit.  Please can you elaborate.

In the second case (indirect augment), a single multi:line interface is 
associated with the port, so the standard "enabled" leaf node (administrative 
enable/disable) will apply to the the multi:line interface. This means that 
there is no way (should you wish it) to individually disable green or red. This 
would require addition of such controls at the green and red level.

> There is possibly a third way to model this, which is to have an augmentation 
> of a choice statement, i.e.:
> 1. Your base model would define a choice statement representing the 
> physical-layer 'color'.
> 2. Each physical layer 'color' would be a separate augmentation of the choice 
> statement.
> 
> Using this design ensures that the model can only ever have a single 
> physical-layer at a given time, and yet still makes it clear which 
> physical-layer is in use and also allows for different configuration nodes 
> for each color.
> 
> I've used this structure for modelling layer 2 encapsulation in the IDs that 
> I've put forward:
> E.g. see "choice encaps-type" in draft-wilton-netmod-intf-ext-yang-01 for the 
> base model, and two instances of 
> 'augment 
> "/if:interfaces/if:interface/if-cmn:encapsulation/if-cmn:encaps-type"'
> in draft-wilton-netmod-intf-vlan-yang-01 for two example augmentation cover a 
> basic VLAN layer 2 encapsulation, and a more flexible layer 2 encapsulation.  
> Other layer 2 encapsulations could also be defined for PPP, cHDLC, FR, ATM, 
> etc in separate drafts.
> 
> Perhaps this choice + augmentation design would also work well in your case?

Thanks! I'll take a look at those drafts. Would this approach allow green and 
red config to exist simultaneously on an interface? I think we'd want to be 
able to do that. Perhaps the choice approach might be used only in the state 
tree?

> Thanks,
> Rob
> 
> On 11/11/2015 09:28, William Lupton wrote:
>> All,
>> 
>> We would much appreciate comments and suggestions on the question posed 
>> below.
>> 
>> Thanks,
>> William Lupton
>> (Software Architect, Broadband Forum)
>> 
>> 
>> 
>> In the Broadband Forum we need to model a port that can support several 
>> physical layer standards, but only one at a time. An initial handshake 
>> mechanism determines which of these standards will actually be used. We have 
>> been trying to decide how best to model this according to the letter and 
>> spirit of RFCs 6020, 6087, 7223 etc.
>> 
>> Consider a port, a handshake mechanism "color-selector" and two physical 
>> layer standards "green" and "red". Each of these is modelled via a YANG 
>> module of the same name ("port" probably uses the ietf-entity module). Here 
>> are the approaches that we have considered:
>> 
>>  Option 1 "direct augment" 
>> 
>> color-selector, green and red all directly augment 
>> /if:interfaces/if:interface. An instance of each of them is associated with 
>> the port. See part of the tree here (YANG on request).
>> 
>> module: ietf-interfaces
>>+--rw interfaces
>>|  +--rw interface* [name]
>>| +--rw namestring
>>| +--rw description?string
>>| +--rw typeidentityref
>>| +--rw enabled?boolean
>>| +--rw link-up-down-trap-enable?   enumeration {if-mib}?
>>| +--rw color-sel:line
>>| +--rw green:line
>>| +--rw red:line
>> 
>> Note that this means that each port needs three separate interface objects. 
>> For each additional possible supported physical layer standard, an 
>> additional interface object would be needed.
>> 
>>  Option 2 "indirect augment" 
>> 
>> An additional if-multicolor module directly augments 
>> /if:interfaces/if:interface. An instance of if-multicolor is associated with 
>> the port. if-multicolor has a supported-type leaf-list that indicates the 
>> physical layer standards that are supported by the port (green and red in 
>> this case). color-selector, green and red are similar to before but this 
>> time they augment 

Re: [netmod] JSON encoding of anyxml

[Juergen Schoenwaelder]

On Wed, Nov 11, 2015 at 02:24:15PM +0100, Ladislav Lhotka wrote:
> 
> > 
> > I wrote 'effectively deprecated' and here is the text in 6020bis.
> > 
> >   Since the use of anyxml limits the manipulation of the content, it is
> >   RECOMMENDED that the "anyxml" statement not be used to define
> >   configuration data.
> > 
> >   It should be noted that in YANG version 1, anyxml was the only
> >   statement that could model an unknown hierarchy of data.  In many
> >   cases this unknown hierarchy of data is actually modelled in YANG,
> >   but the exact YANG model is not known at design time.  In these
> >   situations, it is RECOMMENDED to use anydata (Section 7.10) instead
> >   of anyxml.
> 
> The first paragraph is for config data and the second for data that can 
> modelled with YANG. If we want to deprecate "anyxml" for use with data that 
> are neither of these, 6020bis should say so. I'd be fine with that.
>

The guidelines will say that any usage of anyxml in the IETF will be
carefully checked by YANG doctors. See Y34 for all details.

> > There is more text in Y34-05 that will go into the guidelines. I call
> > this "effectively deprecated", you can call it differently if you
> > want. Frankly, this thread is about how to encode anyxml in JSON not
> > about the YANG 1.1 issue Y34. You may not like Y34-05 but this is what
> > we ended up with.
> 
> I am strongly against encoding serialized XML as JSON strings. It is IMO 
> totally useless and the spec would have to deal with awkward complications 
> because it is not true that arbitrary XML-encoded anyxml content can be used 
> without changes in JSON encoding. 
> 
> Perhaps the best solution would be to state that JSON encoding is 
> incompatible with data models that use "anyxml".
>

Perhaps we can only settle this by doing an opinion poll since
debating this forever is not useful. So what are the options?

a) The JSON encoding does not define anyxml is not encoded at all. If
   you use anyxml in a data model, the content will not appear in JSON
   encodings.

b) The JSON encoding defines that anyxml data is encoded as a string
   containing XML.

c) The JSON encoding defines that anyxml is encoded in whatever way
   the implementor finds useful.

d) If the anyxml content is actually valid anydata content, encode it
   using anydata rules. Content that is not valid anydata content is
   not encoded at all.

Any options missing?

Observations:

 - Except b), none of the options is interoperable. Option d) is
   interoperable for the anydata subset of anyxml.
 - It seems a) is simplest to implement, b) might be expensive to
   implement and use.
 - Some implementations use internal data stores that can only deal
   with data that can be modelled with YANG and for those implementations
   anyxml is effectively the same as anydata and d) migth be close to
   a) in terms of implementation costs.

Any other observations missing?

/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] Modelling ports that can support multiple physical layer standards

[Robert Wilton]

Hi Juergen,

On 11/11/2015 12:13, Juergen Schoenwaelder wrote:

On Wed, Nov 11, 2015 at 09:28:57AM +, William Lupton wrote:

All,

We would much appreciate comments and suggestions on the question posed below.


[...]

Good question. Is this question comparable to IEEE 802.3 interfaces
and Medium Attachment Units (MAUs)? In the past, I think we have seen
different approaches and I am not sure there is agreement on a common
approach. For 802.3 MAUs, MAU details were modeled in data models
extending a single interface. For other technologies, interface
layering seemed to be more appropriate. It would be nice if there
would a common understanding how to model interface specifics
consistently but I am afraid we have no common model. The
ietf-interfaces module essentially allows both approaches. It leaves
it open, however, to decide which approach is appropriate.
I think that a further issue here is that different vendors may have 
different ideas of how to model the layers.  Some vendors have a single 
interface representing both the physical and network layers, but other 
vendors have two separate interfaces (which must have different names to 
appear in if:interfaces) representing both layers (in some cases, if not 
all).  But any such ambiguity is surely going to make models harder to 
use by operators, and hence it would be sensible if the standard IETF 
models could define the expected interface layering behaviour for common 
interface types, even if the base interface model(s) allow for 
alternative interface layering architectures.


Cheers,
Rob




/js

PS: A pure layering approach would treat an IP interface as an
 interface layered on top of say an IEEE 802.3 interface but
 the ietf-ip module does not really force this since many
 implementations do not expose this layering. If I would do
 a clean slate design, I would likely, from a architectural
 point of view, go with a layering approach.



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

Re: [netmod] Modelling ports that can support multiple physical layer standards

[Robert Wilton]

Hi William,

Please see inline ...

On 11/11/2015 12:21, William Lupton wrote:

Rob, Thanks! Please see inline. Cheers, William.

On 11 Nov 2015, at 10:49, Robert Wilton > wrote:


Hi William,

I'm not that familiar with Broadband physical layer standards, but I 
have an interest in figuring out some of the physical layer and 
interface layer relationships in YANG.


There are a couple of things that are not clear to me from your 
email, so I have two questions:


1) Am I right to presume that the "type" of the port is fixed, and 
can't be changed by the handshake mechanism?


I'd say "no" in the sense that the port is initially a color-selector 
port, and then (after the colour selection) will be either a green 
port or a red port. These are all types (interface types).


OK.  I'm not sure whether changing the type of an existing interface is 
a good idea.  E.g. shouldn't the interface type of the base interface 
represent the physical interface that you are operating over.




2) I don't quite understand your last sentence regarding only one 
interface-level enable/disable leaf.  I would have thought that this 
would be a benefit.  Please can you elaborate.


In the second case (indirect augment), a single multi:line interface 
is associated with the port, so the standard "enabled" leaf node 
(administrative enable/disable) will apply to the the multi:line 
interface. This means that there is no way (should you wish it) to 
individually disable green or red. This would require addition of such 
controls at the green and red level.
OK.  But if I understand it correctly a particular port could only ever 
be running as either green or red, never both at the same time.  Is that 
right?  Is so, then I would have thought that a single interface 
enable/disable is sufficient.


Presumably disabling green or red colours could be accomplished by 
removing the associated configuration.




There is possibly a third way to model this, which is to have an 
augmentation of a choice statement, i.e.:
1. Your base model would define a choice statement representing the 
physical-layer 'color'.
2. Each physical layer 'color' would be a separate augmentation of 
the choice statement.


Using this design ensures that the model can only ever have a single 
physical-layer at a given time, and yet still makes it clear which 
physical-layer is in use and also allows for different configuration 
nodes for each color.


I've used this structure for modelling layer 2 encapsulation in the 
IDs that I've put forward:
E.g. see "choice encaps-type" in draft-wilton-netmod-intf-ext-yang-01 
for the base model, and two instances of

'augment "/if:interfaces/if:interface/if-cmn:encapsulation/if-cmn:encaps-type"'
in draft-wilton-netmod-intf-vlan-yang-01 for two example augmentation 
cover a basic VLAN layer 2 encapsulation, and a more flexible layer 2 
encapsulation.  Other layer 2 encapsulations could also be defined 
for PPP, cHDLC, FR, ATM, etc in separate drafts.


Perhaps this choice + augmentation design would also work well in 
your case?


Thanks! I'll take a look at those drafts. Would this approach allow 
green and red config to exist simultaneously on an interface?
No.  The choice statement means that there can be only one colour of 
config at a given time.


Is your requirement effectively a templating one?  I.e. the need to 
define possible configuration for both red and green and then allow the 
protocol to negotiate which colour and hence configuration is used?




I think we'd want to be able to do that. Perhaps the choice approach 
might be used only in the state tree?
Yes possibly, although equally if the leaves in the state tree are not 
mandatory then the information for the unavailable colour could just not 
be returned.


Thanks,
Rob





Thanks,
Rob

On 11/11/2015 09:28, William Lupton wrote:

All,

We would much appreciate comments and suggestions on the question 
posed below.


Thanks,
William Lupton
(Software Architect, Broadband Forum)



In the Broadband Forum we need to model a port that can support 
several physical layer standards, but only one at a time. An initial 
handshake mechanism determines which of these standards will 
actually be used. We have been trying to decide how best to model 
this according to the letter and spirit of RFCs 6020, 6087, 7223 etc.


Consider a port, a handshake mechanism "color-selector" and two 
physical layer standards "green" and "red". Each of these is 
modelled via a YANG module of the same name ("port" probably uses 
the ietf-entity module). Here are the approaches that we have 
considered:


* Option 1 "direct augment" *

color-selector, green and red all directly augment 
/if:interfaces/if:interface. An instance of each of them is 
associated with the port. See part of the tree here (YANG on request).


module: ietf-interfaces
   +--rw interfaces
   |  +--rw interface* [name]
   | +--rw name 

Re: [netmod] JSON encoding of anyxml

[Ladislav Lhotka]

> On 11 Nov 2015, at 13:26, Juergen Schoenwaelder 
>  wrote:
> 
> On Wed, Nov 11, 2015 at 11:54:58AM +0100, Ladislav Lhotka wrote:
>> 
>>> On 11 Nov 2015, at 09:07, Juergen Schoenwaelder 
>>>  wrote:
>>> 
>>> On Wed, Nov 11, 2015 at 07:34:23AM +0100, Martin Bjorklund wrote:
 Andy Bierman  wrote:
> On Tue, Nov 10, 2015 at 6:16 AM, Robert Varga  wrote:
> 
>> Hello,
>> 
>> I am not favor of it, either, but RFC6020 is here and is being widely
>> deployed. So is RESTCONF+JSON, which is favored by application developers
>> in the field today, as is NETCONF devices producing anyxml. We do need a
>> reasonable way of bridging the two -- no matter whether it is 
>> configuration
>> or operational data.
>> 
>> 
> 
> I do not agree that the use of anyxml as arbitrary XML is deployed at all.
> I do not agree that all the "extra XML bits" that are causing so much
> concern
> are ever saved in a datastore.  Martin says we need anyxml for RPC input
> and output. Maybe. This seems proprietary, since no NETCONF/RESTCONF
> operation depends on anything except elements and attributes.
 
 Specifically, we need anyxml for ietf-netconf, since NETCONF is
 supposedly data modeling language agnostic.
 
 One option could be to deprecte anyxml (or remove it) in YANG 1.1, and
 if we ever do a new version of NETCONF, we use anydata instead.
 
>>> 
>>> We are effectively deprecating anyxml in YANG 1.1. We have reached
>>> agreement on Y34-05 and I do not see any new arguments popping up.
>> 
>> There is nothing in 6020bis indicating that "anyxml" is being deprecated.
>> 
> 
> I wrote 'effectively deprecated' and here is the text in 6020bis.
> 
>   Since the use of anyxml limits the manipulation of the content, it is
>   RECOMMENDED that the "anyxml" statement not be used to define
>   configuration data.
> 
>   It should be noted that in YANG version 1, anyxml was the only
>   statement that could model an unknown hierarchy of data.  In many
>   cases this unknown hierarchy of data is actually modelled in YANG,
>   but the exact YANG model is not known at design time.  In these
>   situations, it is RECOMMENDED to use anydata (Section 7.10) instead
>   of anyxml.

The first paragraph is for config data and the second for data that can 
modelled with YANG. If we want to deprecate "anyxml" for use with data that are 
neither of these, 6020bis should say so. I'd be fine with that.

> 
> There is more text in Y34-05 that will go into the guidelines. I call
> this "effectively deprecated", you can call it differently if you
> want. Frankly, this thread is about how to encode anyxml in JSON not
> about the YANG 1.1 issue Y34. You may not like Y34-05 but this is what
> we ended up with.

I am strongly against encoding serialized XML as JSON strings. It is IMO 
totally useless and the spec would have to deal with awkward complications 
because it is not true that arbitrary XML-encoded anyxml content can be used 
without changes in JSON encoding. 

Perhaps the best solution would be to state that JSON encoding is incompatible 
with data models that use "anyxml".

Lada

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

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C




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

Re: [netmod] JSON encoding of anyxml

[Ladislav Lhotka]

> On 11 Nov 2015, at 14:44, Juergen Schoenwaelder 
>  wrote:
> 
> On Wed, Nov 11, 2015 at 02:24:15PM +0100, Ladislav Lhotka wrote:
>> 
>>> 
>>> I wrote 'effectively deprecated' and here is the text in 6020bis.
>>> 
>>>  Since the use of anyxml limits the manipulation of the content, it is
>>>  RECOMMENDED that the "anyxml" statement not be used to define
>>>  configuration data.
>>> 
>>>  It should be noted that in YANG version 1, anyxml was the only
>>>  statement that could model an unknown hierarchy of data.  In many
>>>  cases this unknown hierarchy of data is actually modelled in YANG,
>>>  but the exact YANG model is not known at design time.  In these
>>>  situations, it is RECOMMENDED to use anydata (Section 7.10) instead
>>>  of anyxml.
>> 
>> The first paragraph is for config data and the second for data that can 
>> modelled with YANG. If we want to deprecate "anyxml" for use with data that 
>> are neither of these, 6020bis should say so. I'd be fine with that.
>> 
> 
> The guidelines will say that any usage of anyxml in the IETF will be
> carefully checked by YANG doctors. See Y34 for all details.
> 
>>> There is more text in Y34-05 that will go into the guidelines. I call
>>> this "effectively deprecated", you can call it differently if you
>>> want. Frankly, this thread is about how to encode anyxml in JSON not
>>> about the YANG 1.1 issue Y34. You may not like Y34-05 but this is what
>>> we ended up with.
>> 
>> I am strongly against encoding serialized XML as JSON strings. It is IMO 
>> totally useless and the spec would have to deal with awkward complications 
>> because it is not true that arbitrary XML-encoded anyxml content can be used 
>> without changes in JSON encoding. 
>> 
>> Perhaps the best solution would be to state that JSON encoding is 
>> incompatible with data models that use "anyxml".
>> 
> 
> Perhaps we can only settle this by doing an opinion poll since
> debating this forever is not useful. So what are the options?
> 
> a) The JSON encoding does not define anyxml is not encoded at all. If
>   you use anyxml in a data model, the content will not appear in JSON
>   encodings.
> 
> b) The JSON encoding defines that anyxml data is encoded as a string
>   containing XML.
> 
> c) The JSON encoding defines that anyxml is encoded in whatever way
>   the implementor finds useful.
> 
> d) If the anyxml content is actually valid anydata content, encode it
>   using anydata rules. Content that is not valid anydata content is
>   not encoded at all.
> 
> Any options missing?

Yes, the one that's in yang-json-06:

e) An anyxml instance is encoded as a JSON name/value pair which MUST
   satisfy I-JSON constraints.  Otherwise it is unrestricted, i.e., the
   value can be an object, array, number, string or one of the literals
   "true", "false" and "null".


My preference is e), and then a).

Lada

> 
> Observations:
> 
> - Except b), none of the options is interoperable. Option d) is
>   interoperable for the anydata subset of anyxml.
> - It seems a) is simplest to implement, b) might be expensive to
>   implement and use.
> - Some implementations use internal data stores that can only deal
>   with data that can be modelled with YANG and for those implementations
>   anyxml is effectively the same as anydata and d) migth be close to
>   a) in terms of implementation costs.
> 
> Any other observations missing?
> 
> /js
> 
> -- 
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C




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

Re: [netmod] Modelling ports that can support multiple physical layer standards

[Ladislav Lhotka]

Robert Wilton  writes:

> Hi William,
>
> I'm not that familiar with Broadband physical layer standards, but I 
> have an interest in figuring out some of the physical layer and 
> interface layer relationships in YANG.
>
> There are a couple of things that are not clear to me from your email, 
> so I have two questions:
>
> 1) Am I right to presume that the "type" of the port is fixed, and can't 
> be changed by the handshake mechanism?
> 2) I don't quite understand your last sentence regarding only one 
> interface-level enable/disable leaf.  I would have thought that this 
> would be a benefit.  Please can you elaborate.
>
>
> There is possibly a third way to model this, which is to have an 
> augmentation of a choice statement, i.e.:
> 1. Your base model would define a choice statement representing the 
> physical-layer 'color'.
> 2. Each physical layer 'color' would be a separate augmentation of the 
> choice statement.

Another option might be to come up with a hierarchy of interface types and
then make conditional augments based on the type.

For example, a simple hierarchy could be like this:

multi-color
  red
  green

Now that YANG 1.1 supports multiple inheritance of identities, this
would be just another interface property axis.  

This design is extensible and also allows for fine control of how
individual properties are shared among the "colors".

Lada

>
> Using this design ensures that the model can only ever have a single 
> physical-layer at a given time, and yet still makes it clear which 
> physical-layer is in use and also allows for different configuration 
> nodes for each color.
>
> I've used this structure for modelling layer 2 encapsulation in the IDs 
> that I've put forward:
> E.g. see "choice encaps-type" in draft-wilton-netmod-intf-ext-yang-01 
> for the base model, and two instances of
>
> 'augment 
> "/if:interfaces/if:interface/if-cmn:encapsulation/if-cmn:encaps-type"'
>
> in draft-wilton-netmod-intf-vlan-yang-01 for two example augmentation 
> cover a basic VLAN layer 2 encapsulation, and a more flexible layer 2 
> encapsulation.  Other layer 2 encapsulations could also be defined for 
> PPP, cHDLC, FR, ATM, etc in separate drafts.
>
> Perhaps this choice + augmentation design would also work well in your case?
>
> Thanks,
> Rob
>
>
> On 11/11/2015 09:28, William Lupton wrote:
>> All,
>>
>> We would much appreciate comments and suggestions on the question 
>> posed below.
>>
>> Thanks,
>> William Lupton
>> (Software Architect, Broadband Forum)
>>
>> 
>>
>> In the Broadband Forum we need to model a port that can support 
>> several physical layer standards, but only one at a time. An initial 
>> handshake mechanism determines which of these standards will actually 
>> be used. We have been trying to decide how best to model this 
>> according to the letter and spirit of RFCs 6020, 6087, 7223 etc.
>>
>> Consider a port, a handshake mechanism "color-selector" and two 
>> physical layer standards "green" and "red". Each of these is modelled 
>> via a YANG module of the same name ("port" probably uses the 
>> ietf-entity module). Here are the approaches that we have considered:
>>
>> * Option 1 "direct augment" *
>>
>> color-selector, green and red all directly augment 
>> /if:interfaces/if:interface. An instance of each of them is associated 
>> with the port. See part of the tree here (YANG on request).
>>
>> module: ietf-interfaces
>> +--rw interfaces
>>| +--rw interface* [name]
>>|   +--rw namestring
>>|   +--rw description?string
>>|   +--rw typeidentityref
>>|   +--rw enabled?boolean
>>|   +--rw link-up-down-trap-enable?   enumeration {if-mib}?
>>|   +--rw color-sel:line
>>|   +--rw green:line
>>|   +--rw red:line
>>
>> Note that this means that each port needs three separate interface 
>> objects. For each additional possible supported physical layer 
>> standard, an additional interface object would be needed.
>>
>> * Option 2 "indirect augment" *
>>
>> An additional if-multicolor module directly augments 
>> /if:interfaces/if:interface. An instance of if-multicolor is 
>> associated with the port. if-multicolor has a supported-type leaf-list 
>> that indicates the physical layer standards that are supported by the 
>> port (green and red in this case). color-selector, green and red are 
>> similar to before but this time they augment 
>> /if:interfaces/if:interface/multi:line, and the green and red "when" 
>> (existence) criteria are tied to if-multicolor's supported-type 
>> leaf-list rather than to their own type leaf. See part of the tree 
>> here (YANG on request).
>>
>> module: ietf-interfaces
>> +--rw interfaces
>>| +--rw interface* [name]
>>|   +--rw namestring
>>|   +--rw description?string
>>|   +--rw type

Re: [netmod] JSON encoding of anyxml

[Ladislav Lhotka]

Randy Presuhn  writes:

> Hi -
>
>>From: Juergen Schoenwaelder 
>>Sent: Nov 11, 2015 5:44 AM
>>To: Ladislav Lhotka 
>>Cc: netmod@ietf.org
>>Subject: Re: [netmod] JSON encoding of anyxml
> ...
>>Observations:
>>
>> - Except b), none of the options is interoperable. Option d) is
>>   interoperable for the anydata subset of anyxml.
>> - It seems a) is simplest to implement, b) might be expensive to
>>   implement and use.
>> - Some implementations use internal data stores that can only deal
>>   with data that can be modelled with YANG and for those implementations
>>   anyxml is effectively the same as anydata and d) migth be close to
>>   a) in terms of implementation costs.
>>
>>Any other observations missing?
>
> The problem is similar to the ones that show up with ASN.1 "ANY"
> (but *not* "ANY DEFINED BY") in environments supporting multiple
> encoding rules / transfer syntaxes.
>
> For a recipient to *fully* decode something in such an environment,
> either the encoding has unambiguously identify the grammar of the
> bits in question, or the recipient has to have complete a priori
> knowledge of everything that could possibly be encountered in that
> context, along with any disambiguation logic.
>
> The "ANY DEFINED BY" construct meets that requirement, as long as
> each set of encoding rules properly supports the abstract syntax.
> ASN.1 "ANY" doesn't meet that requirement as soon as things like,
> for example, IMPLICIT tagging come into play.
>
> Netmod and netconf have painted themselves into a corner here:
>   (1) the grammar can't be deduced from an encoding
>   (2) the information identifying the grammar of the payload
>   is not present on the wire, nor is it available in
>   machine-readable form in the data model.  At best it'll
>   be handled on an ad hoc basis if a developer gets around
>   to it for a given leaf.

Right, that's exactly how I see it. Even if anyxml is deprecated in
standard modules, I believe it may be useful if an implementation has
the possibility to send some non-YANG data, for one reason or
another. The vendor can then write a one-off module for this purpose
and that's all.

Lada

>
> This means that, as a practical matter, it's not going to be
> practical or interoperable to treat the payloads of these types
> as anything other than (octet) strings for transport.  Attempts
> to convert a value based on the (wrapping) transfer syntax will
> only work for senders that know the payload's grammar.  Generic
> recipients and particularly relays would be Simply Out of Luck.
>
> Randy
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

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

Re: [netmod] JSON encoding of anyxml

[Randy Presuhn]

Hi -

>From: Juergen Schoenwaelder 
>Sent: Nov 11, 2015 5:44 AM
>To: Ladislav Lhotka 
>Cc: netmod@ietf.org
>Subject: Re: [netmod] JSON encoding of anyxml
...
>Observations:
>
> - Except b), none of the options is interoperable. Option d) is
>   interoperable for the anydata subset of anyxml.
> - It seems a) is simplest to implement, b) might be expensive to
>   implement and use.
> - Some implementations use internal data stores that can only deal
>   with data that can be modelled with YANG and for those implementations
>   anyxml is effectively the same as anydata and d) migth be close to
>   a) in terms of implementation costs.
>
>Any other observations missing?

The problem is similar to the ones that show up with ASN.1 "ANY"
(but *not* "ANY DEFINED BY") in environments supporting multiple
encoding rules / transfer syntaxes.

For a recipient to *fully* decode something in such an environment,
either the encoding has unambiguously identify the grammar of the
bits in question, or the recipient has to have complete a priori
knowledge of everything that could possibly be encountered in that
context, along with any disambiguation logic.

The "ANY DEFINED BY" construct meets that requirement, as long as
each set of encoding rules properly supports the abstract syntax.
ASN.1 "ANY" doesn't meet that requirement as soon as things like,
for example, IMPLICIT tagging come into play.

Netmod and netconf have painted themselves into a corner here:
  (1) the grammar can't be deduced from an encoding
  (2) the information identifying the grammar of the payload
  is not present on the wire, nor is it available in
  machine-readable form in the data model.  At best it'll
  be handled on an ad hoc basis if a developer gets around
  to it for a given leaf.

This means that, as a practical matter, it's not going to be
practical or interoperable to treat the payloads of these types
as anything other than (octet) strings for transport.  Attempts
to convert a value based on the (wrapping) transfer syntax will
only work for senders that know the payload's grammar.  Generic
recipients and particularly relays would be Simply Out of Luck.

Randy

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

Re: [netmod] JSON encoding of anyxml

[Juergen Schoenwaelder]

On Wed, Nov 11, 2015 at 07:34:23AM +0100, Martin Bjorklund wrote:
> Andy Bierman  wrote:
> > On Tue, Nov 10, 2015 at 6:16 AM, Robert Varga  wrote:
> > 
> > > Hello,
> > >
> > > I am not favor of it, either, but RFC6020 is here and is being widely
> > > deployed. So is RESTCONF+JSON, which is favored by application developers
> > > in the field today, as is NETCONF devices producing anyxml. We do need a
> > > reasonable way of bridging the two -- no matter whether it is 
> > > configuration
> > > or operational data.
> > >
> > >
> > 
> > I do not agree that the use of anyxml as arbitrary XML is deployed at all.
> > I do not agree that all the "extra XML bits" that are causing so much
> > concern
> > are ever saved in a datastore.  Martin says we need anyxml for RPC input
> > and output. Maybe. This seems proprietary, since no NETCONF/RESTCONF
> > operation depends on anything except elements and attributes.
> 
> Specifically, we need anyxml for ietf-netconf, since NETCONF is
> supposedly data modeling language agnostic.
> 
> One option could be to deprecte anyxml (or remove it) in YANG 1.1, and
> if we ever do a new version of NETCONF, we use anydata instead.
>

We are effectively deprecating anyxml in YANG 1.1. We have reached
agreement on Y34-05 and I do not see any new arguments popping up.

The JSON encoding document has to specify the encoding of an
effectively deprecated construct that was designed to encode any XML.

/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