Subject: [netmod] comments on draft-ietf-netmod-yang-json-00.txt

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 15 Jul 2014 13:55:11 +0200

I have reviewed draft-ietf-netmod-yang-json-00.txt and I have a couple
of questions.

* Relationship to <draft-ietf-json-i-json-02>:

  - Lada, you once said that the JSON mapping leads to an I-JSON
    message. I note that I-JSON puts constraints on say object member
    names (section 2.1). Do we have the same constraints in YANG?

  - There is a recommendation (section 2.3) to encode large integers
    (e.g. 64-bit integer values) as JSON string values.

  - What about the other recommendations, e.g. base64 vs. base64url?

  Would it make sense to add a section to explain the relationship of
  the JSON mapping of YANG to I-JSON messages?

* Numbers

  RFC 7159 makes me believe numbers are always treated as floating
  point numbers in JSON and hence there are precision limits. Note
  that RFC 7159 says:

    Note that when such software is used, numbers that are integers and
    are in the range [-(2**53)+1, (2**53)-1] are interoperable in the
    sense that implementations will agree exactly on their numeric
    values.

  So how does this work with out 64-bit integer types?

  And should there be a discussion of YANG's decimal64 type? Can JSON
  parsers always be expected to treat them nicely?

* Namespaces

  Is the module qualified notation a common convention or could it be
  that JSON people eventually pick a different solution for dealing
  with namespaces?

* IANA

  The question should be answered, one way or the other.

* Security Considerations

  An empty sections considerations section is not good.

* Updates

  [IF-CFG] became [RFC 7223]

/js

-- 
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: Ladislav Lhotka <[email-masked]>
Date: Sun, 20 Jul 2014 10:12:55 -0400

Hi Juergen,

thanks for reviewing the draft.

>     names (section 2.1). Do we have the same constraints in YANG?

Yes, a member name in our case can be:
- YANG identifier
- pair of colon-separated YANG identifiers (explicit namespace)

Names of metadata objects also include "@".

>     (e.g. 64-bit integer values) as JSON string values.

It is an option to encode int64 and uint64 as strings, although it would
be awkward.

>   - What about the other recommendations, e.g. base64 vs. base64url?

IMO, in this case we should stick to base64 because this is what YANG
prescribes for the "binary" type. I don't think we need URL-safe
encoding.

>   the JSON mapping of YANG to I-JSON messages?

Yes, although I don't know whether it is a good idea to use it as a
normative reference.

>     sense that implementations will agree exactly on their numeric

I-JSON spec even says that the sender MUST NOT expect the receiver to treat
an integer outside that range as an exact value.

>   So how does this work with out 64-bit integer types?

For such large values it doesn't, I am afraid.

>   parsers always be expected to treat them nicely?

Probably not, it is the same problem. However, I wonder whether large
decimal64 values can be safely processed even if they are passed in XML
- most likely they will end up as double precision numbers anyway.

>   that JSON people eventually pick a different solution for dealing

There is no standard solution. Expired I-D

http://tools.ietf.org/html/draft-saintandre-json-namespaces-00

proposed to use James Clark's notation, {URI}local-name, e.g.

{urn:ietf:params:xml:ns:yang:iana-if-type}interface

We are lucky that we can avoid the URI-prefix duality by using the
module name. And using colon as the separator is natural because it is
not allowed in identifiers.

>   The question should be answered, one way or the other.

RESTCONF spec registers the application/yang.data media type. I actually
think it would be more appropriate to bundle the registration with the
specification of the data format because the format can be used in
different protocols. So maybe the best place is 6020bis?
 
>   [IF-CFG] became [RFC 7223]

Yes, I will write Security Considerations and update references in the next revision.

Thanks, Lada

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

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 20 Jul 2014 20:17:44 +0200

> - pair of colon-separated YANG identifiers (explicit namespace)

OK, makes sense.
 
> It is an option to encode int64 and uint64 as strings, although it would

According to RFC 7158, numbers in JSON seem to be considered to be
floating point numbers by typical applications and there is specific
advice on the precision that can be achieved in such situations:

I think we need to discuss this issue somewhere in the document. Even
if we go with a plain representation of large integral numbers, there
probably needs to be a warning somewhere. (I just checked json-c and
it seems to represent numbers as json_type_double.)

> prescribes for the "binary" type. I don't think we need URL-safe

I must admit that I do not really understand the story behind
base64url but the i-json document RECOMMENDs its usage.

> Yes, although I don't know whether it is a good idea to use it as a

I guess the question is how long I-JSON remains a moving target? The
charter says IETF last call in June 2014. ;-)

> - most likely they will end up as double precision numbers anyway.

A proper implementation needs to process fixed point data as fixed
point data. That said, I think we need to look how we deal with the
differences of the number spaces. (This reminds me when Java SNMP
API's came along and due to a lack of unsigned numbers, things we
simply mapped to the larger numeric type and for 64-bit numbers the
"solution" was to simply drop a bit. I think we should do better.)

> different protocols. So maybe the best place is 6020bis?

Lets keep things focussed on the JSON document. So you are saying there
is nothing to do. Then I suggest to write this down.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Sun, 20 Jul 2014 18:31:48 -0400

> I think we need to discuss this issue somewhere in the document. Even

I agree, and we also have to decide whether the mapping needs to be changed. I assume there isn’t much excitement about representing numbers as strings.

> base64url but the i-json document RECOMMENDs its usage.

I will probably ask in the JSON mailing list.

> charter says IETF last call in June 2014. ;-)

Yes, that's why I am a bit reluctant to put it there. 

> point data. That said, I think we need to look how we deal with the

The problem is that decimal number isn't usually available as a built-in type.

> "solution" was to simply drop a bit. I think we should do better.)

Yes. We have the advantage that the exact type is known, so there should be no excuse. On the other hand, developers want to use existing JSON parsers.   

> is nothing to do. Then I suggest to write this down.

OK.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 21 Jul 2014 00:45:22 +0200

> The problem is that decimal number isn't usually available as a built-in type.

Yes, but an implementation can do the right thing if we provide the
opportunity to do the right thing. If the JSON parser already messes
up the numbers, the implementation has lost. Or are you saying to do
the right thing, implementations can't use a stock JSON parsers? That
would also be somewhat disappointing...

/js