I agree with Yingzhen on both counts - that the compressed SID enhancements should not be documented in an Errata and that the augmentations to the IS-IS and OSPFv3 encodings can be documented in the 6MAN document including the compressed SID semantics that LSR reviews.
Thanks, Acee > On Dec 4, 2025, at 1:25 PM, Yingzhen Qu <[email protected]> wrote: > > I don't think this should be filed as an errata. The document was correct > when published. People implementing RFC 9352 understand that "number of SIDs" > means "number of 128 bits" and would not confuse it with the number of SIDs > that include compressed SIDs. > > I prefer Adrian's suggestion, clarifying this in > draft-ietf-6man-sidlist-clarification. Otherwise we should handle this in a > -bis document. > > Thanks, > Yingzhen > > On Thu, Dec 4, 2025 at 1:54 AM Gunter van de Velde (Nokia) > <[email protected]> wrote: > Apologies for the late response. The note got filtered into a an unsuspected > folder. > > There is an IESG statement about processing errata: > https://datatracker.ietf.org/doc/statement-iesg-iesg-processing-of-rfc-errata-for-the-ietf-stream-20210507/ > > This statement advises that the rules are strong guidelines, not immutable > rules. > > The first rule says: > " > • Errata are items that were errors at the time the document was > published -- things that were missed during the last call, approval, and > publication process. If new information, new capabilities, or new thinking > has come up since publication, or if you disagree with the content of the > RFC, that is not material for an errata report. Such items are better brought > to relevant working groups, technical area discussions, or the IESG. > " > > Looking at this rule, it appears that the observation (SID not always 128 > bits after RFC 9800) is not really an errata, but rather a consequence of the > updated SID size flexibility introduced by RFC 9800. > > The errata rule is not immutable, and the changes required to correct rfc9352 > are obvious. Hence, if the WG agrees to resolve this via an errata, I’ll > process it as a technical erratum. If not, it should be handled in a -bis > document. Let’s make sure the WG have clear consensus on the list first. > > G/ > > > From: Joel Halpern <[email protected]> > Sent: Tuesday, December 02, 2025 11:05 PM > To: Gunter van de Velde (Nokia) <[email protected]> > Cc: Adrian Farrel <[email protected]>; lsr <[email protected]>; Tony Li > <[email protected]>; Ketan Talaulikar <[email protected]>; James Guichard > <[email protected]> > Subject: Re: [Lsr] Re: Where to clarify RFC 9352 relative to SID containers > > CAUTION: This is an external email. Please be very careful when clicking > links or opening attachments. See the URL nok.it/ext for additional > information. > > As far as I can tell, Gunther is the responsible AD. As such, Gunther, do > you agree that this should be handled as a pair of errata? And if so, do you > want me to file them? > Yours, > Joel > On 12/2/2025 9:09 AM, Joel Halpern wrote: > Those changes are the clarification I am asking for. > Yours, > Joel > On 12/2/2025 6:51 AM, Ketan Talaulikar wrote: > < only as co-author of RFC9513 and contributor to RFC9352 > > > Hi All, > > I believe a technical errata on these documents is appropriate and a bis is > not necessary. > > As Adrian notes, "number of SIDs in SRH" and "number of segments in SRH" were > used interchangeably in some places in documents that were published before > CSID RFC9800. I see a technical error with this mix up in the MSD context > since RFC8754 that specified the SRH talks about Segments in the SRH and > Segment List in the SRH. > > Now, the MSD types in question are all referring to SRH (refer > https://www.rfc-editor.org/rfc/rfc9352.html#section-4 and > https://www.rfc-editor.org/rfc/rfc9513.html#section-4) and so the errata > would be something like below: > - Maximum Segments Left MSD Type (no errata needed) > - Maximum End Pop MSD Type : s/number of SIDs in the SRH/number of Segments > in the SRH > - Maximum H.Encaps MSD Type: s/number of SIDs that can be added to the > segment list of an SRH/number of Segments that can be added to the segment > list of an SRH .... and also s/SRH up to the advertised number of SIDs/SRH up > to the advertised number of Segments > - Maximum End D MSD Type: s/number of SIDs present in an SRH/number of > Segments present in an SRH > > The actual "update" and clarifications to "Segments Left" and "Segment List" > are already being done in draft-ietf-6man-sidlist-clarification and applied > to RFC8754 which is the base that these OSPF and ISIS specs are referencing. > Therefore, I don't see the need for a bis for the LSR specs. > > Joel, have I understood your point correctly? > > Just my view ... > > Thanks, > Ketan > > > On Mon, Dec 1, 2025 at 12:29 PM Tony Li <[email protected]> wrote: > > Hi all, > > IMHO, this is not an appropriate use of the Errata mechanism. The intent of > that mechanism is to report technical and editorial errors in the document. > > In this case, we’re talking about extending the text (albeit in an obvious > way) to cover the case of a compressed segment list. This deserves to be in > a separate document and have WG scrutiny. It would not be inappropriate to > consider a 9352bis. > > Regards, > T > > > On Nov 30, 2025, at 7:11 PM, Zafar Ali (zali) - zali=40cisco.com at > dmarc.ietf.org <[email protected]> wrote: > > Hi Adrian, Joel, WG, > > I agree with Adrain, "that in 9352, MSD should be interpreted to mean the > maximum number of 128-bit entries in the Segment list, and not the number of > SIDs represented". Depending on AD/ chairs preference, a clarification along > these lines can be made in draft-ietf-6man-sidlist-clarification or as an > RFC9352 Errata. > > Thanks > > Regards … Zafar > > > On 11/30/25, 5:54 AM, "Adrian Farrel" <[email protected] > <mailto:[email protected]>> wrote: > > > Hi, > > > Coming to this thread late a wilfully jumping in half way through. > > > Can I point you to draft-ietf-6man-sidlist-clarification? > > > The problem identified there is that there was originally some "wooliness" > with regard to terminology in 8754. > - Both "SID list" and "Segment list" are used. > - There is an implication (which, certainly, no longer applies) that entries > in the Segment list are 128 bit IPv6 addresses. > This is no attack on the authors (we were all in the room when the text was > agreed) and the clarification doesn't change the technology one iota. > > > I think that 9352 carried on this slight fuzziness. Again, no attack on the > authors or the technology - we all reviewed the text. > I would agree that in 9352, MSD should be interpreted to mean the maximum > number of 128-bit entries in the Segment list, and not the number of SIDs > represented. > > > Cheers, > Adrian > > > > Cisco Confidential > -----Original Message----- > From: Vasilenko Eduard <[email protected] > <mailto:[email protected]>> > Sent: 27 November 2025 11:08 > To: LUIS MIGUEL CONTRERAS MURILLO <[email protected] > <mailto:[email protected]>>; Joel Halpern > <[email protected] <mailto:[email protected]>>; lsr <[email protected] > <mailto:[email protected]>> > Cc: Giuseppe Fioccola <[email protected] > <mailto:[email protected]>>; Paolo Volpato > <[email protected]<mailto:[email protected]>>; Bruno Decraene > <[email protected] <mailto:[email protected]>> > Subject: [Lsr] Re: Where to clarify RFC 9352 relative to SID containers > > > Hi all, > Pay attention that RFC 9532 is the normative document, all documents in BMWG > are informative. > > > I am not sure I have understood the context. I do not see the problem. > Compressed SID is the "SID" too. > 128bit entry inside the SRH is called "Segment List" in the RFC 8754. > Hence, no problems because names are different. > Eduard > -----Original Message----- > From: LUIS MIGUEL CONTRERAS MURILLO > <[email protected] > <mailto:[email protected]>> > Sent: Thursday, November 27, 2025 13:40 > To: Joel Halpern <[email protected] <mailto:[email protected]>>; lsr > <[email protected] <mailto:[email protected]>> > Cc: Giuseppe Fioccola <[email protected] > <mailto:[email protected]>>; Paolo Volpato > <[email protected] <mailto:[email protected]>>; Bruno Decraene > <[email protected] <mailto:[email protected]>>; Vasilenko > Eduard > <[email protected] <mailto:[email protected]>> > Subject: RE: [Lsr] Where to clarify RFC 9352 relative to SID containers > > Hi Joel, > > Not sure if this would be what you are looking for (especially because is an > outcome of BMWG and not LSR), but draft-ietf-bmwg-sr-bench-meth includes > proposal of segment list scale testing that could serve for the purpose you > comment (that is, adding maximum number of 128 bit pieces as an aspect to > be considered during the benchmarking process). So maybe the point that you > raise can be included here. > > I copy my co-authors in case they want to complement with additional > comments. > > Best regards > > Luis > > -----Mensaje original----- > De: Joel Halpern <[email protected] <mailto:[email protected]>> > Enviado el: jueves, 27 de noviembre de 2025 11:07 > Para: lsr <[email protected] <mailto:[email protected]>> > Asunto: [Lsr] Where to clarify RFC 9352 relative to SID containers > > AVISO/WARNING: Este correo electrónico se originó desde fuera de la > organización. No haga clic en enlaces ni abra archivos adjuntos a menos que > reconozca al remitente y sepa que el contenido es seguro / This email has > been originated from outside of the organization. Do not click links or open > attachments unless you recognize the sender and know the content is safe. > > > First, to be clear, what I am describing is NOT an error in RFC 9352. > Thus, I don't think an erratum is the appropriate way to document for future > readers this additional aspect of the intent of certain maximum segment depth > advertisements for SRv6. > > RFC 9352 talks about the maximum number of SIDs. However, when SIDs are > carried in compressed SID containers, the number that matters for some > (maybe all?) of the maximum segment depths is the number of 128 bit > pieces, not the number of SIDs. Apparently, several implementations > are consistent with that. It seems a bit odd to write another RFC just to say > that. Is there some document in process that could sensibly capture this. > > (As RFC 9352 predates the Compressed SID RFC it makes sense that this case is > not disucssed there.) > > Yours, > > Joel > > _______________________________________________ > Lsr mailing list -- [email protected] <mailto:[email protected]> > To unsubscribe send an email to [email protected] <mailto:[email protected]> > > ________________________________ > > Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, > puede contener información privilegiada o confidencial y es para uso exclusivo > de la persona o entidad de destino. Si no es usted. el destinatario indicado, > queda notificado de que la lectura, utilización, divulgación y/o copia sin > autorización puede estar prohibida en virtud de la legislación vigente. Si ha > recibido este mensaje por error, le rogamos que nos lo comunique > inmediatamente por esta misma vía y proceda a su destrucción. > > The information contained in this transmission is confidential and privileged > information intended only for the use of the individual or entity named above. > If the reader of this message is not the intended recipient, you are hereby > notified that any dissemination, distribution or copying of this communication > is strictly prohibited. If you have received this transmission in error, do > not > read it. Please immediately reply to the sender that you have received this > communication in error and then delete it. > > Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, > pode conter informação privilegiada ou confidencial e é para uso exclusivo da > pessoa ou entidade de destino. Se não é vossa senhoria o destinatário > indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia > sem > autorização pode estar proibida em virtude da legislação vigente. Se recebeu > esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente > por esta mesma via e proceda a sua destruição > _______________________________________________ > Lsr mailing list -- [email protected] <mailto:[email protected]> > To unsubscribe send an email to [email protected] <mailto:[email protected]> > > > _______________________________________________ > Lsr mailing list -- [email protected] <mailto:[email protected]> > To unsubscribe send an email to [email protected] <mailto:[email protected]> > > > > _______________________________________________ > Lsr mailing list -- [email protected] > To unsubscribe send an email to [email protected] > > _______________________________________________ > Lsr mailing list -- [email protected] > To unsubscribe send an email to [email protected] > > _______________________________________________ > Lsr mailing list -- [email protected] > To unsubscribe send an email to [email protected] > > > _______________________________________________ > Lsr mailing list -- [email protected] > To unsubscribe send an email to [email protected] > > _______________________________________________ > Lsr mailing list -- [email protected] > To unsubscribe send an email to [email protected] > _______________________________________________ > Lsr mailing list -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
