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

[Joel Halpern <[e-mail]>]

I am inclined to "Segment List", but can live with "Segment List field" 
if others feel that is helkpful.

Yours,

Joel

On 5/30/2023 11:12 AM, Darren Dukes (ddukes) wrote:
>
> Hi Greg and Joel, I’m happy with:
>
> Segments Left: Defined in [RFC8200], Section 4.4.
> Specifically, for the SRH, the number of unprocessed
>
> 128-bit entries in the Segment List.
>
> It’s the more precise description. Now “Segment List field” or 
> “Segment List”?
>
> Thanks!
>
> Darren
>
> On 2023-05-29, 10:46 PM, "ipv6" <[e-mail]> wrote:
>
> 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
>         --------------------------------------------------------------------
>