Re: RFC2460bis WGLC comments

[Brian E Carpenter <[e-mail]>]

Very brief comments in line...

On 08/06/2016 23:43, [e-mail] wrote:
> I have read through the change set and have the following comments:
> 
> 1. Update reference to working group document:
>     [I-D.hinden-6man-rfc4291bis].
> 
> 2. HBH header handling.
> 
> 2460bis relaxes the must to a should. And incorporates a paragraph from 7045 giving performance considerations.
> The use of a _should_ process combined with a _may_ drop is not elegant.
> The second paragraph can also be read as a licence to drop.
> 
> After having thought about the text in draft-ietf-6man-hbh-header-handling, I propose the following instead:
> 
> OLD:
>    The exception referred to in the preceding paragraph is the Hop-by-
>    Hop Options header, which carries information that should be examined
>    and processed by every node along a packet's delivery path, including
>    the source and destination nodes.  The Hop-by-Hop Options header,
>    when present, must immediately follow the IPv6 header.  Its presence
>    is indicated by the value zero in the Next Header field of the IPv6
>    header.
> 
>    It should be noted that due to performance restrictions nodes may
>    ignore the Hop-by-Hop Option header, drop packets containing a hop-
>    by-hop option header, or assign packets containing a hop-by-hop
>    option header to a slow processing path.  Designers planning to use a
>    hop-by-hop option need to be aware of this likely behaviour.
> 
> NEW:
>    The exception referred to in the preceding paragraph is the Hop-by-
>    Hop Options header, which carries information that may be examined
>    and processed by nodes along a packet's delivery path, including the
>    source and destination nodes.  The Hop-by-Hop Options header, when
>    present, must immediately follow the IPv6 header.  Its presence is
>    indicated by the value zero in the Next Header field of the IPv6
>    header.
> 
>    NOTE: While RFC2460 required that all nodes must process the Hop-by-
>    Hop Options header, it is now expected that nodes only process the
>    Hop-by-Hop Options header if explicitly configured to do so.

wfm

> 
> 
> In short replace the should we a may, making HBH options header purely optional. Note that section 4.8 in 2460bis already uses a may.
> I also suggest we remove the 7045 paragraph on performance considerations, that's highly subjective.
> 
> 3. Section 4.3 HBH
> OLD:
>   The Hop-by-Hop Options header is used to carry optional information
>    that should be examined by every node along a packet's delivery path.
>    The Hop-by-Hop Options header is identified by a Next Header value of
>    0 in the IPv6 header, and has the following format:
> 
> NEW:
>    The Hop-by-Hop Options header is used to carry optional information
>    that may be examined by every node along a packet's delivery path.
>    The Hop-by-Hop Options header is identified by a Next Header value of
>    0 in the IPv6 header, and has the following format:

wfm

> 
> Same change as above.
> 
> 4. Fragmentation.
> 
> We need more people to review the rewritten fragmentation section.
> 
> Are people comfortable with these new names on the parts?
> 
> +------------------+-------------------------+---//----------------+
>  |  Per-Fragment    | Extension & Upper-Layer |   Fragmentable      |
>  |    Headers       |       Headers           |      Part           |
>  ------------------+-------------------------+---//----------------+
> 
> I kind of think the old terms where clearer, but it might just be what I'm used to.

I'm OK with it. Or with the old terms.

     Brian