[Pals] Re: Erik Kline's Discuss on draft-ietf-pals-ple-10 : (with DISCUSS and COMMENT)
"Christian Schmutzer \(cschmutz\)" <[email protected]> Mon, 25 Nov 2024 09:55:29 +0000
| Newsgroups | gmane.ietf.pwe3 |
|---|---|
| Message-ID | <[email protected]> |
--===============0937879625155621194== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_9AD865BB4B1F4E258C3CDC777F26043Cciscocom_" --_000_9AD865BB4B1F4E258C3CDC777F26043Cciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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]> wrot= e: 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-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-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 extension headers between the SRH and the "upper layer header". Per RFC 8200 S4.1, there are a fair number of number of extension headers 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 t= he exact same text. 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 (authen= tication and encryption) to the PLE VPWS packet stream, which would lead to= potentially AH or ESP being present. The goal of the bullet was to say that the last header being processed shou= ld have TBA1. Trying to not overcomplicate the text ... does this small cha= nge 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." ---------------------------------------------------------------------- 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 Network 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 the = 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 T= LV alone? OLD "The push of the SRH MAY be omitted when the SRv6 policy only contains = one segment." 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." ### 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 MAY 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 number = 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 bits. I= f so, the initial value of the RTP sequence number MUST be 0 and incremente= d 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 h= eader MUST be equal to the sequence number in the PLE control word. When us= ing a sequence number space of 32 bit, the initial value of the RTP sequenc= e number MUST be 0 and incremented whenever the PLE control word sequence n= umber cycles through from 0xFFFF to 0x0000. --_000_9AD865BB4B1F4E258C3CDC777F26043Cciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <[email protected]> Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > </head> <body style=3D"overflow-wrap: break-word; -webkit-nbsp-mode: space; line-br= eak: after-white-space;"> 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 <br id=3D"lineBreakAtBeginningOfMessage"> <div><br> <blockquote type=3D"cite"> <div>On 24.11.2024, at 00:25, Erik Kline via Datatracker <[email protected]= rg> wrote:</div> <br class=3D"Apple-interchange-newline"> <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 https://www.ietf.org/about/groups/iesg/statements/handling-= ballot-positions/ <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> https://datatracker.ietf.org/doc/draft-ietf-pals-ple/<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> - https://github.com/mnot/ietf-comments/blob/main/format.md<br> <br> * "Handling Ballot Positions":<br> - https://ietf.org/about/groups/iesg/statements/handling-ballot-posit= ions/<br> <br> ## Discuss<br> <br> ### S5.1<br> <br> * "The next header field of the SRH MUST be set to TBA1."<br> <br> Technically this should only apply when there are no intervening exte= nsion<br> headers between the SRH and the "upper layer header".<br> <br> Per RFC 8200 S4.1, there are a fair number of number of extension hea= ders<br> that are permitted.<br> <br> This document may RECOMMEND that there be no extension headers betwee= n<br> the SRH and the PLE (upper layer) header, but it cannot forbid them (= not<br> without considering updating 8200 and/or 8754).<br> </div> </div> </blockquote> <div><br> </div> <div> <div>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) w= ith the exact same text. </div> <div><br> </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><br> </div> </div> <br> <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> - https://github.com/mnot/ietf-comments/blob/main/format.md<br> <br> * "Handling Ballot Positions":<br> - https://ietf.org/about/groups/iesg/statements/handling-ballot-posit= ions/<br> <br> ## Comments<br> <br> ### S3.1<br> <br> * "ICMP - Internet Control Message Protocol [RFC792]"<br> <br> Since the only use of ICMP in this document is in describing SRv6 Net= work<br> Programming SRH processing, the ICMP reference you probably want is<b= r> actually 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> contains one segment."<br> <br> You might append "and no optional TLVs in the SRH are desired, e= .g.<br> HMAC TLV."<br> <br> This applies to both bullets with identical text.<br> </div> </div> </blockquote> <div><br> </div> <div>Indeed. I also checked again with RFC 8986 and realised I have tr= immed the comparable sentence <a href=3D"https://datatracker.ietf.org/doc/html/rfc8986#section-5.3-3">htt= ps://datatracker.ietf.org/doc/html/rfc8986#section-5.3-3</a> too much.= </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><br> </div> <blockquote type=3D"cite"> <div> <div>### S5.2.2<br> <br> * "Sequence number ... MUST be ... MAY be ..."<br> <br> I'm not sure it's a good use of MUST to say something MUST be 'x' but= MAY<br> be 'y'. Can this be reworded into a SHOULD or a "MUST follow one= the<br> following 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><br> </div> <br> </div> </body> </html> --_000_9AD865BB4B1F4E258C3CDC777F26043Cciscocom_-- --===============0937879625155621194== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KUGFscyBtYWls aW5nIGxpc3QgLS0gcGFsc0BpZXRmLm9yZwpUbyB1bnN1YnNjcmliZSBzZW5kIGFuIGVtYWlsIHRv IHBhbHMtbGVhdmVAaWV0Zi5vcmcK --===============0937879625155621194==--