[ippm] Éric Vyncke's No Objection on draft-ietf-ippm-multipoint-alt-mark-06: (with COMMENT)

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

Éric Vyncke has entered the following ballot position for
draft-ietf-ippm-multipoint-alt-mark-06: 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-ippm-multipoint-alt-mark/



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

Thank you for the work put into this document. Beside some of my COMMENT about
the wording, the flow and the explanations make the document easy to read.

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

The wording "Multipoint to multipoint" raised confusion in my mind to be
honest. It took reading further in the document to understand what it was
about. What about: "multi-party multiple flows" or "aggregated alternate
marking" or "clustered alternate marking" ?

-- Section 1 --
In the 5th paragraph, suggest to replace "Multipoint alternate marking" by
"this document" (if my assumption is correct).

" Intelligent Network " looks more like a marketing name than an IETF defined
one.

-- Section 3 --
What's in a name... but using "flow" to convey the semantics of multiple flows
is weird. Why not using "aggregated flows" ?

"headers fields" is it limited to layer-3 only? Probably worth specifying so
early in the text by "layer-3 and layer-4 headers fields"

Using "TCP 5-tuple" looks simple but what about fragmented packets ?

I really have problems with sentences such as "ECMP flow is in scope by
definition, since it is a point-to-multipoint unicast flow", esp
"point-to-multipoint unicast flow" that looks like an oxymoron to me. Perhaps,
it is only me having this parsing problem ?

-- Section 4 --
Again about IPv4 fragmentation, if fragmentation happens on the path, then
there could be more IP packets received than sent. Or are non-initial fragments
ignored? If so, I suggest to clarify the text.

== NITS ==

RFC 7322 suggests "The full expansion of the text should be followed by the
abbreviation itself in parentheses" ;-) Not always applied through this
document: e.g., CIR, OTT

-- Section 1 --
s/ECMP (Equal-Cost Multi-Path) paths/ECMP (Equal-Cost MultiPath)/ to avoid
repeating "path".