My take on this is that it is fine to show text from RFC8200 without any change (with a reference), but it is not good to try to summarize that text (for example, as in “We assume….”).
Thanks, Bob > On Nov 23, 2019, at 4:28 PM, Ron Bonica <[email protected]> wrote: > > Pablo, > > During the SPRING WG meeting at IETF 106, we discussed the following text > from Section 2 of draft-ietf-spring-srv6-network-programming-05: > > “SRH: Segment Routing Header as defined in > [I-D.ietf-6man-segment-routing-header]. We assume that the SRH may be > present multiple times inside each packet.” > > This text contradicts the following text from RFC 8200: > > “Each extension header should occur at most once, except for the Destination > Options header, which should occur at most twice (once before a Routing > header and once before the upper-layer header).” > > The following redaction reconciles the contradiction by remaining silent and > allowing RFC 8200 to speak for itself: > > OLD> > SRH: Segment Routing Header as defined in > [I-D.ietf-6man-segment-routing-header]. We assume that the SRH may be > present multiple times inside each packet > <OLD > > NEW> > SRH: Segment Routing Header as defined in > [I-D.ietf-6man-segment-routing-header]. > <NEW > > During the meeting, you mentioned the need to import some text from RFC 8200. > If you feel the need to do that, the follow redaction imports all relevant > text without bias: > > OLD> > SRH: Segment Routing Header as defined in > [I-D.ietf-6man-segment-routing-header]. We assume that the SRH may be > present multiple times inside each packet. > <OLD > > NEW> > SRH: Segment Routing Header as defined in > [I-D.ietf-6man-segment-routing-header]. > > As per Section 4.1 of RFC 8200, the Routing header (e.g., SRH) should occur > at most one inside a packet. However, IPv6 nodes must accept and attempt to > process extension headers in any order and occurring any number of times in > the same packet, except for the Hop-by-Hop Options header, which is > restricted to appear immediately after an IPv6 header only. > > Nonetheless, it is strongly advised that sources of IPv6 packets adhere to > the recommendations found in Section 4.1 of RFC 8200 until and unless > subsequent specifications revise those recommendation. > <NEW > > > Happy Holidays, > > Ron > > > Juniper Business Use Only
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
