Barry, Many thanks for the confirmation of those three points. We have posted an updated version of the I-D with all the changes discussed below.
Regards, Pablo. There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-20 https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-network-programming-20 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-srv6-network-programming-20 -----Original Message----- From: Barry Leiba <[email protected]> Sent: martes, 22 de septiembre de 2020 23:05 To: Pablo Camarillo (pcamaril) <[email protected]> Cc: The IESG <[email protected]>; [email protected]; [email protected]; [email protected]; Bruno Decraene <[email protected]>; Joel Halpern <[email protected]> Subject: Re: Barry Leiba's No Objection on draft-ietf-spring-srv6-network-programming-19: (with COMMENT) 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
