[Detnet] Paul Wouters' No Objection on draft-ietf-detnet-bounded-latency-09: (with COMMENT)

[Paul Wouters via Datatracker <[e-mail]>]

Paul Wouters has entered the following ballot position for
draft-ietf-detnet-bounded-latency-09: 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/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-detnet-bounded-latency/



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

Well written document. I have some comments that can be answered or ignored as
the authors see fit.

   If an already-established DetNet flow would be pushed beyond its latency
   requirements by the new DetNet flow, then the new DetNet flow can be
   refused, or some other suitable action taken.

This seems like a great power and should come with great responsibility. If
being a member of a DetNet is voluntary, that seems fine. But if such
membership is forced on the enduser, the concerns of RFC 8890 come into play.

[BennettDelay]

This seems to be a broken reference in section 4.2.2

   As illustrated by numerous
   implementation examples, some of the "Layer 3" mechanisms described
   in documents such as [RFC7806] are often integrated, in an
   implementation, with the "Layer 2" mechanisms also implemented in the
   same node.

But shepherds write up said:

   While there seems to be interest in this specification from multiple
   vendors, there are no publicly known implementations of this
   specification.

Which leaves me wondering what "implementation examples" refers to.

The security considerations mostly (and rightly so) point to RFC 9055 and RFC
8655. Although those seem to mostly focus on attacks against DetNet and there
is no mention of abuse by the DetNet. For example, if a mobile phone is
considered to be within a DetNet, the enduser has no real choice but to be part
of this. If a common service like a speedtest service the user can run to
evaluate their internet connection is also within or linked to a DetNet, it can
present the user a very false sense of low latency and network speed by simply
reserving an excessive amount of network between the endusers and the speedtest
service. This leads to a more generic concern of DetNet placing us in the "user
vs network" debate on who should have a say in how packets flow, which is
clearly not a problem this document needs or can address.