Re: [IPv6] [Technical Errata Reported] RFC8754 (7102)

[Joel Halpern <[e-mail]>]

Good point.  That works for me.  That wording seems better than simply 
relying on people understanding "remaining".

Yours,

Joel

On 5/29/2023 10:17 PM, Greg Mirsky wrote:
> Hi, Joel et al.,
> as I understand it, segments are not removed from the Segment List. If 
> that is correct, then, according to the proposed definition, the value 
> of the Segments Left field is constant throughout the lifetime of a 
> given SRH. But that is not how it is supposed to be used, Right? I 
> think that the following might better reflect the use of the field:
> NEW TEXT:
> Segments Left:  Defined in [RFC8200], Section 4.4.
> Specifically, for the SRH, the number of unprocessed
> segments in the Segment List.
> Similarly, following up on your point about the need to use more 
> general terminology:
> NEW TEXT:
> Segments Left:  Defined in [RFC8200], Section 4.4.
> Specifically, for the SRH, the number of unprocessed
> 128-bit entries in the Segment List.
>
> WDYT?
>
> Regards,
> Greg
>
> On Mon, May 29, 2023 at 6:59 PM Joel Halpern <[e-mail]> wrote:
>
>     I think there are two issues, both easily resolved.
>
>     Given that different people may have been reading the existing text
>     differently, I think that we need to make sure 6man agrees on what it
>     should have meant.   To solve this, we "merely" need folks to
>     speak up.
>
>     The second issue is that we want the wording to end up correct
>     even when
>     we add compressed SID containers, without introducing a normative
>     dependence on a WG I-D.
>
>     The proposed clarifying text currently reads:
>
>     Segments Left:  Defined in [RFC8200], Section 4.4.
>     Specifically, for the SRH, the number of segments
>     remaining in the Segment List.
>
>     If I try to interpret that looking forward to compressed SID
>     containers, I end up confused as to what is intended.  (I know
>     what the various pieces of pseudo-code add up to, but the
>     definition should be clear.)  I think the following may help:
>
>     Segments Left:  Defined in [RFC8200], Section 4.4.
>     Specifically, for the SRH, the number of 1228 bit entries
>     remaining in the Segment List.
>
>     I had earlier thought that maybe we could say "the number of 128
>     bit SIDs or SID containers", but I fear that would produce an
>     improper dependence since we don't have containers defined anywhere.
>
>     Thoughts?
>     Joel
>
>     On 5/29/2023 6:40 PM, Erik Kline wrote:
>     > There has been a request to engage in some word-smithing before
>     > returning this to Verified.
>     >
>     > May I ask that it be put back into Reported state while this is
>     discussed?
>     >
>     > On Tue, Aug 23, 2022 at 12:38 PM RFC Errata System
>     > <[e-mail]> wrote:
>     >> The following errata report has been submitted for RFC8754,
>     >> "IPv6 Segment Routing Header (SRH)".
>     >>
>     >> --------------------------------------
>     >> You may review the report below and at:
>     >> https://www.rfc-editor.org/errata/eid7102
>     >>
>     >> --------------------------------------
>     >> Type: Technical
>     >> Reported by: Darren Dukes <[e-mail]>
>     >>
>     >> Section: 2
>     >>
>     >> Original Text
>     >> -------------
>     >> Segments Left:  Defined in [RFC8200], Section 4.4.
>     >>
>     >> Corrected Text
>     >> --------------
>     >> Segments Left:  Defined in [RFC8200], Section 4.4.
>     >> Specifically, for the SRH, the number of segments
>     >> remaining in the Segment List.
>     >>
>     >> Notes
>     >> -----
>     >> RFC8754 describes “The encoding of IPv6 segments in the SRH”
>     where IPv6 segments are defined in RFC8402.  RFC8402 describes
>     binding SIDs and adjacency SIDs for SRv6. Both these SID types
>     identify more than a single explicitly listed intermediate node to
>     be visited.
>     >> The current definition of Segments Left only indicates it is
>     defined in RFC8200, and RFC8200 defines it as “Number of route 
>     segments remaining, i.e., number of explicitly listed intermediate
>     nodes still to be visited before reaching the final destination”.
>     >>
>     >> Previous versions of draft-ietf-6man-segment-routing-header
>     (0-11) referenced RFC2460/RFC8200 and described the Segments Left
>     field by use in the SRH; as an index into the Segment List. This
>     was removed in later versions (12/13) to consolidate the use of
>     segments left to be specific to the segment processed (now section
>     4.3.1).  However, that removed the definition of its meaning in
>     the SRH which led to the current issue.
>     >>
>     >> The corrected text restores the meaning of Segments Left for
>     the SRH in relation to Segment List (which is not defined in
>     RFC8200), while still leaving its use during segment processing to
>     the segment definition (section 4.3.1 or future documents).
>     >>
>     >> Instructions:
>     >> -------------
>     >> This erratum is currently posted as "Reported". If necessary,
>     please
>     >> use "Reply All" to discuss whether it should be verified or
>     >> rejected. When a decision is reached, the verifying party
>     >> can log in to change the status and edit the report, if necessary.
>     >>
>     >> --------------------------------------
>     >> RFC8754 (draft-ietf-6man-segment-routing-header-26)
>     >> --------------------------------------
>     >> Title               : IPv6 Segment Routing Header (SRH)
>     >> Publication Date    : March 2020
>     >> Author(s)           : C. Filsfils, Ed., D. Dukes, Ed., S.
>     Previdi, J. Leddy, S. Matsushima, D. Voyer
>     >> Category            : PROPOSED STANDARD
>     >> Source              : IPv6 Maintenance
>     >> Area                : Internet
>     >> Stream              : IETF
>     >> Verifying Party     : IESG
>     > --------------------------------------------------------------------
>     > IETF IPv6 working group mailing list
>     > [e-mail]
>     > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>     > --------------------------------------------------------------------
>
>     --------------------------------------------------------------------
>     IETF IPv6 working group mailing list
>     [e-mail]
>     Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>     --------------------------------------------------------------------
>