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

From: Éric Vyncke via Datatracker <[email-masked]>
Date: Fri, 06 Mar 2020 03:57:26 -0800

Éric Vyncke has entered the following ballot position for
draft-ietf-6man-icmp-limits-07: No Objection

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://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-6man-icmp-limits/

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

Tom,

Thank you for the work put into this document. It is short and easy to read
while addressing a real problem in real deployments.

********************
*  I was about to add a DISCUSS for not using the right BCP14 RFC 8174 template
but please FIX this *       (as this is the first review, I would suggest to
issue today a revised I-D with just this fix *       before other IESG
reviews). * *  I was also about to ballot a DISCUSS on the comment in section
2.4...
*******************

Please find below some non-blocking COMMENTs and NITs. An answer will be
appreciated.

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

-- Section 1.2 --
Just wondering why the "aggregate header limits" has a section on its own. Feel
free to keep it like it is but this looks weird.

-- Section 2 --
Strongly suggest to use TBA1, TBA2, ... in order to avoid mistakes done by the
IANA.

-- 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.

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)

-- 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.

-- Section 3 --
Some justifications on why using a different ICMPv6 format would really help
the reader.

-- Section 4.1 --
The wording "1) Real error (existing codes)" looks weird because the code
points in this documents will also be existing. Why not using "1) RFC 4443
error codes" ?

-- Section 5.2 --
Is applicable to RFC 4443 in general, so, I wonder why it is in this document.

== NITS ==

-- Section 1.1 --
If I was picky, then I would argue that "Extension Headers are placed between
the IPv6 header and the Upper-Layer Header in a packet" is not always true: if
Next-Header is 59 (No Next Header per RFC 8200 section 4.7) ;-)

-- Section 2.1 + 3.1--
s/IPv6 Fields:/IPv6 Header Fields:/

---

From: Tom Herbert <[email-masked]>
Date: Fri, 6 Mar 2020 13:58:34 -0800

> https://datatracker.ietf.org/doc/draft-ietf-6man-icmp-limits/
Okay.

> I hope that this helps to improve the document,
Thanks for the review!

> free to keep it like it is but this looks weird.
It's distinctly different than the other errors. This error can be
applied to other packet headers than IPv6 whereas the rest are only
about IPv6 header or extension header. Hence we needed to use
Destination Unreachable with extended ICMP message instead of
Parameter Problem type.

> Strongly suggest to use TBA1, TBA2, ... in order to avoid mistakes done by the

Thanks, will do that.

> really wonder why: it can only be confusing to existing implementation.
I imagine the host response would be the same.

> avoid discussions when a routing-header is used (too many discussions around
Will make that "final destination"

> 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.

> Some justifications on why using a different ICMPv6 format would really help
Okay, will add some text.

> points in this documents will also be existing. Why not using "1) RFC 4443

Will fix.

> Is applicable to RFC 4443 in general, so, I wonder why it is in this document.
That was due to feedback from 6man WG to mention reliability of ICMP.

> Next-Header is 59 (No Next Header per RFC 8200 section 4.7) ;-)
That's from RFC8200.

> s/IPv6 Fields:/IPv6 Header Fields:/

Will fix.

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Sat, 7 Mar 2020 09:44:27 +0000

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 <[email-masked]>
Date: Friday, 6 March 2020 at 22:58
To: Eric Vyncke <[email-masked]>
Cc: The IESG <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Bob Hinden <[email-masked]>
Subject: Re: Éric Vyncke's No Objection on draft-ietf-6man-icmp-limits-07: (with COMMENT)

EV> may be

EV> yes, please :)

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)

---

From: Tom Herbert <[email-masked]>
Date: Mon, 9 Mar 2020 10:58:51 -0700

On Sat, Mar 7, 2020, 1:44 AM Eric Vyncke (evyncke) <[email-masked]>
wrote:

> Cc: The IESG <[email-masked]>, "[email-masked]" <
> [email-masked]>, "[email-masked]" <
> [email-masked]>, "[email-masked]" <[email-masked]>, Bob Hinden <
> [email-masked]>
> 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.

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Mon, 9 Mar 2020 18:16:45 +0000

Tom

Thank you, I sincerely believe that specific information can help (if not the application, at least the operation & troubleshooting).

NB: it is usually easier for everyone to wait until the IESG evaluation is over before uploading a new revision (less confusion).

Regards

-éric

Date: Monday, 9 March 2020 at 18:59

On Sat, Mar 7, 2020, 1:44 AM Eric Vyncke (evyncke) <[email-masked]<mailto:[email-masked]>> wrote:
Hello Tom

Regards

-éric

-----Original Message-----
From: Tom Herbert <[email-masked]<mailto:[email-masked]>>
Date: Friday, 6 March 2020 at 22:58
To: Eric Vyncke <[email-masked]<mailto:[email-masked]>>
Cc: The IESG <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Bob Hinden <[email-masked]<mailto:[email-masked]>>
Subject: Re: Éric Vyncke's No Objection on draft-ietf-6man-icmp-limits-07: (with COMMENT)

EV> may be

EV> yes, please :)

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.