John Scudder has entered the following ballot position for draft-ietf-spring-segment-routing-policy-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/blog/handling-iesg-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-spring-segment-routing-policy/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I’ve done an initial review of this document and have several concerns I’d like to discuss. I apologize for not also providing a full review as comments in this ballot, I judged it more important to begin the discussion about these points timely, than to provide all comments in a single message. 1. The shepherd writeup indicates that “Standard Track is requested and indicated in the title page header. This is appropriate for a specification of packet steering into an SR policy needing interoperability between the ingress/source of the policy instantiation and the egress/destination of the policy termination.” I realize it’s unusual to ask to discuss a shepherd writeup rather than the spec itself, but I think this one rises to the level. My concern is that this description (needing interoperability between the ingress and the egress) doesn’t comport with my understanding of the Segment Routing architecture. Surely, one of the key value propositions of SR is that it’s stateless everywhere other than the headend? Indeed, that’s stated in the abstract. SR doesn’t require the egress to even understand that it IS an egress of a SR Policy, it just does what the headers tell it to, right? If that's so, then the rationale given for the requested track must be wrong. :-( And that in turn leads me to ask, whether the track really is right. It seems to me that in most respects this is more an Informational document than a standards track one. That’s not a value judgement in any respect, just a statement of fact — for the most part, it doesn’t seem as though the information found in this document is needed in order to interoperate with another system. (Section 8.8 is an exception, I discuss that separately.) Anyway, not to get too far ahead of myself, let’s start by working on this question: is the shepherd writeup correct in saying that interoperability between headend and tailend is required? If so, can someone please characterize the nature of that interoperability, and put it in the context of SR’s stateless nature? 2. It seems to me an unusual practice for this document to be defining semantics and even reserving values in a field allocated by a different document, by a different WG. I’m referring here to the so-called “‘Color-Only’ bits” discussed in Section 8.8. - I would be more comfortable if the work were all done in one place, to the extent possible. - Given the fact this document is reaching in to a registry normally managed by IDR, was there any discussion with the IDR group? I don't see any evidence of a courtesy notification of the last call when I look at the IDR mailing list archive. I’ve also emailed the IDR list about this in connection with draft-ietf-idr-segment-routing-te-policy, see https://mailarchive.ietf.org/arch/msg/idr/yCcZdStmTR-FLUYGHTsLLBv5aWo/ Relating this back to my previous question, it’s evident that if this document is going to define semantics for the Color Extended Community Flags, then that makes it Standards Track because there is an interoperability factor to take into account (that's been imported from IDR). A more ideal solution would be to take care of that in the IDR document rather than putting it in this “architecture” document, though. Surely, this kind of detail is implementation, not architecture? Indeed, Ketan said in his reply to Matthew Bocci's RTG review, "Given that this is an architecture document, it describes the architecture and not really the protocol mechanisms"... but this section seems to be an exception to that aspiration. 3. Related to the above, at least one of the references listed as informational clearly has to be normative with the document as it stands. draft-ietf-idr-segment-routing-te-policy is the one I’m thinking of, for example its use in §2.4 seems like it may rise to the "normative" level, §2.5 almost surely does, §4.1 surely does, and §8.8.1 is the icing on the cake because this document defines semantics for a field that isn’t even allocated until and unless draft-ietf-idr-segment-routing-te-policy is published. 4. In §2.1 you talk about the signaling of symbolic names for candidate paths. Although you are careful to say that such symbolic names are only used for presentation purposes, it seems to me they still could be considered a new potential source of vulnerability, since a string that has no sanity-checking whatsoever applied by the protocol can display literally anything to an operator viewing it. Shouldn’t this be addressed in your Security Considerations? (For an example of a related Security Considerations, see RFC 9003. It’s probably not the best example, but it’s the one I had at my fingertips…) ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- As noted in my DISCUSS, these comments are unfinished but I thought I’d give you what I have. 1. I see that Cullen Jennings referred to this in his ART review, but I’d like to talk about it a little more: why have you chosen to restrict symbolic names to ASCII? UTF-8 is the more usual choice in this context; indeed implementations may have to go to extra effort to scrub their input to insure that only ASCII is present. BCP 18 doesn’t require you to internationalize your strings, of course, it gives you two options, of which you have (sort of, you don't have the "US-") followed the latter: This document does not mandate a policy on name internationalization, but requires that all protocols describe whether names are internationalized or US-ASCII. But in 2022 the choice to restrict symbolic names to ASCII seems unusual enough to invite the question. If you do stick with ASCII as currently written, might you add text mandating that implementations scrub their input to prevent non-ASCII characters from being accepted? _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
