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. > > 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. > > - 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 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. > > - 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): 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. /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/> _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
