Alvaro Retana has entered the following ballot position for draft-ietf-trill-channel-tunnel-10: 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-trill-channel-tunnel/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Even though the IANA Considerations section was just updated (in version -10), I am putting in this DISCUSS because it is still incomplete/incorrect. 1. Guidance for managing the SubERR namespace should be included. Note that this document only specifies values for ERR 6, but guidance should be given to IANA for the other ERR values as well. 2. Section 6.2.1 (RBridge Channel Error Codes Subregistry) requests the creation of a new registry ("RBridge Channel Error Codes”), but that registry was already created by RFC7178. This document should then split the requests in two parts: assignment of the vales 6-8, and the change to the registration procedure. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- >From Section 2. (RBridge Channel Header Extension Format), is the RESV4 field a space that is reserved for potential future use? Why isn’t it ignored on receipt (similar to the RESV field in Section 4.3)? If there is potential for use of this space (RESV is defined as 4 bits, which makes me think about potential bit-level allocations), then there should be some guidance in the IANA Considerations. _______________________________________________ trill mailing list [email protected] https://www.ietf.org/mailman/listinfo/trill
