[Int-area] Éric Vyncke's No Objection on draft-ietf-intarea-frag-fragile-15: (with COMMENT)

[Éric Vyncke via Datatracker <[e-mail]>]

Éric Vyncke has entered the following ballot position for
draft-ietf-intarea-frag-fragile-15: 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-intarea-frag-fragile/



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

Thank you for the work put into this document, a real problem in the real
Internet

I have a couple of COMMENTs below in the hope to improve the quality of the
document.

Regards,

-éric

== COMMENTS ==

-- Section 2.1 --

"An Internet path connects a source node to a destination node", what about
multicast? If the document is for unicast, then it should be stated early in
the document.

s/If a link fails,/If a link or a router fail,/

A reference to "see NOTE 1" (using xref/target in XML) would be easier for the
reader. Same for "NOTE 2" of course.

-- Section 2.2 --

"In IPv4, the upper-layer header usually appears in the first fragment" perhaps
the right place to mention RFC 3128 (informational) ?

-- Section 2.3 --

Perhaps explicitly mention that PLPMTUD is therefore more reliable than
ICMP-based PMTUD but not applicable to all traffic?

-- Section 3.1 --

Please add reference to A+P (or better MAP ?) and CGN ? (done only in section
3.3)

More generally, it is not clear for the reader why virtual reassembly increases
the fragility.

-- Section 3.3 --

"NOTE 1" is it the same as in section 2.1? Also add xref/target for the
reader's convenience.

-- Section 3.4 --

Suggest to replace "trailing fragments" by "non-initial fragments" as it is
more accurate.

-- Section 3.6 --

The section title refers to "data rate" while it is rather "fragment generation
rate" (which will of course increase the data rate as a consequence). BTW, I
never thought about that ;-)

-- Section 3.7 --

Is it still the case that "Many implementations set the Identification field to
a predictable value" ? Would it be possible to have some data backing this
statement?

-- Section 3.8 --

AFAIK, RFC 4890 is only applicable to IPv6 ICMP and not to IPv4 ICMP
messages... please rewrite this part.

-- Section 3.8.1 --

s/ICMP rate limiting/ICMP generation rate limiting/

Also RFC4442 is IPv6 specific. Add some text for IPv4 ?

-- Section 3.8.2 --

Unsure what the "zone-based" has to do with the content of this section.

-- Section 3.8.3 --

It may be worth adding that the paths TO and FROM the anycast DNS server can be
different, hence, causing the described problem.

-- Section 3.8.4 --

While actually correct, this would also mean that BCP38 is not implement in
this network.

-- Section 6.3 --

"that behavior MUST be clearly documented" unsure whether a "MUST" can be used
for a non protocol action.

-- Section 6.5 --

"MAY rate limit ICMP messages" please state "MAY rate limit the generation ICMP
messages"

Unsure how "Network operators SHOULD NOT filter IP fragments " can be
implemented as non-initial fragments have no UDP/TCP ports... Doing statefull
filtering is probably undoable. Even with a SHOULD this is probably too
restrictive.

== NITS ==

-- Section 2.1 --

s/Whlie/While/