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.
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..."?
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.
Fair enough.
-
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?
Ok, let's fix it in 6020bis then.
-
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.
So please fix the text in 6087bis.
Until it's done, I'll stick to the current rule.
Regards, Benoit
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
