Juergen Schoenwaelder <j.schoenwael...@jacobs-university.de> writes: > On Mon, Jun 29, 2015 at 11:49:11AM +0200, Ladislav Lhotka wrote: >> Hi Juergen, >> >> thank you for the review. >> >> Juergen Schoenwaelder <j.schoenwael...@jacobs-university.de> writes: >> >> > 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 >> >> You are right that this section shouldn't talk about XML-encoded data, >> i.e. serialized form. On the other hand, XPath 1.0 spec says: "XPath >> operates on the abstract, logical structure of an XML document, …". >> >> So I think a datastore needs to be represented, at least conceptually, >> as XML infoset. >> >> > such as XPATH, how the validation is carried out is not defined in >> > the YANG specifications. I guess I actually disagree with the >> >> I don't think this is true. YANG spec doesn't say how "must" and "when" >> statements are evaluated, and relies on XPath. > > RFC 6020: > > When a datastore is validated, all "must" constraints are > conceptually evaluated once for each data node in the data tree, and > for all leafs with default values in use (see Section 7.6.1). If a > data node does not exist in the data tree, and it does not have a > default value, its "must" statements are not evaluated. > > [...] > > Also note that the XPath expression is conceptually evaluated. This > means that an implementation does not have to use an XPath evaluator > on the device. How the evaluation is done in practice is an > implementation decision.
Yes, but the result must be guaranteed to be the same as if an XPath 1.0 processor is used, otherwise it makes really no sense. > >> > wording in section 3 of the JSON encoding I-D. >> >> What specifically? Do you have any suggestions for changes? > > The problem is that RFC 6020 talks about datastore validation, not > about validation of a specific serialization. Hence, it does not > matter whether the data was XML or JSON (or CBOR or whatnext) encoded > - once the data is in the datastore, datastore validation takes > place. One way to implement this is to serialize everything to XML and > then to use XML gear to do the validation. But this implementation > strategy is not required. We have no explicit concept of a metamodel for datastores but IMO the fact that we evaluate XPath expressions on top of it implies that the datastore must be (congruent to) restricted XML infoset. Section 5 (Data Model) is a crucial part of XPath spec, and it is XML. > >> > - 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 >> >> Yes, that's the intention. Why is it unclear? >> >> > 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. >> >> Revision -02 used 2119 terms but there were objections against it: >> >> https://mailarchive.ietf.org/arch/msg/netmod/xXS0uSKKu83qBQVCJ_CYmdsavUc >> >> In fact, YANG spec also states syntax rules without using 2119 keywords, >> for example "Each identifier starts with an uppercase or lowercase ASCII >> letter or an underscore character, …", it doesn't say that it MUST NOT >> start with anything else. > > If the goal is to define a strict implementation requirement, then I > think using RFC 2119 language is the preferred choice in the IETF. I I guess identifier syntax is a strict implementation requirement, too. What the I-D defines is an unambiguous encoding of data. > think the debate back then was whether it is reasonable to declare an > implementation that fails to produce minimal encodings as violating > the spec. How does it break a receiver if I send a redundant module > name? Your change of the MUST to 'if and only if' did cosmetics but it > did not address the concern raised. Yes, but these are two different things: 1. In my view, in any syntax or encoding specification 2119 keywords are not needed, in fact they are inappropriate. 2. There are strong technical reasons for *not* relaxing the namespace rules - it would again render of-the-shelf JSON parsers pretty much useless, as Martin correctly pointed out: https://mailarchive.ietf.org/arch/msg/netmod/mCtvup_YnL3gvr95EIe4sSFcKfs > >> > - 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? >> >> This cannot be required as long as our aim is interoperability of >> implementations based on off-the-shelf JSON parsers, hence I_JSON. RFC >> 7493 states it clearly: "The order of object members in an I-JSON >> message does not change the meaning of an I-JSON message." >> >> > 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 it is clear that an implementation needs to be able to handle >> keys appearing anywhere in a list-entry-object. How it is handled is IMO >> implementation-specific - I guess it also depends on where and how the >> stream-oriented data processing is used. > > I still prefer to have this explicitly stated. If the keys happen to > appear at the end, how can you process the data without some form of > buffering? Perhaps this wording is better (since it is less specific > how data is buffered): Maybe the keys are just irrelevant for the given purpose, e.g. when streaming state data. As a matter of fact, with JSON encoding the receiving side will mostly buffer the whole payload anyway. I can add that sentence, if you insist, but I see it as superfluous. > > As a consequence, implementations must be cable to buffer data > 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. >> >> Something like this should then probably appear in 6020bis, yet it doesn't. >> >> I am unclear how one can determine that the data model is known because >> anydata nodes don't provide this information. Perhaps it can be >> specified in the description but then is it known including the >> revisions of YANG modules involved? Moreover, the data model needn't be >> known at all. > > Yes, this is why the sentence starts with "If the data model ... is > known," > >> Therefore, I tend to think about anydata as kind of ad hoc data >> that's just piggybacked inside YANG-modelled data. There may be rules >> that this data have to conform to (expressed in YANG or not) but they >> are out of scope from the perspective of the data model that's specified >> in hello or yang-library. >> >> That's why sec. 5.5 only states syntactic constraints to make sure that >> the data "can be modelled with YANG". >> >> BTW, I have a growing concern that anydata creates more problems than it >> solves. > > I fail to see that but this is not relevant here as long as the JSON > document provides a means to encode anydata in an interoperable way. It depends on what you call "interoperability", but if there is no (precise) data model available for anydata content, then the round-trip JSON client -> server -> XML client (or the other way around) may not be possible. So I don't get how "anydata" fixes "anyxml" problems (I personally only have problem with the name). Lada > > /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/> -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
