Suresh Krishnan has entered the following ballot position for draft-ietf-lisp-lcaf-16: Discuss
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lisp-lcaf/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- The way that the length field is specified in this document is inconsistent, extremely confusing and sometimes wrong. e.g. In Section ASCII Names in the Mapping Database Length value n: length in bytes AFI=17 field and the null-terminated ASCII string (the last byte of 0 is included). but the field mentions 2+n. Only one of these can be correct Similarly in Section 4.9. Replication List Entries for Multicast Forwarding Length value n: length in bytes of fields that follow. but the field mentions 4+n. Again one of these can be correct. Similar error in Section 5.2 (Generic Database Mapping Lookups) * Section 4.10.4. Using Recursive LISP Canonical Address Encodings The "IP TOS, IPv6 QQS or Flow Label" field is underspecified and cannot be implemented in an interoperable manner. There are multiple ways to encode the 8 bit values (the IP TOS and the IPv6 Traffic Class) into the 24 bit field. Similarly, there are at least two obvious ways to encode the 20 bit flow label into this field. Also the "IPv6 QoS" needs to be renamed to "IPv6 Traffic Class" ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- * Can you please clarify why Rsvd2 is reserved for future use but this document already ends up specifying it under "Segmentation" * I think the reference for AFI is not correct. Shouldn't it be http://www.iana.org/assignments/address-family-numbers/address-family-numbers.xhtml? The current reference leads to a generic IANA page. * Section 4.8: Is the explanation for the AFI correct? The source dest lookups don't seem to be multicast addresses. "When a specific AFI has its own encoding of a multicast address, this field must be either a group address or a broadcast address." _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
