Hi Benoit, thank you for the review, please see my responses inline.
Benoit Claise <[email protected]> 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. > > 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? > > 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. Encoding of operations or notifications is a subject for a protocol spec, and RESTCONF does provide examples. > > - Editorial > > In the introduction, you might want to complete the last sentence > > NEW: > The specification of YANG 1.1 data modelling language > [I-D.ietf-netmod-rfc6020bis > <https://tools.ietf.org/html/draft-ietf-netmod-yang-json-07#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. The aim of this document is to define rules for > encoding the same data as JavaScript Object Notation (JSON) > text [RFC7159 <https://tools.ietf.org/html/rfc7159>]. > > NEW: > The specification of YANG 1.1 data modelling language > [I-D.ietf-netmod-rfc6020bis > <https://tools.ietf.org/html/draft-ietf-netmod-yang-json-07#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. The aim of this document is to define rules for > encoding the same data as JavaScript Object Notation (JSON) > text [RFC7159 <https://tools.ietf.org/html/rfc7159>], most precisely the > Internet JSON (I-JSON) restricted > profile [RFC7493 <https://tools.ietf.org/html/rfc7493>]. I would say that for the introduction the more general term (JSON) is appropriate, the reasons for sticking to I-JSON are explained later. In fact, this document specifies a profile that's even more restricted than I-JSON. > > > - > section 2: > > The following terms are defined in [I-D.ietf-netmod-rfc6020bis > <https://tools.ietf.org/html/draft-ietf-netmod-yang-json-07#ref-I-D.ietf-netmod-rfc6020bis>]: > ... > > o identity, > > There is no identity definition in the RFC 6020 terminology section. Maybe it is an omission in 6020bis? > Are you referring to the identity statement, > https://tools.ietf.org/html/draft-ietf-netmod-rfc6020bis-09#section-7.18 > ? No, I am referring to a "globally unique, abstract, and untyped identity" (sec. 7.18 in 6020bis) that's defined by an "identity" statement. > > - Editorial. > > OLD: > An object member name MUST be in one of the following forms: > NEW: > A JSON object member name MUST be encoded in one of the following forms: > OK. > > - > module foomod { > > namespace"http://example.com/foomod";; > > prefix "foo"; > > container top { > leaf foo { > type uint8; > } > } > } > > Use "example-" in the module name, as mentioned > inhttps://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-05: > > Example modules are non-normative, and SHOULD be named with the > prefix "example-". > > Same remark for module barmod (and btw, pay attention to the "import > foomod") and module exmod 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. > > > - Editorial (Appendix A): > > OLD: > The "if-mib" feature defined in the "ietf- > interfaces" module is considered to be active. > > NEW: > The "if-mib" feature defined in the "ietf- > interfaces" module is supported. Yes, right. Thanks, Lada > > Regards, Benoit -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
