Juergen Schoenwaelder <[email protected]> wrote:
> 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.
Ha! It seems to have been empty since -01...
> /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.
Fixed.
> 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.
Fixed.
> * p127
>
> s/XML instance documents/XML encoding/
Fixed.
> * p131
>
> s/XML instance documents/XML encoding/
Fixed.
> * p132
>
> The section 9.4.6 (modifier statement) is empty and needs to be
> filled in.
Fixed.
> * 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.
Neither did I :(
I think it is best to add this warning to section 10:
OLD:
o An "enumeration" type may have new enums added, provided the old
enums's values do not change.
NEW:
o An "enumeration" type may have new enums added, provided the old
enums's values do not change. Note that inserting a new enum before
an existing enum or reordering existing enums will result in new
values for the existing enums, unless they have explicit values
assigned to them.
?
> * p139
>
> s/A binary can/A binary type can/
Fixed.
> * p139
>
> s/are encoded/are encoded in XML/
How about s/are encoded/are lexically represented/
since it is not just XML, but also defaults and the canonical form.
> * p141
>
> s/is encoded/is encoded in XML/
s/is encoded/is lexically represented/ ?
> * p146
>
> s/is encoded/is encoded in XML/
s/is encoded/is lexically represented/ ?
> * 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...
I added this last sentence.
/martin
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
