Hi,
here is the review of section 9 or draft-ietf-netmod-rfc6020bis-07; I
have finish now a complete review of the document. The most important
bug I spotted is likely that section 9.4.6 is empty.
/js
* p126
OLD
Some types have a lexical representation that depends on the XML
context in which they occur. These types do not have a canonical
form.
NEW
Some types have a lexical representation that depends on the
encoding, e.g., the XML context in which they occur. These types
do not have a canonical form.
Well, it turns out that there are XML encoding specifics in several
of the following sections. Perhaps instead stated upfront that the
section 9 describes the types and they XML encoding and noting that
other encodings may use different rules. Perhaps also stating that
the canonical representation is also used for constraint evaluation
purposes.
OLD
When a NETCONF server sends data, it MUST be in the canonical form.
NEW
When a server sends data encoded in XML, it MUST use the canonical
form defined in this section. Other encodings may introduce
alternate representations. Note, however, that values in the data
tree are conceptually stored in the canonical representation as
defined in this section. In particular, any XPath expression
evaluations are done using the canonical form.
* p127
s/XML instance documents/XML encoding/
* p131
s/XML instance documents/XML encoding/
* p132
The section 9.4.6 (modifier statement) is empty and needs to be
filled in.
* p137
Y25-02 says:
Keep the auto-numbering procedure for enums and bits and add an
explicit warning that inserting enum or bits definitions or
reordering enum or bits definitions violates section 10 and causes
interoperability problems unless explicit value assignments are
used.
Has this been implemented? I did not find such a statement.
* p139
s/A binary can/A binary type can/
* p139
s/are encoded/are encoded in XML/
* p141
s/is encoded/is encoded in XML/
* p146
s/is encoded/is encoded in XML/
* p148
The text stating that a value is consecutively against each member
type does not seem to be 100% true for the JSON mapping since JSON
says the JSON type information is taken into account. So we either
change the JSON specification or we rewrite this text in RFC 6020 to
allow different member type selection styles by making this
statement specific to the XML encoding:
In the XML encoding, the value representing a union data type...
/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
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
