Reviewer: Dan Romascanu Review result: Ready with Issues I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-trill-multilevel-single-nickname-09 Reviewer: Dan Romascanu Review Date: 2020-05-20 IETF LC End Date: 2020-06-11 IESG Telechat date: Not scheduled for a telechat Summary: This is not easy reading for non-TRILL experts, but I can guess that this document is useful and clear enough for the people working in the field. The document is READY but there are a few issues that seem to be in need of being clarified and addressed if necessary. Major issues: 1. Something is not clear to me about the Intended Status of this document. It is supposed to solve a problem introduced or left unclear by RFC 8243, but that document is Informational. Why is then the Intended Status Standards Track? Minor issues: 1. All the examples in the text are static. Changes however happen in the configuration of the network. What happens when an Rbridge is added at the border of an L1 area? 2. Section 6 'RB1 SHOULD use a single area nickname for all these areas.' - why is this only a SHOULD? It seems to me that in any exception case the scheme breaks 3. I am used with documents in the routing area to include Operational and Manageability considerations. These are missing here, with the exception of backwards compatibility which is addressed. Are any configuration operations necessary for example? If these are addressed in other documents a reference would be useful. Nits/editorial comments: 1. Need to correct grammar/syntax problems 2. Inconsistent writing Level 1 / Level-1 ; Level 2 / Level-2 3. Section 1: s/nicknames in L2 MUST be unique/nicknames in L2 areas MUST be unique/ 4. It would be useful to add Level to the terminology 5. Section 3.1: s/D's location is learned by the relevant TRILL switches already/D's location has been learned by the relevant TRILL switches already/ 6. Section 3.2: s/ESADI protocol/ESADI protocol [RFC7357]/ -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
