Deterministic Networking Problem Statement
RFC 8557

Note: This ballot was opened for revision 07 and is now closed.

Deborah Brungard Yes

Warren Kumari Yes

Comment (2018-12-05 for -07)
I'm balloting Yes (and not NoObj) because I specifically *do* see archival value in this document (and use-case / problem-statement documents in general); when someone has to implement / deploy the technology, having them understand what problem it is supposed to solve (or what the use case is) is valuable...

I did have a few nits - they are purely editorial, and I'm only mentioning them because I noticed them, feel free to address or not.

1: Section 1.  Introduction
"While the initial user base has focused almost entirely on Ethernet
   physical media and Ethernet-based bridging protocol (from several
   Standards Development Organizations), the need for Layer-3 expressed
   above, must not be confined to Ethernet and Ethernet-like media, and
   while such media must be encompassed by any useful Deterministic
   Networking (DetNet) Architecture, cooperation between IETF and other
   SDOs must not be limited to IEEE or IEEE 802."
I found this sentence to be hard to parse / a run on -- the comma between above and must didn't help, but splitting it up into multiple sentences would sure make it easier to read. 

2: "As a result of this work, it will be possible to establish a multi-hop path over the IP or MPLS network,"
The "will" in the above made me twitch -- I understand that that is the expected outcome / desire, but wording it as "will" seems like hubris.

3: "In other words, a Deterministic Network is
   backwards compatible with - capable of transporting - statistically
   multiplexed traffic while preserving the properties of the accepted
   deterministic flows."
The hyphens around "capable of transporting" confused me. Perhaps it was intended to be a parenthetical?

(Spencer Dawkins) No Objection

Benjamin Kaduk No Objection

Comment (2018-12-06 for -07)
Section 2
   Robustness is a common need for networking protocols, but plays a
   more important part in real-time control networks, where expensive
   equipment, and even lives, can be lost due to misbehaving equipment.

I guess this is a side note in some sense, but are we saying we want to get in
the business of making life/safety-grade protocols?

Section 3.1

   On the other end, the deterministic portion of a path may be a tunnel
   between and ingress and an egress router.  In any case, routers and
   switches in between should not need to be aware whether the path is
   end-to-end of a tunnel.

Nit: is that "of" or "or" in the last line?

Alvaro Retana No Objection

Comment (2018-12-05 for -07)
Given the close relationship between this document and draft-ietf-detnet-use-cases, I think that it would have been beneficial to produce a single document.  As it stands neither one normatively references the other.

draft-ietf-detnet-architecture-09 says it better:

   The Deterministic Networking Problem Statement
   [I-D.ietf-detnet-problem-statement] introduces Deterministic
   Networking, and Deterministic Networking Use Cases
   [I-D.ietf-detnet-use-cases] summarizes the need for it.

Martin Vigoureux No Objection

Alissa Cooper Abstain

Comment (2018-12-05 for -07)
I am balloting ABSTAIN, which does not block publication of this document. I agree with Mirja's first ballot point. Moreover, the document contains forward-looking statements that will presumably be overtaken by events in the near future, e.g. the statements about what the IETF will need to do in Section 1.


Section 2 says: "Considerable experience ([ODVA]/[EIP],[AVnu], [Profinet],[HART],[IEC62439], [ISA100.11a] and [WirelessHART], etc...)"
It seems like the "etc." should be replaced with an enumerated list of citations, or a description of what the other experience is that isn't explicitly listed.

Mirja K├╝hlewind Abstain

Comment (2018-11-30 for -07)
I don't really see the archival value of this doc; it rather reads like an extended charter. However, that's not a reason to block publication, therefore I ballot abstain.

One comment on this text in section 3.3: 
"indicate the flows and packet sequences in-band with the flows;"
I don't really understand why this is needed or where this requirement comes from. Is then assumption that in-ordered delivery is needed? However, why would packets be re-ordered in a detnet system? Also, not all flows might need ordered delivery; so that might be another flow characteristic which you may want to configure.