[Detnet] Éric Vyncke's No Objection on draft-ietf-detnet-ip-06: (with COMMENT)

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

Éric Vyncke has entered the following ballot position for
draft-ietf-detnet-ip-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-detnet-ip/



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

Thank you for the work put into this document.

I support Roman's first DISCUSS.

Please find below a couple on non-blocking COMMENTs; but, I would really
appreciate a reply/answer/comment on all my COMMENTs.

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

Please bear with my lack of DetNet expertise... but I have to ask the following
question: how are IP fragments (i.e. lacking transport ports) processed? as
they cannot match the 6-tuple. Related question: what about ICMP messages? They
are often critical to a flow (PMTUd for instance, or traceroute) and should
perhaps inherit the DetNet service?

-- Abstract --
Beside being the smallest abstract I have ever read on an IETF document, I also
wonder about the wording "IP packet switched network". May be I am a purist,
but, IP packet are forwarded and not switched. => recommend to add more meat in
the abstract (notably differences with diffserv and intserv) *AND* remove the
'switched' word.

-- Section 4.5 --
"  While the DetNet IP data plane must support bidirectional DetNet
   flows, there are no special bidirectional features with respect to
   the data plane other than the need for the two directions of a co-
   routed bidirectional flow to take the same path."

This section does not use normative wording and I wonder whether the 'need' to
take the same path will always be true as some links have different throughput
up/down or their link loads could be different.

-- Section 5.1.2.1. --
"  The rules defined in this section only apply when the IPv4 Protocol
   or IPv6 Next Header Field contains the IANA defined value for UDP or
   TCP."

Is the intent to ignore those field when there is an IPv6 extension header
between the IP and transport headers ? Same question for section 5.1.2.3.

Does it also mean that SCTP is not supported?