Alvaro Retana has entered the following ballot position for draft-ietf-trill-centralized-replication-11: No Objection
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-centralized-replication/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I have some non-blocking comments. I would like to see the ones related to Normative Language addressed before publication. - From the Abstract: "RPF checks on each RBridge MUST be calculated as if the centralized node was the ingress RBridge..." Using Normative Language in the Abstract seems strange to me, specially since the same language is not used later in the text. The document does get to the same point later, but not with the same language. - The Introduction says that "...a centralized node, which SHOULD be a distribution tree root", but Section 3 says otherwise: "The centralized node MUST be a distribution tree root." Suggestion: use Normative Language in just one place. IMO, the Introduction may not be the right place for it. - BTW, what is a "distribution tree root"? The definition is probably intuitive since we're talking about replication, but explicitly defining it would clear any possible confusion. - I appreciate the background and the description of the problem and the mechanism, but there's a lot of repetition. Section 3 presents for the third time an overview of the mechanism -- Abstract, Introduction, and Section 3...note that even the last paragraph repeats information about the replication from this same section. - Section 9: "An edge group using CMT [RFC7783] MUST NOT set the C-nickname flag on the pseudo-nickname it is using. This is already mandatory behavior..." If "already mandatory" then there's no need to use Normative Language here, right? - Section 11.1 ("R" and "C" Flag in the Nickname Flags APPsub-TLV): I'm not sure if I understand correctly, but because there's a distinction between the R-nickname and the C-nickname, both bits should not be set at the same time, right? What happens if they are? It seems that the last paragraph tries to address that question ("due to errors")...but I'm then not sure what the action is: "it is RECOMMENDED that the nickname be treated as if the R / C flag was set if any Nickname Flags APPsub-TLV for that nickname has the R / C flag set." Again, what if both are set? And "RECOMMENDED" implies that there are reasons not to do it this way...what are those cases? _______________________________________________ trill mailing list trill@ietf.org https://www.ietf.org/mailman/listinfo/trill