On Mon, Jun 15, 2015 at 10:49:28PM +0000, Kent Watsen wrote:
>
> This is a notice to start a NETMOD WG last call for the document "JSON
> Encoding of Data Modeled with YANG":
>
> https://tools.ietf.org/html/draft-ietf-netmod-yang-json-04
>
> Please indicate your support by Monday June 29, 2015 at 9PM EST.
Hi,
I have reviewed draft-ietf-netmod-yang-json-04.
- I am not sure I agree with the wording in section 3. Why is section
8.3.3 only applicable to XML encoded data? Validation applies to
datastores. While constraints are defined using XML-based notations
such as XPATH, how the validation is carried out is not defined in
the YANG specifications. I guess I actually disagree with the
wording in section 3 of the JSON encoding I-D.
- It is unclear whether the 'if and only if' on page 4 means that an
implementation that generates namespace prefixes that are not
strictly needed is violating this I-D. I see the need for a MUST to
include the module name if the parent node belongs to a different
module. I am not sure why it is necessary to mandate minimal
encodings (if that is the idea here). Whatever the answer is, it
would be good to use RFC 2119 language.
- The reason for the requirement that list keys are encoded first in
RFC 6020 is to make it easier to process data in a stream-oriented
fashion. If keys can appear anywhere, they might appear at the very
end and thus buffering is required in order to process data
properly. Is this concern not relevant for the JSON encoding?
Perhaps this is not relevant, but then we might also state this
explicitly:
As a consequence, implementations must be cable to buffer JSON
encoded instances in order to locate keys that may appear at the
end of a JSON encoded instance.
- I think that section 5.5 should say:
If the data model for the data in an anydata instance is known,
then the data must be encoded following the rules defined in
this I-D.
In other words, it is not arbitrary JSON with a few constraints but
something that matches the JSON encoding rules once the data model
is known.
- Section 6, I suggest s/mapped/encoded/.
- I do not understand 'An "enumeration" value is mapped in the same
way as a string except that permitted values are defined by enum
statements in YANG.' Perhaps this is simpler:
An "enumeration" value is encoded as a JSON string. The allowed
string values are the enumeration names assigned by the enum
statement in YANG.
The representation is identifical to the XML encoding, see
sec. 9.6 in [RFC6020bis].
I specifically tried to avoid 'value' in order to avoid confusion with
the value YANG statement.
- Perhaps remove the reference to XML in section 6.5 from the
definition of the encoding rules so that the JSON encoding rules are
not tied into the XML encoding rules. It is OK to mention that it is
the same.
A "bits" value is encoded as a JSON string. Multiple bit names
assigned by the bit statement in YANG are encoded as a
space-separated string of bit names representing the individual
bits that are set.
The representation is identifical to the XML encoding, see
sec. 9.7 in [RFC6020bis].
- Same as before for section 6.6:
A "binary" value is encoded by first encoding the binary value in
base64 and encoding the resulting base64-encoded value as a JSON
string.
The representation is identifical to the XML encoding, see
sec. 9.8 in [RFC6020bis].
- I am not sure I understand the argument why [null] is better than
null for the empty type. Perhaps it is but the text does not really
tell me.
- I suggest to remove the reference to 9.13.3 in the definition. In
fact, the representation is pretty different since XML uses
namespace prefixes while JSON uses module names. (I must admit that
I find the JSON representation more readable since it does not
require XML namespace context.)
- Section 7: So what happens in the rare case of a binary value
appearing in a RESTCONF URI? Is the resulting BASE64 value than
simply subject to URI escaping rules?
I assume this 'rare event' would happen if a list is indexed by a
leaf of type binary, no? Are there any other cases?
/js
PS: Should RFC 6020bis change the section titles "XML Mapping Rules" to
"XML Encoding Rules"? I think we really talk about 'encoding', not
about 'mapping' and if we agree on this, we should try to be
consistent with the terms we use.
--
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/>
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
