Re: Éric Vyncke's No Objection on draft-ietf-6man-icmp-limits-07: (with COMMENT)

Tom Herbert <tom@quantonium.net> Mon, 09 March 2020 17:59 UTC

MIME-Version: 1.0
References: <158349584610.2156.6067317475048579614@ietfa.amsl.com> <CAPDqMeosz3uxstbb1rxgVT8CdLjfev3_fPmsTiTmsfxzaadOXA@mail.gmail.com> <BCD5B47E-E6B7-437B-B0D8-C13BC282E686@cisco.com>
In-Reply-To: <BCD5B47E-E6B7-437B-B0D8-C13BC282E686@cisco.com>
From: Tom Herbert <tom@quantonium.net>
Date: Mon, 09 Mar 2020 10:58:51 -0700
Message-ID: <CAPDqMergaTzb=y+hTXiH4J2zCpCwh+-RYFnHc2r-VpBcOCiNKA@mail.gmail.com>
Subject: Re: Éric Vyncke's No Objection on draft-ietf-6man-icmp-limits-07: (with COMMENT)
To: "Eric Vyncke (evyncke)" <evyncke@cisco.com>
Cc: The IESG <iesg@ietf.org>, draft-ietf-6man-icmp-limits@ietf.org, "6man-chairs@ietf.org" <6man-chairs@ietf.org>, "ipv6@ietf.org" <ipv6@ietf.org>, Bob Hinden <bob.hinden@gmail.com>
Content-Type: multipart/alternative; boundary="0000000000003bd53f05a06fc213"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/s-MFNZktX0lPTZsPdRFba0iRxFA>
Precedence: list

On Sat, Mar 7, 2020, 1:44 AM Eric Vyncke (evyncke) <evyncke@cisco.com>
wrote:

> Hello Tom
>
> Thank you for the quick reply.
>
> See below for EV> (and I have removed most of the text when we agree)
>
> Regards
>
> -éric
>
> -----Original Message-----
> From: Tom Herbert <tom@quantonium.net>
> Date: Friday, 6 March 2020 at 22:58
> To: Eric Vyncke <evyncke@cisco.com>
> Cc: The IESG <iesg@ietf.org>, "draft-ietf-6man-icmp-limits@ietf.org" <
> draft-ietf-6man-icmp-limits@ietf.org>, "6man-chairs@ietf.org" <
> 6man-chairs@ietf.org>, "ipv6@ietf.org" <ipv6@ietf.org>, Bob Hinden <
> bob.hinden@gmail.com>
> Subject: Re: Éric Vyncke's No Objection on draft-ietf-6man-icmp-limits-07:
> (with COMMENT)
>
>     On Fri, Mar 6, 2020 at 3:57 AM Éric Vyncke via Datatracker
>     <noreply@ietf.org> wrote:
>     >
>     >
>     > -- Section 2.2 --
>     > Why not using a new code for 'unrecognized header' by intermediate
> node ? I
>     > really wonder why: it can only be confusing to existing
> implementation.
>     >
>     I imagine the host response would be the same.
>
> EV> may be
>
>     > Please also ensure what is meant by 'destination' here... I would
> prefer to
>     > avoid discussions when a routing-header is used (too many
> discussions around
>     > this in 6MAN already)
>     >
>     Will make that "final destination"
>
> EV> yes, please :)
>
>
>     > -- Section 2.4 --
>     > How can the original source distinguish among the two potential
> causes ? Why
>     > not using two code points? Or am I missing something obvious? I was
> really
>     > about to issue a blocking DISCUSS on this one.
>     >
>     If the Pointer points to the first byte of an extension header then
>     the limit on extension headers is inferred. If it points to something
>     inside extension headers then the length is exceeded. Grant it, that's
>     not 100% accurate but I don't believe that fine granularity is needed
>     for host response.
>
> EV> indeed, the source cannot distinguished among the two causes when the
> length is exceeded at the start of a new EH. Honestly, why not using two
> different code points? (Non blocking comment)
>

Very well, I'll fix to use different code points for this, and can also
create another for unrecognized header at intermediate node. So draft will
define six new parameter problem codes instead of four.

Tom

I will fix.

>
>

Éric Vyncke's No Objection on draft-ietf-6man-icm… Éric Vyncke via Datatracker
Re: Éric Vyncke's No Objection on draft-ietf-6man… Tom Herbert
Re: Éric Vyncke's No Objection on draft-ietf-6man… Eric Vyncke (evyncke)
Re: Éric Vyncke's No Objection on draft-ietf-6man… Tom Herbert
Re: Éric Vyncke's No Objection on draft-ietf-6man… Eric Vyncke (evyncke)