Juergen Schoenwaelder <j.schoenwael...@jacobs-university.de> 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. 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 > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
