[Pals] Re: Erik Kline's Discuss on draft-ietf-pals-ple-10 : (with DISCUSS and COMMENT)
Erik Kline <[email protected]> Mon, 25 Nov 2024 13:24:41 -0800
| Newsgroups | gmane.ietf.pwe3 |
|---|---|
| Message-ID | <CAMGpriWrBFgbdDLLax+2_xWXtszo5_rpnrTLoOKt5JhjvHCRbA@mail.gmail.com> |
--===============2104448189609137958== Content-Type: multipart/alternative; boundary="000000000000faccf90627c35cf5" --000000000000faccf90627c35cf5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Nov 25, 2024 at 1:55=E2=80=AFAM Christian Schmutzer (cschmutz) < [email protected]> wrote: > Hi Erik, > > Please see my responses inline. Upon your feedback I can upload a new > draft version with the proposed changes incorporated. > > Regards > Christian > > On 24.11.2024, at 00:25, Erik Kline via Datatracker <[email protected]> > wrote: > > Erik Kline has entered the following ballot position for > draft-ietf-pals-ple-10: 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-positio= ns/ > 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-pals-ple/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Internet AD comments for draft-ietf-pals-ple-10 > CC @ekline > > * comment syntax: > - https://github.com/mnot/ietf-comments/blob/main/format.md > > * "Handling Ballot Positions": > - > https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/ > > ## Discuss > > ### S5.1 > > * "The next header field of the SRH MUST be set to TBA1." > > Technically this should only apply when there are no intervening extensi= on > headers between the SRH and the "upper layer header". > > Per RFC 8200 S4.1, there are a fair number of number of extension header= s > that are permitted. > > This document may RECOMMEND that there be no extension headers between > the SRH and the PLE (upper layer) header, but it cannot forbid them (not > without considering updating 8200 and/or 8754). > > > We have followed the wording used in > https://datatracker.ietf.org/doc/html/rfc8986#section-5.3-2 which defines > a similar function (H.Encaps.L2) with the exact same text. > Oh that it is unfortunate, yes. I only handled the appeal for this document; I wasn't on the IESG when it came to telechat and I failed to do a review when it was in IETF LC. I see your point about this being overly restrictive. And thinking about > it, I can see cases where someone may in fact apply security measures > (authentication and encryption) to the PLE VPWS packet stream, which woul= d > lead to potentially AH or ESP being present. > > The goal of the bullet was to say that the last header being processed > should have TBA1. Trying to not overcomplicate the text ... does this sma= ll > change do the trick? > > OLD "The next header field of the SRH MUST be set to TBA1." > > NEW "The next header field of the SRH or last extension header present > MUST be set to TBA1." > This sounds great! ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > # Internet AD comments for draft-ietf-pals-ple-10 > CC @ekline > > * comment syntax: > - https://github.com/mnot/ietf-comments/blob/main/format.md > > * "Handling Ballot Positions": > - > https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/ > > ## Comments > > ### S3.1 > > * "ICMP - Internet Control Message Protocol [RFC792]" > > Since the only use of ICMP in this document is in describing SRv6 Networ= k > Programming SRH processing, the ICMP reference you probably want is > actually ICMPv6, which is RFC 4443. > > > Good point. I will change to RFC4443 > > ### S5.1 > > * "The push of the SRH MAY be omitted when the SRv6 policy only > contains one segment." > > You might append "and no optional TLVs in the SRH are desired, e.g. > HMAC TLV." > > This applies to both bullets with identical text. > > > Indeed. I also checked again with RFC 8986 and realised I have trimmed th= e > comparable sentence > https://datatracker.ietf.org/doc/html/rfc8986#section-5.3-3 too much. > > How about this change which is even more generic and not specific to HMAC > TLV alone? > > OLD "The push of the SRH MAY be omitted when the SRv6 policy only contain= s > one segment." > > NEW "The push of the SRH MAY be omitted when the SRv6 policy only contain= s > one segment and there is no need to use any flag, tag, or TLV." > Perfect, thanks. > ### S5.2.2 > > * "Sequence number ... MUST be ... MAY be ..." > > I'm not sure it's a good use of MUST to say something MUST be 'x' but MA= Y > be 'y'. Can this be reworded into a SHOULD or a "MUST follow one the > following two numbering schemes:"? > > > What about this wording? > > OLD > > The Sequence number in the RTP header MUST be equal to the sequence numbe= r > in the PLE control word. The sequence number of the RTP header MAY be use= d > to extend the sequence number of the PLE control word from 16 to 32 bits. > If so, the initial value of the RTP sequence number MUST be 0 and > incremented whenever the PLE control word sequence number cycles through > from 0xFFFF to 0x0000. > > NEW > > When using a 16 bit sequence number space, the sequence number in the RTP > header MUST be equal to the sequence number in the PLE control word. When > using a sequence number space of 32 bit, the initial value of the RTP > sequence number MUST be 0 and incremented whenever the PLE control word > sequence number cycles through from 0xFFFF to 0x0000. > I think this is much more clear, thank you. I do wonder about how an IW would sync up if it misses some first set of packets, but ... perhaps I'm misunderstanding or that's for another discussion in another context. Thanks again! --000000000000faccf90627c35cf5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">= <div dir=3D"ltr" class=3D"gmail_attr">On Mon, Nov 25, 2024 at 1:55=E2=80=AF= AM Christian Schmutzer (cschmutz) <<a href=3D"mailto:[email protected]"= >[email protected]</a>> wrote:<br></div><blockquote class=3D"gmail_quot= e" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204)= ;padding-left:1ex"> <div> Hi Erik, <div><br> </div> <div>Please see my responses inline. Upon your feedback I can upload a new = draft version with the proposed changes incorporated.</div> <div><br> </div> <div>Regards</div> <div>Christian=C2=A0<br id=3D"m_5157716799769461944lineBreakAtBeginningOfMe= ssage"> <div><br> <blockquote type=3D"cite"> <div>On 24.11.2024, at 00:25, Erik Kline via Datatracker <<a href=3D"mai= lto:[email protected]" target=3D"_blank">[email protected]</a>> wrote:</di= v> <br> <div> <div>Erik Kline has entered the following ballot position for<br> draft-ietf-pals-ple-10: Discuss<br> <br> When responding, please keep the subject line intact and reply to all<br> email addresses included in the To and CC lines. (Feel free to cut this<br> introductory paragraph, however.)<br> <br> <br> Please refer to <a href=3D"https://www.ietf.org/about/groups/iesg/statement= s/handling-ballot-positions/" target=3D"_blank">https://www.ietf.org/about/= groups/iesg/statements/handling-ballot-positions/</a> <br> for more information about how to handle DISCUSS and COMMENT positions.<br> <br> <br> The document, along with other ballot positions, can be found here:<br> <a href=3D"https://datatracker.ietf.org/doc/draft-ietf-pals-ple/" target=3D= "_blank">https://datatracker.ietf.org/doc/draft-ietf-pals-ple/</a><br> <br> <br> <br> ----------------------------------------------------------------------<br> DISCUSS:<br> ----------------------------------------------------------------------<br> <br> Internet AD comments for draft-ietf-pals-ple-10<br> CC @ekline<br> <br> * comment syntax:<br> =C2=A0- <a href=3D"https://github.com/mnot/ietf-comments/blob/main/format.m= d" target=3D"_blank">https://github.com/mnot/ietf-comments/blob/main/format= .md</a><br> <br> * "Handling Ballot Positions":<br> =C2=A0- <a href=3D"https://ietf.org/about/groups/iesg/statements/handling-b= allot-positions/" target=3D"_blank">https://ietf.org/about/groups/iesg/stat= ements/handling-ballot-positions/</a><br> <br> ## Discuss<br> <br> ### S5.1<br> <br> * "The next header field of the SRH MUST be set to TBA1."<br> <br> =C2=A0Technically this should only apply when there are no intervening exte= nsion<br> =C2=A0headers between the SRH and the "upper layer header".<br> <br> =C2=A0Per RFC 8200 S4.1, there are a fair number of number of extension hea= ders<br> =C2=A0that are permitted.<br> <br> =C2=A0This document may RECOMMEND that there be no extension headers betwee= n<br> =C2=A0the SRH and the PLE (upper layer) header, but it cannot forbid them (= not<br> =C2=A0without considering updating 8200 and/or 8754).<br> </div> </div> </blockquote> <div><br> </div> <div> <div>We have followed the wording used in <a href=3D"https://datatracker.ie= tf.org/doc/html/rfc8986#section-5.3-2" target=3D"_blank">https://datatracke= r.ietf.org/doc/html/rfc8986#section-5.3-2</a> which defines a similar funct= ion (H.Encaps.L2) with the exact same text.=C2=A0</div></div></div></div></= div></blockquote><div><br></div><div>Oh that it is unfortunate, yes.=C2=A0 = I only handled the appeal for this document; I wasn't on the IESG when = it came to telechat and I failed to do a review when it was in IETF LC.</di= v><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px = 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><di= v><div><div> <div>I see your point about this being overly restrictive. And thinking abo= ut it, I can see cases where someone may in fact apply security measures (a= uthentication and encryption) to the PLE VPWS packet stream, which would le= ad to potentially AH or ESP being present.</div> <div><br> </div> <div>The goal of the bullet was to say that the last header being processed= should have TBA1. Trying to not overcomplicate the text ... does this smal= l change do the trick?</div> <div><br> </div> <div>OLD "The next header field of the SRH MUST be set to TBA1."<= /div> <div><br> </div> <div>NEW "The next header field of the SRH or last extension header pr= esent MUST be set to TBA1."</div></div></div></div></div></blockquote>= <div><br></div><div>This sounds great!</div><div><br></div><blockquote clas= s=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid r= gb(204,204,204);padding-left:1ex"><div><div><div> <blockquote type=3D"cite"> <div> <div>----------------------------------------------------------------------= <br> COMMENT:<br> ----------------------------------------------------------------------<br> <br> # Internet AD comments for draft-ietf-pals-ple-10<br> CC @ekline<br> <br> * comment syntax:<br> =C2=A0- <a href=3D"https://github.com/mnot/ietf-comments/blob/main/format.m= d" target=3D"_blank">https://github.com/mnot/ietf-comments/blob/main/format= .md</a><br> <br> * "Handling Ballot Positions":<br> =C2=A0- <a href=3D"https://ietf.org/about/groups/iesg/statements/handling-b= allot-positions/" target=3D"_blank">https://ietf.org/about/groups/iesg/stat= ements/handling-ballot-positions/</a><br> <br> ## Comments<br> <br> ### S3.1<br> <br> * "ICMP - Internet Control Message Protocol [RFC792]"<br> <br> =C2=A0Since the only use of ICMP in this document is in describing SRv6 Net= work<br> =C2=A0Programming SRH processing, the ICMP reference you probably want is<b= r> =C2=A0actually ICMPv6, which is RFC 4443.<br> </div> </div> </blockquote> <div><br> </div> <div>Good point. I will change to RFC4443</div> <br> <blockquote type=3D"cite"> <div> <div>### S5.1<br> <br> * "The push of the SRH MAY be omitted when the SRv6 policy only<br> =C2=A0=C2=A0contains one segment."<br> <br> =C2=A0You might append "and no optional TLVs in the SRH are desired, e= .g.<br> =C2=A0HMAC TLV."<br> <br> =C2=A0This applies to both bullets with identical text.<br> </div> </div> </blockquote> <div><br> </div> <div>Indeed. I also checked again with=C2=A0RFC 8986 and realised I have tr= immed the comparable sentence <a href=3D"https://datatracker.ietf.org/doc/html/rfc8986#section-5.3-3" tar= get=3D"_blank">https://datatracker.ietf.org/doc/html/rfc8986#section-5.3-3<= /a>=C2=A0too much.=C2=A0</div> <div><br> </div> <div>How about this change which is even more generic and not specific to H= MAC TLV alone?</div> <div><br> </div> <div> <div>OLD "The push of the SRH MAY be omitted when the SRv6 policy only= contains one segment."</div> <div><br> </div> <div>NEW "The push of the SRH MAY be omitted when the SRv6 policy only= contains one segment and there is no need to use any flag, tag, or TLV.&qu= ot;</div></div></div></div></div></blockquote><div><br></div><div>Perfect, = thanks.</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px = 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><d= iv> <blockquote type=3D"cite"> <div> <div>### S5.2.2<br> <br> * "Sequence number ... MUST be ... MAY be ..."<br> <br> =C2=A0I'm not sure it's a good use of MUST to say something MUST be= 'x' but MAY<br> =C2=A0be 'y'. Can this be reworded into a SHOULD or a "MUST fo= llow one the<br> =C2=A0following two numbering schemes:"?<br> </div> </div> </blockquote> <div><br> </div> <div>What about this wording?</div> <div><br> </div> <div>OLD</div> <div><br> </div> <div>The Sequence number in the RTP header MUST be equal to the sequence nu= mber in the PLE control word. The sequence number of the RTP header MAY be = used to extend the sequence number of the PLE control word from 16 to 32 bi= ts. If so, the initial value of the RTP sequence number MUST be 0 and incremented whenever the PLE control= word sequence number cycles through from 0xFFFF to 0x0000.</div> <div><br> </div> </div> <div>NEW</div> <div><br> </div> <div>When using a 16 bit sequence number space, the sequence number in the = RTP header MUST be equal to the sequence number in the PLE control word. Wh= en using a sequence number space of 32 bit, the initial value of the RTP se= quence number MUST be 0 and incremented whenever the PLE control word sequence number cycles through from 0xFFFF t= o 0x0000.</div></div></div></blockquote><div><br></div><div>I think this is= much more clear, thank you.</div><div><br></div><div>I do wonder about how= an IW would sync up if it misses some first set of packets, but ... perhap= s I'm misunderstanding or that's for another discussion in another = context.</div><div><br></div><div>Thanks again!</div></div></div> --000000000000faccf90627c35cf5-- --===============2104448189609137958== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KUGFscyBtYWls aW5nIGxpc3QgLS0gcGFsc0BpZXRmLm9yZwpUbyB1bnN1YnNjcmliZSBzZW5kIGFuIGVtYWlsIHRv IHBhbHMtbGVhdmVAaWV0Zi5vcmcK --===============2104448189609137958==--