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

[Ladislav Lhotka <[e-mail]>]

Hi Juergen,

thanks for reviewing the draft.

Juergen Schoenwaelder <[e-mail]> writes:

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

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 "@".

>
>   - There is a recommendation (section 2.3) to encode large integers
>     (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.

>
>   Would it make sense to add a section to explain the relationship of
>   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.

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

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.

>
>   And should there be a discussion of YANG's decimal64 type? Can JSON
>   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.

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

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.

>
> * IANA
>
>   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?
 
>
> * Security Considerations
>
>   An empty sections considerations section is not good.
>
> * Updates
>
>   [IF-CFG] became [RFC 7223]

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

Thanks, Lada

>
> /js
>
> -- 
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: [phone]         Campus Ring 1, 28759 Bremen, Germany
> Fax:   [phone]         <http://www.jacobs-university.de/>
>
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod

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