Subject: [netmod] review of draft-ietf-netmod-rfc6020bis-07 (section 9. built-in types)

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 13 Oct 2015 10:02:54 +0200

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/>

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 15 Oct 2015 08:04:28 +0200

> 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

> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 15 Oct 2015 23:01:41 +0200 (CEST)

> bug I spotted is likely that section 9.4.6 is empty.

Ha!  It seems to have been empty since -01...

>      do not have a canonical form.

Fixed.

>     evaluations are done using the canonical form.

Fixed.

>   s/XML instance documents/XML encoding/

Fixed.

>   s/XML instance documents/XML encoding/

Fixed.

>   The section 9.4.6 (modifier statement) is empty and needs to be

Fixed.

>   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.

?

>   s/A binary can/A binary type can/

Fixed.

>   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.

>   s/is encoded/is encoded in XML/

s/is encoded/is lexically represented/ ?

>   s/is encoded/is encoded in XML/

s/is encoded/is lexically represented/ ?

>      In the XML encoding, the value representing a union data type...

I added this last sentence.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 16 Oct 2015 16:00:34 +0200

> Yes, and the "modifier" statement should also be listed in Table 1 of

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

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 16 Oct 2015 23:19:09 +0200 (CEST)

> I just noticed this table contains a copy-and-paste error:

fixed!

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 18 Oct 2015 10:51:14 +0200

>      values for the existing enums, unless they have explicit values

OK

> since it is not just XML, but also defaults and the canonical form.

But if you think about something like CBOR, would you still base64
encode the binary value? I do not think so. Within the YANG context,
we represent binary values as base64 encoded strings but on the wire
we might do something more efficient in a binary encoding.

/js