> On 03 Feb 2016, at 13:58, Benoit Claise <bcla...@cisco.com> wrote: > > Hi Lada, > > Thanks for the quick reply. >> Hi Benoit, >> >> thank you for the review, please see my responses inline. >> >> Benoit Claise <bcla...@cisco.com> writes: >> >>> Dear all, >>> >>> I understood from the chairs that draft-ietf-netmod-yang-json is now >>> ready and that the write-up will be completed end of this week. >>> In order to speed up the publication, here is my AD review. >>> >>> - Editorial: >>> >>> This document defines encoding rules for representing configuration, >>> state data, RPC operation or action input and output parameters, and >>> notifications defined using YANG as JavaScript Object Notation (JSON) >>> text. >>> >>> "RPC operation or action input and output parameters" >>> ", or ... and, " it's always complicated. >>> Why not only "RPC operation or action"? >> Because we aren't encoding operations, just their parameters. > Good point. >> >>> At the very minimum "input and output parameters" to "input/output >>> parameters" >> OK, so how about using just "parameters of RPC operations or actions" in >> the abstract, and "input/output parameters of RPC operations or actions" >> elsewhere? > Sure.
Done. >> >>> Same remark for section 1.1 >>> >>> The specification of YANG 1.1 data modelling language >>> [I-D.ietf-netmod-rfc6020bis >>> <https://tools.ietf.org/html/draft-ietf-netmod-yang-json-06#ref-I-D.ietf-netmod-rfc6020bis>] >>> defines only XML encoding for data >>> instances, i.e., contents of configuration datastores, state data, >>> RPC operation or action input and output parameters, and event >>> notifications. >>> >>> If you want to extend, also fine. >>> >>> The specification of YANG 1.1 data modelling language >>> [I-D.ietf-netmod-rfc6020bis >>> <https://tools.ietf.org/html/draft-ietf-netmod-yang-json-06#ref-I-D.ietf-netmod-rfc6020bis>] >>> defines only XML encoding for data >>> instances, i.e., contents of configuration datastores, state data, >>> RPC operation input and output parameters, action input and output >>> parameters, and event notifications. >>> >>> Btw, "RPC", "action" and "input and output parameters" are only >>> mentioned in the abstract and this introduction, not anymore in the body >>> of the document. There is nothing specific to these worth noting? Not >>> even an example? >> This document is about encoding YANG data nodes, and the rules are the >> same for any data tree. > Not worth mentioning something such as > " There is nothing specific to input and output parameters compared to any > other data tree..."? OK, I'll add such a note. ... >> I agree with Juergen that 6087bis should distinguish between complete >> example modules and short module snippets that are used for explaining a >> certain YANG language or encoding issue. If you look at this particular >> example, then changing the JSON document on p. 6 to >> >> { >> "example-foomod:top": { >> "foo": 54, >> "example-barmod:bar": true >> } >> } >> >> would IMO just add noise and blur the message the example is supposed to >> convey. > So please fix the text in 6087bis. > Until it's done, I'll stick to the current rule. I don't want to be excessively bureaucratic but, strictly speaking, current rules are those of RFC 6087 that contains no such requirement, so we should be OK for now. And I think there is enough consensus to change the corresponding 6087bis text - after all, 6020bis also has example modules whose names don't start with "example-". Thanks, Lada > > Regards, Benoit -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
