[Detnet] Alissa Cooper's No Objection on draft-ietf-detnet-architecture-13: (with COMMENT)

[Alissa Cooper via Datatracker <[e-mail]>]

Alissa Cooper has entered the following ballot position for
draft-ietf-detnet-architecture-13: 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-architecture/



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

Thanks for addressing my DISCUSS point. Old COMMENT left here:

I support Benjamin's DISCUSS.

I agree with others that this document should be informational.

= Section 3.1 =

"There are, of course, simpler methods available (and employed, today)
   to achieve levels of latency and packet loss that are satisfactory
   for many applications."

I think this paragraph would make more sense if it said "specific levels of
latency and packet loss for particular applications." A lot of applications
have satisfactory performance without any of the methods/techniques described.

"Prioritization and over-provisioning is one
   such technique."

It seems these are two techniques, not one.

= Section 3.2.1.2 =

s/sensitive/time-sensitive/

I can't parse this sentence:

'In general, users are encouraged to use, instead of, "do this when you
   get the packet," a combination of:

   o  Sub-microsecond time synchronization among all source and
      destination end systems, and

   o  Time-of-execution fields in the application packets.'

= Section 3.2.2.2 =

s/ Either of these functions/ Any of these functions/

"Providing sequencing information to the packets of a DetNet
      compound flow.  This may be done by adding a sequence number or
      time stamp as part of DetNet, or may be inherent in the packet,
      e.g., in a higher layer protocol, or associated to other physical
      properties such as the precise time (and radio channel) of
      reception of the packet."

How do multiple connected DetNet nodes know which fields they are supposed to
use as the packet sequence number?

= Section 3.3.1 =

"the highest-priority non-DetNet packet is also ensured a worst-case latency."
--> Did you mean "ensured less than or equal to a worst-case latency"?

= Section 4.3.2 =

If applications need to be altered to be run over DetNet, or if they need to be
DetNet-aware, it would be useful to state that explicitly up front somewhere in
this document. This is sort of implied in this section but it's not clear.

= Section 6 =

"However, the requirement for every (or almost every) node along the
   path of a DetNet flow to identify DetNet flows may present an
   additional attack surface for privacy, should the DetNet paradigm be
   found useful in broader environments."

I'm not sure what is meant by "broader environments." Is the implication that
flow identification doesn't present a privacy risk within a single
administrative domain? I don't think that is always true.