Murray Kucherawy has entered the following ballot position for draft-ietf-rtgwg-segment-routing-ti-lfa-17: 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/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-rtgwg-segment-routing-ti-lfa/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- John commented on this, but I think it's worth discussing briefly for clarification: There are several unsupported SHOULDs in this document. By "unsupported" I'm referring to the fact that SHOULD presents the implementer with a choice, and it's in our best interests to provide them with enough context to make an informed one. For instance, in Section 6.1: "When a remote node R is in P(S,X) and Q(D,x) and on the post-convergence path, the repair list SHOULD be made of a single node segment to R and the outgoing interface SHOULD be set to the outgoing interface used to reach R." Why is this a SHOULD? Will this still interoperate properly if the implementer doesn't do this? If so, why not use MAY? If not, why not use MUST? Why/when might someone implementing this specification legitimately not do what it says here? I have the same questions about the SHOULDs in 6.2 and 6.3. The one in Section 9 is closer to a more complete presentation. If the reason for doing this is to accommodate extant deployments that don't, I suggest something like "New implementations MUST do X, but for backward compatibility SHOULD continue to support Y which the deployed base uses". I saw some replies to John's comments along the lines of "computation are part of the implementation", but I didn't understand how that answers the question. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for this work. It was an interesting read, which is uncommon for those of us up in Applications space where the air is thin. I have the same question as others about having six authors on this document. I concur in particular with Eric's comments. I have some concerns with the shepherd writeup. Question #11 is incomplete; question #13 has me concerned that the question was not directly asked of the authors. Section 3 defines "SPT_old()" but it doesn't appear anywhere else in this document. Also it seems to me the definitions of "Primary interface" and "Primary link" could be merged, because the former term doesn't appear anywhere in the document other than in the definition of the latter. And a very minor point: We define "adj-sid()", but throughout the document it's variably that or "Adj-Sid()". We should probably pick one and use it consistently. _______________________________________________ rtgwg mailing list -- rtgwg@ietf.org To unsubscribe send an email to rtgwg-le...@ietf.org
