Subject: [netmod] VRFY :Y34: remove/deprecate/replace the 'anyxml' statement

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 7 Jan 2015 15:59:43 +0100

The 2014-12-03 virtual interim meeting proposal is to adopt Y34-04.
Please speak up by Wednesday 2015-01-14 if you disagree with this
proposal.

For more details, see the issues list and the virtual interim meeting
minutes available here:

     http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: [email-masked]
Date: Thu, 8 Jan 2015 09:15:42 +0800

Hi,
  Y34-04 is ugly. Why use 'root' statement? The meaning of 'root' is not 
clear. I prefer Y34-02, introduce 'anydata' statement. 

Frank Feng   冯冲
BN Product Team
BN产品团队

Add: ZTE Corporation, 50 Software Avenue, YuHuaTai District, Nanjing, P.R. 
China,210012
南京市雨花台区软件大道50号中兴通讯
Mp:+86-18913852612
E-mail: [email-masked]

Juergen Schoenwaelder <[email-masked]> 
发件人:  "netmod" <[email-masked]>
2015-01-07 22:59
请答复 给
Juergen Schoenwaelder <[email-masked]>

收件人
[email-masked], 
抄送

主题
[netmod] VRFY :Y34: remove/deprecate/replace the 'anyxml' statement

_______________________________________________
netmod mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netmod

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s).  If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited.  If you have received this mail in error, please delete it and notify us immediately.
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s).  If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited.  If you have received this mail in error, please delete it and notify us immediately.

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 08 Jan 2015 10:37:28 +0100 (CET)

Hi,

> The 2014-12-03 virtual interim meeting proposal is to adopt Y34-04.

I don't think Y34-04 is sufficient.  If I understand Y34-04 (add
'root) correctly, the difference between it and Y34-02 (add 'anydata')
is that 'root' is a special case of 'anydata'; i.e., 'root' behaves as
'anydata' with the constraint that it only can hande top-level nodes.

As an example of why this is not sufficient, YANG PATCH uses anyxml
with non-top-level nodes.  It would not be possible to use 'root' in
this case.  'anydata' would be a better match.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 21 Jan 2015 11:21:44 +0100

> this case.  'anydata' would be a better match.

Andy,

can you please respond to this since you created Y34-04? I now hear
two people in favour of Y34-02 and we had this back in July 2014:

   2014-07-21 meeting proposal and action: adopt Y34-02, AB to work out
   a concrete proposal.

So is the main delta of Y34-04 compared to Y34-02 (i) the additional
text (the three list items) or (ii) additional restrictions of "root"
to top-level nodes. (The Y34-04 referes to ncx:root which is not known
to everybody.)

Would adoption of Y34-02 with the additional text (the three list
items) of Y34-04 be a workable solution?

/js

---

From: Andy Bierman <[email-masked]>
Date: Wed, 21 Jan 2015 07:05:03 -0800

> to top-level nodes. (The Y34-04 referes to ncx:root which is not known

There are corner cases like YANG Patch edit value that need to be
anyxml.

> items) of Y34-04 be a workable solution?

yes

> /js

Andy

---

From: Andy Bierman <[email-masked]>
Date: Thu, 22 Jan 2015 15:57:36 -0800

>> items) of Y34-04 be a workable solution?

The discussion in the last VI meeting seemed to favor this solution
but there is still this issue of JSON -> XML -> JSON round-trip
conversion of anydata (unstructured data).

IMO the loss of JSON typing through the XML conversion
is not an issue because the only schema that matters is
the YANG anydata.  E.g.,  booleans and numbers are
just strings. null is not supported.  All simple nodes are
strings.  There are no keys so there are no real arrays.
The server may return multiple containers that could
have been encoded as an array.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 23 Jan 2015 08:56:51 +0100

> have been encoded as an array.

Yes, the JSON I-D must be updated to define how anydata is encoded.

In general, I believe a JSON receiver must be able to do conversions
if needed, that is, if the JSON type does not match the type of the
YANG data model, the receiver must convert as needed instead of
throwing an error. I believe the YANG type is authoritative, not the
type used in the encoding. Lada may not like this but since the two
type systems do not align 1:1, I think giving the YANG type system
authority is the way to go. And the principle "the receiver converts
as needed" instead of throwing an error follows the Postel principle.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 23 Jan 2015 10:34:10 +0100

> have been encoded as an array.

So it seems JSON encoding will change (compared to
draft-ietf-netmod-yang-json-02, sec. 5.5) only so that null will be
allowed only in a single-element array ("[null]") and array containing
both scalar values and objects/arrays won't be allowed.

Is it correct?

Lada

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

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 23 Jan 2015 11:14:07 +0100

> type used in the encoding. Lada may not like this but since the two

Well, I fully agree that YANG types should be authoritative but,
strangely enough, it leads me to a completely different conclusion: If a
leaf is defined as uint8, and both parties are supposed to know that,
why should the sender want to encode it as string?

> as needed" instead of throwing an error follows the Postel principle.

If Postel principle is so great, why don't we allow 42.0 as a valid
value of uint8? Why don't we allow "001.002.003.004" as a valid IPv4
address?

Lada

---

From: Andy Bierman <[email-masked]>
Date: Fri, 23 Jan 2015 04:04:00 -0800

> why should the sender want to encode it as string?

Because we are talking about anyxml, not uint8.
The entire point of anyxml is that is carries absolultely
no YANG schema information whatsoever.
The peer parsing the node has no way to associate
uint8 with any sub-node of the anyxml blob.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 23 Jan 2015 13:08:14 +0100 (CET)

> uint8 with any sub-node of the anyxml blob.

In the generic case this is true.

But for example in YANG PATCH, the target node is known from the
context, so the anydata blob can/will be parsed according to the
schema.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 23 Jan 2015 13:12:04 +0100

> why should the sender want to encode it as string?

a) In the context of anydata, the sender may simply not have the type
   information.

b) In other contexts, there might be translators involved or encoding
   layers that have not access to the type information.

And there is always conversion since we will send 64-bit ints as
strings etc. The JSON type in the encoding simply is not authoritative
and dropping messages because someone did send 5 instead of "5" or
"False" instead of False in JSON seems counter productive if our goal
is interoperability.

/js

---

From: Andy Bierman <[email-masked]>
Date: Fri, 23 Jan 2015 04:14:37 -0800

> context, so the anydata blob can/will be parsed according to the

This is a corner-case full of implementation details.
e.g., all the data can be passed before all the resource
offsets that identify the schema.  There is nothing except
description-stmt text to associate the target leaf with
the anyxml blob.  Not sure how an off-the-shelf tool could
ever implement YANG Patch correctly.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 23 Jan 2015 13:17:11 +0100

> On 23 Jan 2015, at 13:04, Andy Bierman <[email-masked]> wrote:
> 

Yes, but Juergen talks about YANG types, i.e. not about anyxml/anydata, so I responded to it.

> uint8 with any sub-node of the anyxml blob.

The peer may have other non-YANG knowledge about the types, or not. I agree that a client sending a JSON number must be prepared to receive it back as string. I just don’t agree that only strings be allowed in JSON encoding of anydata.

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 23 Jan 2015 13:22:14 +0100 (CET)

> ever implement YANG Patch correctly.

Agreed.

But I think that this case might be pretty common - i.e., from some
context the schema of the anydata blob will eventually be known.  For
example, we could do:

 list logged-notification {
   key id;
   leaf id { ... }
   leaf device-address { ... }
   // more meta-data here
   anydata notification;
 }

The implementation of the logged-notification list doesn't have to
know all the notifications, but a consumer that knows the schema of
some or all notifications can use this info to parse the data.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 23 Jan 2015 14:14:07 +0100

> a) In the context of anydata, the sender may simply not have the type

You mentioned YANG types first, and YANG types have nothing to do with
anyxml/anydata.

>    layers that have not access to the type information.

Yes, I understand that: there is software that's primarily developed for
XML and the developers want to minimize the impact of a new encoding on
their code.

However, for someone who starts a new JSON-only implementation in
anything else than Javascript, the idea of converting JSON numbers to
strings must look really weird.

> strings etc. The JSON type in the encoding simply is not authoritative

Yes, unfortunately. Note that even in the JSON WG not everybody is happy
with this I-JSON restriction: 

http://www.ietf.org/mail-archive/web/json/current/msg03577.html

> "False" instead of False in JSON seems counter productive if our goal

The same can be said about sending "42.0" instead of "42".

I think the correct solution for the JSON encoding spec is to require
that JSON encoding be in accordance with the YANG type (again, this is
not about anydata). If the receiving side wants to be liberal and
tolerate type violations, it's fine with me.

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 23 Jan 2015 14:43:51 +0100

> On 23 Jan 2015, at 13:22, Martin Bjorklund <[email-masked]> wrote:
> 

Exactly, and that’s why I want to leave it open whether what’s received in anydata as <foo>42</foo> will be sent in JSON encoding as

"foo": "42"

or

"foo": 42.

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 23 Jan 2015 14:47:17 +0100 (CET)

Ladislav Lhotka <[email-masked]> wrote:
> Exactly, and that’s why I want to leave it open whether what’s
> received in anydata as <foo>42</foo> will be sent in JSON encoding as
> 
> "foo": "42"
> 
> or
> 
> "foo": 42.

Isn't this what Juergen also proposed?  Basically allow both a
schema-faithful encoding, and a generic, "string"-based encoding.  (it
affects more than just leaf types though).  A receiver MUST (?) be
able to handle both styles of encodings.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 23 Jan 2015 15:01:23 +0100

> On 23 Jan 2015, at 14:47, Martin Bjorklund <[email-masked]> wrote:
> 

In a previous discussion Juergen didn’t seem to be happy with this approach:

http://www.ietf.org/mail-archive/web/netmod/current/msg10473.html

> able to handle both styles of encodings.

I don’t think it is necessary. Any use of anydata probably requires that both parties are aware of what the contents are. How they behave is then IMO outside the scope of YANG.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Fri, 23 Jan 2015 08:43:52 -0800

> http://www.ietf.org/mail-archive/web/netmod/current/msg10473.html

You mean this example:

(1)
{
  "x": {
      "y": "<a xmlns:foo='urn:foo'> <foo:b>4668</foo:b> </a>"
    }
}

This is a strange corner-case that does not exactly survive a round-trip.

Of course the "y" string content will be rendered in XML with
character entities.

(2)
  <y>&lt;a xmlns:foo='urn:foo'&gt; &lt;foo:b&gt;4668&lt;/foo:b&gt;
&lt;/a&gt;</y>

The return JSON is changed:

(3)
{
  "x": {
      "y": "&lt;a xmlns:foo='urn:foo'&gt;
&lt;foo:b&gt;4668&lt;/foo:b&gt; &lt;/a&gt;"
    }
}

What use-case does this serve?
I have never seen a real operation do something like this.

Supposedly this conversion can happen if the node /x is configuration data.
Client A sets /x in JSON.  (1)
Client B does a GET /x in XML and then a PUT /x in XML. (2)
Client A reads /x in JSON (3)

> I don’t think it is necessary. Any use of anydata probably requires that both parties are aware of what the contents are. How they behave is then IMO outside the scope of YANG.

Our implementation would never generate anything like (1).
Instead, the structure would be passed in JSON, not encoded as a string:

(4)
{
  "x": {
      "y": {
          "foo:a" : {
             "b": "4668"
           }
        }
    }
}

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Sat, 24 Jan 2015 06:07:33 +0100

> On 23 Jan 2015, at 17:43, Andy Bierman <[email-masked]> wrote:

…

>> http://www.ietf.org/mail-archive/web/netmod/current/msg10473.html

No, not only this particular example. Throughout the discussion, Juergen always wanted (or at least so I understood him) to have a fixed mapping between XML- and JSON-encoded anyxml content, i.e. one that’s the same for all anyxml nodes. My preference has been to be able to handle each anyxml in a specific way - sometimes a schema is available, sometimes isn’t.

Lada