On Tue, Jun 30, 2015 at 02:56:30PM +0200, Ladislav Lhotka wrote: > 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.
The YANG language does not require that XPath is used. It says that XPath is conceptually evaluated. Should the text in an encoding document not be consistent with that? > > > >> > - 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 OK > >> > - 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. Thanks. > > 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 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). We are not discussing this anymore. /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
