[IPv6]Re: Jim Guichard's Discuss on draft-ietf-6man-comp-rtg-hdr-08: (with DISCUSS and COMMENT)

[James Guichard <[e-mail]>]

Hi Ron,

I notice that you did not respond to my comments outside of the DISCUSS. I will remove my DISCUSS but please consider my other comments.

Thanks!

Jim

From: James Guichard <[e-mail]>
Date: Thursday, May 30, 2024 at 7:44 AM
To: Ron Bonica <[e-mail]>, The IESG <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: [IPv6]Re: Jim Guichard's Discuss on draft-ietf-6man-comp-rtg-hdr-08: (with DISCUSS and COMMENT)
Thanks Ron, appreciate you taking care of this in such a timely manner.

Jim

From: Ron Bonica <[e-mail]>
Date: Wednesday, May 29, 2024 at 8:50 PM
To: The IESG <[e-mail]>, James Guichard <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: Re: Jim Guichard's Discuss on draft-ietf-6man-comp-rtg-hdr-08: (with DISCUSS and COMMENT)
Jim,

I have removed Section 7 and posted a new version. This satisfies your DISCUSS and one of Eric's  DISCUSS's.

                                                             Ron



Juniper Business Use Only

________________________________
From: Jim Guichard via Datatracker <[e-mail]>
Sent: Wednesday, May 29, 2024 5:55 PM
To: The IESG <[e-mail]>
Cc: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Subject: Jim Guichard's Discuss on draft-ietf-6man-comp-rtg-hdr-08: (with DISCUSS and COMMENT)

[External Email. Be cautious of content]


Jim Guichard has entered the following ballot position for
draft-ietf-6man-comp-rtg-hdr-08: 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://urldefense.com/v3/__https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!NEt6yMaO-gk!CtSfY4Ukz5xO_1x2KKbbtEi1Fax4xmb9rX8QQ9PX5AajwVpD25H0vtlybxZODNnHZM9oK9g__m9m1Gw$
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-6man-comp-rtg-hdr/__;!!NEt6yMaO-gk!CtSfY4Ukz5xO_1x2KKbbtEi1Fax4xmb9rX8QQ9PX5AajwVpD25H0vtlybxZODNnHZM9oK9g_lQER24s$



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I would like to DISCUSS Section 7 of the document as I have a few concerns and
question whether the section is even necessary. The relevant text from this
section is as follows:

           When a packet containing the CRH header leaves its source, it does
           not include its final destination address.  The final destination
           address is not added to the packet until the final CRH SID is
           resolved.

Jim> This first paragraph just seems to document what routing headers do - the
IPv6 destination address of the packet is not the final destination as carried
in the last entry in the routing header. Okay, got that but then the text jumps
to talk about address transparency but this concept is nothing new in the
presence of routing headers.

           While destination address transparency enhances privacy, it prevents
           intermediate nodes from verifying transport layer checksums.

Jim> Now the text introduces the notion that address transparency somehow
enhances privacy - how and why is that relevant? I think you are trying to
highlight that because addresses that are not the ultimate destination are
carried in the IPv6 destination address, and the routing header may have one or
more other addresses (these being the 'transparent' ones), then an intermediate
node might have trouble verifying transport layer checksums. If so, why not
just say if you use CRH then intermediate nodes may not be able to calculate
transport layer checksums unless they are CRH aware?


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

A few additional comments (I have included line numbers from idnits for the
latest version):

18         This document describes an experiment in which two new IPv6 Routing
19         headers are implemented and deployed.  Collectively, they are called
20         the Compact Routing Headers (CRH).  Individually, they are called
21         CRH-16 and CRH-32.

Jim> This first paragraph seems to overlap with the second paragraph with its
discussion of implementation and deployment. Perhaps reword it as follows as
the second paragraph is clear enough as to the purpose of the experiment.

           This document describes an experiment in which two new IPv6 Routing
           headers are defined; Collectively called the Compact Routing Headers
           (CRH).  Individually, they are called CRH-16 and CRH-32.

89      1.  Introduction

91         IPv6 [RFC8200] source nodes use Routing headers to specify the path
92         that a packet takes to its destination.  The IETF has defined several
93         Routing header types [IANA-RH].  This document defines two new

Jim> [IANA-RH] defines ‘Routing Types’ not ‘Routing header types’. It would be
more precise to just say ‘Routing Types’.

107        *  Because Path MTU Discovery (PMTUD) [RFC8201] is not entirely
108           reliable, many IPv6 hosts refrain from sending packets larger than
109           the IPv6 minimum link MTU (i.e., 1280 bytes).  When packets are
110           small, the overhead imposed by large Routing Headers is excessive.

Jim> The above text is making a statement that may or may not be true dependent
upon who one talks to ;-) I would suggest to say, ‘large Routing Headers may be
excessive’.

207        The topological function specifies how the processing node forwards
208        the packet to the interface identified by the IPv6 address.  The
209        following are examples:

Jim> Is this an exhaustive list? If not, please specify that.

232        The above-mentoned mechanisms are not defined here and are beyond the

Jim> s/above-mentoned/above-mentioned

250        *  If L is greater than Hdr Ext Len, discard the packet and send an
251           ICMPv6 Parameter Problem, Code 0, message to the Source Address,
252           pointing to the Segments Left field.

Jim> Why would the ICMPv6 message point to the Segments Left field? Shouldn’t
it point to the Hdr Ext Len field?

332     8.  Applications And SIDs

Jim> s/Applications And SIDs/Applications and SIDs