On Thu, Oct 15, 2015 at 11:01:41PM +0200, Martin Bjorklund wrote: > > * 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.
OK > > * 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. 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 -- 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
