Ladislav Lhotka <[email protected]> writes:
> Juergen Schoenwaelder <[email protected]> writes:
>
>> 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.
>
> Yes, and the "modifier" statement should also be listed in Table 1 of
> sec. 13.1.
I just noticed this table contains a copy-and-paste error:
+------------------+---------------+-------------+
| keyword | argument name | yin-element |
+------------------+---------------+-------------+
| action | name | false |
| anydata | 7.10 | 0..n |
^^^^ ^^^^
Lada
>
> Lada
>
>>
>> /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
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
> _______________________________________________
> netmod mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/netmod
--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
