Thanks for the reply, Pablo (and thanks also to Joel for his reply). All good here. And just confirming three items in particular:
>> It should be “an SID”, “an FIB”, “an RIR”, and some others, not “a”, because >> one reads these as >> “ess-eye-dee” and “eff-eye-bee”, not as the expansions thereof. > > [PC] Agreed for RIR. For the other ones I’ve seen some disagreement on this > regard in between > native English speakers. I’m not a native English speaker, hence I would > prefer to leave the decision > up to RFC Editor. As Joel said also, and I agree. >> I can’t figure this out. It looks like it should be “required to >> terminate”, but I don’t know what it means > to “terminate less bytes”. Can you reword this? > > [PC] I propose the following diff: > <OLD> > as part of the decapsulation process the egress PE is required to terminates > less bytes from the packet. > </OLD> > <NEW> > as part of the decapsulation process the egress PE is required to parse and > remove fewer bytes from the packet. > </NEW> A very fine change; thanks. >> This document introduces SRv6 Endpoint and SR Policy Headend >> behaviors for implementation on SRv6 capable nodes in the network. >> As such, this document does not introduce any new security >> considerations. >> >> I’m not convinced of this. It seems that misuse (such as injection or >> alteration) of some of these Behaviors could, >> for example, result in packets being forwarded to nodes they were not >> intended to go to. Is it not important to >> discuss issues such as that: how these Behaviors might be attacked? Is that >> really fully covered in 8754 and 8402? > > [PC] You mention injection alteration or misuse of these behaviors, the > paragraph preceding the one you quote > in revision 19 states: > “Additionally, [RFC8754] defines an HMAC TLV permitting SR > Endpoint Nodes in the SR domain to verify that the SRH applied to a > packet was selected by an authorized party and to ensure that the > segment list is not modified after generation, regardless of the > number of segments in the segment list.” > > This text was added to revision 19 as part of the SECDIR review, and I think > this provides a reminder of how misuse > or alteration within the SR domain of trust can be handled based on RFC8754. > Can you please check if this addresses > your comment? It does, and thanks for pointing it out. I think I must have had that comment left over from an earlier start on reviewing, and hadn't double-checked it with the latest version. Barry _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
