Deterministic Networking (DetNet) Data Plane: IP
draft-ietf-detnet-ip-07

[Ballot 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?

Closed request for Telechat review by IOTDIR with state 'Withdrawn': The document is on the IESG telechat today. No need anymore for a review (still welcome by the authors probably).

[Ballot comment]
I'm balloting NoObj in the "I read the protocol action, and I trust the sponsoring AD so have no problem." / "I have no cycles" sense.
Due to other work, I was not able to review this document nearly as thoroughly as I would have liked, but I *do* support Alvaro's (and others) DISCUSS - there are many places where the document says that the network MUST do something, but without the something being particularly well defined;I'm sure that the authors / DetNet WG understand what these are, but it's not clear from the document itself -- I'm guessing that this is defined in other documents, but I wasn't able to easily find them.

I was mystified by " For some of the protocols 5-tuples and 6-tuples cannot be used because the port information is not available (e.g., ICMP, IPSec ESP).  Same can be valid for flow aggregates. " - is this that the 5/6 tuples cannot be used for flow aggregates? I went to try and find more info on flow aggregates, and looked in ietf-detnet-data-plane-framework (which, like many of the referenced draft-detnet- documents should be Normative references), but it didn't seem to have much detail (other than that "There are many techniques to achieve aggregation" -- where is how flow aggregation actually works documented? This document (S4.4) says that: flow aggregation "is an important technique for improving
  scaling by reducing the state per hop", but without understanding how flows are aggregated, and the state needed per flow, this is hard to evaluate. In addition "In either case, the management or control function that provisions the aggregate flows must ensure that adequate resources are allocated and configured to provide combined service requirements of the individual flows." -- if this "of the individual flows", or "of the aggregate flows"? Presumably there will be a difference.

I found Section "5.3.  DetNet IP Traffic Treatment Procedures" to be very terse -- I was expecting to read this and understand what *exactly* the IP Traffic Treatment Procedures are - instead it seemed to feel more like "Implementations must make sure that they provide the service that has been configured". The section says: " Typical mechanisms used to provide different treatment to different flows includes the allocation of system resources (such as queues and buffers) and provisioning or related parameters (such as shaping, and policing). " -- but this all feels fairly circular - where is the treatment of traffic "when operating in an IP packet switched network." actually defined?
If I'm building a router/switch/similar, and what to provide support for DetNet over IP, what *exactly* do I do with traffic once it has been identified? How do I queue it differently? What happens if I cannot meet the requirement? Where is this documented?

Apologies for not being able to review this in the depth it deserves,
W

[Ballot comment]
Hi,

Thanks for this document.  The concept seems pretty simple, I just have a few comments.

3.  DetNet IP Data Plane Overview

In the introduction, I wondered whether it would be useful to mention that the Detnet forwarding is based on the classification of the 6-tuple that is programmed via the management plane with the next hop.  E.g. introducing the key forwarding concept defined in 5.2.

4.2.  DetNet Domain-Specific Considerations

Are the sub networks shown in Figure 4 all detnet aware supporting the service function?  If so, it may be helpful to explicitly clarify this.

4.3.3.  Path Selection

Like the other reviewers, I found the terminology around using 5-tuple/6-tuples slightly confusing in places.  In particular, the text in 4.3.3 regarding 5 tuples seemed confusing.  I basically interpreted the text as saying that 5-tuple forwarding already has these issues that must be avoided, and 6 tuple forwarding is no different.

Should it also mention that EMCP should be avoided as part of this path selection section?

I note that there is an informative reference to ietf-detnet-yang.  I wasn't sure whether an informative reference to YANG itself might also be worth adding.

Regards,
Rob

[Ballot comment]
Hi,

Thanks for this document.  The concept seems pretty simple, I just have a few comments.

3.  DetNet IP Data Plane Overview

In the introduction, I wondered whether it would be useful to mention that the Detnet forwarding is based on the classification of the 6-tuple that is programmed via the management plane with the next hop.  E.g. introducing the key forwarding concept defined in 5.2.

4.2.  DetNet Domain-Specific Considerations

Are the sub networks shown in Figure 4 all detnet aware supporting the service function?  If so, it may be helpful to explicitly clarify this.

4.3.3.  Path Selection

Like the other reviewers, I found the terminology around using 5-tuple/6-tuples slightly confusing in places.  In particular, the text in 4.3.3 regarding 5 tuples seemed confusing.  I basically interpreted the text as saying that 5-tuple forwarding already has these issues that must be avoided, and 6 tuple forwarding is no different.

Should it also mention the EMCP should be avoided here?

I note that there is an informative reference to ietf-detnet-yang.  I wasn't sure whether an informative reference to YANG itself might also be worth adding.

Regards,
Rob

[Ballot comment]
The other ADs caught a bunch of editorial stuff that I'll try to not
duplicate, though I do list a bunch of editorial stuff as well.

Section 1

  and routers that provide DetNet service to IP encapsulated data.  No
  DetNet-specific encapsulation is defined to support IP flows, instead
  the existing IP and higher layer protocol header information is used
  to support flow identification and DetNet service delivery.  Common

nit: comma splice

  This document provides an overview of the DetNet IP data plane in
  Section 3, considerations that apply to providing DetNet services via
  the DetNet IP data plane in Section 4.  Section 5 provides the

nit: this looks like it's trying to be a list but failing, so it's an
incomplete sentence.

Section 3

Do we want to have a note anywhere in here about how information about
which flows are DetNet flows and what behavior(s) they get (e.g., the
controller plane, or perhaps a forward reference to section 5), to
remind the reader about the architecture?

  Non-DetNet and DetNet IP packets are identical on the wire.

I suggest a different word than "identical", perhaps
"indistinguishable" (or maybe "the non-DetNet and DetNet IP packet
layouts")

  DetNet flow aggregation may be enabled via the use of wildcards,
  masks, lists, prefixes and ranges.  IP tunnels may also be used to

side note: I'd consider rewording so this doesn't sound like an
exhaustive list.

  Figure 1 illustrates a DetNet enabled IP network.  The DetNet enabled
  end systems originate IP encapsulated traffic that is identified
  within the DetNet domain as DetNet flows.  Relay nodes understand the

nit: I think the description of "identified" could be tightened up -- at
present, one could read this as either "the DetNet ingress classifies IP
traffic as DetNet or non DetNet, thus identifying the flows that are
DetNet flows", or "within the DetNet domain, these flows (originated
from the specific end systems) are identifiable as being DetNet flows".

  As non-DetNet and DetNet IP packets are identical on the wire, from
  data plane perspective, the only difference is that there is flow-

[whatever is done for "identical" above could be done here as well]
nit: missing article before "data-plane perspective"

Section 4.1

  IP flow identification means that DetNet must be aware of not only
  the format of the IP header, but also of the next protocol carried
  within an IP packet (see Section 5.1.1.3).

The way this is written it seems to bind as "(must be aware of) (not
only the format of) (the IP header) (but also of [the format of] the next
protocol)", but following the reference, it seems to only require
inspecting the value in the "next protocol" IP header field.
There would, of course, *also* be a requirement to look into TCP/UDP
headers to extract the ports needed for the 6-tuple, which is where I
originally thought this was going, but given the apparent intent, my
suggestion is to just s/next protocol/next protocol value/.

  End systems need to ensure that DetNet service requirements are met
  when processing packets associated to a DetNet flow.  When forwarding

We just said in the previous paragraph that end systems can be
DetNet-unaware; how would such DetNet-unaware systems ensure that DetNet
service requirements are met?

  packets, this means that packets are appropriately shaped on

Also, are end systems going to be *forwarding* packets?  I thought that
it was DetNet edge nodes (and transit/relay nodes) that would do so.

Section 4.2

  aware.  Such routers identify DetNet flows based on the IP 6-tuple,
  and ensure that the DetNet service required traffic treatment is
  provided both on the node and on any attached sub-network.

nit: I suggest hyphenating the compound adjective(s?) in "DetNet service
required traffic treatment" or otherwise rewording it, as I'm not
entirely clear on how to parse it.

  This solution provides DetNet functions end to end, but does so on a
  per link and sub-network basis.  Congestion protection and latency

We should probably note that there is a single point of failure at the
routers/etc. that remove and reapply these functions.

  Note that not mixing DetNet and non-DetNet traffic within a single
  5-tuple, as described above, enables simpler 5-tuple filters to be
  used (or re-used) at the edges of a DetNet network to prevent non-
  congestion-responsive DetNet traffic from escaping the DetNet domain.

I'd consider s/described/recommended/

Also, does the "simpler filters" also apply to determining what inbound
traffic should receive DetNet treatment?

Section 4.3.2

  future document.  From an encapsulation perspective, the combination
  of the 6-tuple i.e., the typical 5-tuple enhanced with the DSCP and
  previously mentioned optional field (i.e., flow label), uniquely
  identifies a DetNet IP flow.

I agree with the directorate reviewer that the language here needs to
get cleaned up.

  queue or shaper, is used by such flows.  There are multiple methods
  that MAY be used by an implementation to defend service delivery to
  reserved DetNet flows, including but not limited to:

nit: this doesn't seem like a normative MAY.

Section 4.3.3

  next hops.  As mentioned above, the DetNet IP data plane identifies
  flows using "6-tuple" header information as well as the additional
  optional header field.  DetNet generally allows for both flow-

Please just name the "optional header field" field directly; there's no
need to be oblique about it.

  Care should be taken when using different next hops for the same
  5-tuple.  As discussed in [RFC7657], unexpected behavior can occur
  when a single 5-tuple application flow experience reordering due to
  being split across multiple next hops.  Understanding of the

For some reason I thought the detnet architecture doc also had some
discussion of potential consequences of having a single flow split
across multiple paths, but all I can find is Section 3.2.2.2 that points
out there may be need to have additional buffering in such cases, in
order to equalize delays.  (Maybe I'm thinking of a different detnet
document, though I'm not sure which one that would be.)

  application and transport protocol impact of using different next
  hops for the same 6-tuple is required.  Again, this impacts path

I don't think I understand why we went from "5-tuple" to "6-tuple" in
the same paragraph.

Section 4.4

  flow identification.  DetNet IP flows can be aggregated using any of
  the 6-tuple, and an additional optional field (i.e., flow label).

Similarly to the previous comments, perhaps this should be "any of the
6-tuple and flow label"?  There's no need to add "optional" when already
subject to "using any of".

Section 5.1

  IP and higher layer protocol header information is used to identify
  DetNet flows.  All DetNet implementations that support this document
  MUST identify individual DetNet flows based on the set of information
  identified in this section.  Note, that additional flow

Does this requirement apply even to those implementations that have no
need to act at flow-level granularity, e.g., a router that only provide
DetNet service for aggregated flows, as recommended in Section 4.4?

  The configuration and control information used to identify an
  individual DetNet flow MUST be ordered by an implementation.
  Implementations MUST support a fixed order when identifying flows,
  and MUST identify a DetNet flow by the first set of matching flow
  information.

I'm a little surprised that this type of determinism is only an
implementation-level requirement.  If I'm understanding correctly, this
requirement would still allow for two different implementations to use
different rules for flow identification, and thus, potentially, to map a
single end-to-end flow to different classes of service.

Section 5.1.1.3

  An implementation MUST support flow identification based on the next
  protocol values defined in Section 5.1.2.  Other, non-zero values,
  MUST be used for flow identification.  Implementations SHOULD allow

I don't understand what distinction we're trying to draw between flow
identification based on the values defined in Section 5.1.2 and flow
identification based on other (non-zero) values.  Aren't they both
MUST-level requirements, as written?

  for these fields to be ignored for a specific DetNet flow.

side note: it seems like we're using "flow" to mean a couple different
(but similar) things in this paragraph (e.g., "considering IPv4
Protocol/IPv6 Next Header to be distinct or not").  Perhaps that's
unavioidable, though.

Section 5.1.1.4

  Traffic Class Field when processing IPv6 packets.  Implementations
  MUST support list based matching of DSCP values, where the list is

nit: hyphenate "list-based matching"

Section 6

  Information identifying a DetNet flow is ordered and implementations
  use the first match.  This can, for example, be used to provide a

[this bit might perhaps be affected if my previous comment about
implementation-specific results in any changes]

  DetNet service for a specific UDP flow, with unique Source and
  Destination Port field values, while providing a different service
  for the aggregate of all other flows with that same UDP Destination
  Port value.

[and this part actually seems to be setting at least an expectation that
the order is tied down more tightly than just "implementation specific".
Is this order perhaps something that the controller plane is expected to
provision?]

Section 7

We discuss elsewhere the need for end systems to (paraphrasing) "not
shoot themself in the foot", i.e., actually provide the resources
necessary to meet DetNet traffic guarantees.  For the case of DN
attached systems that are behind a sub-network (e.g., ES2 in Figure 3),
are there also considerations on the ability of that sub-network to
provide the necessary level of service?

Is there a need for synchronization of information about DetNet flows?
For example, would the controller plane need to ensure that information
about a new flow is fully propagated to the entire DetNet domain before
any traffic on that flow starts to flow?

If an attacker knows the 6-tuple used by a DetNet flow, isn't there a
risk that they could use IP-level spoofing to generate traffic that gets
classified as a DetNet flow, potentially causing that flow to exceed its
reservation and get erminated?  This may be a slightly different risk
than the one discussed in the last paragraph as requiring policing at
the input of the DetNet domain.  (This is related to the "source address
spoofing" risk that Bob Briscoe raised.)

  Security considerations for DetNet are described in detail in
  [I-D.ietf-detnet-security].  General security considerations are
  described in [RFC8655].  This section considers exclusively security

side note: the wording of these first two sentences feels a little
strange, as if the two documents should be somehow the same but are not.
Perhaps:

% Detailed security considerations for DetNet are catalogued in
% [I-D.ietf-detnet-security], and a more general (abbreviated) treatment
% is provided in [RFC8655].

Also, it looks like the comments I made on 2020-04-23 regarding
draft-ietf-detnet-security (as a side note in my ballot position on
draft-ietf-detnet-data-plane-framework-04) remain applicable:

% The referenced document (now at -09) seems significantly improved from
% when I previously made an in-passing review of the -03
% (https://mailarchive.ietf.org/arch/msg/detnet/jZLodXBmQa7ZFDbBIvDO_xCDD0E/),
% however, some of the issues I mentioned there remain, at least in part
% (e.g., mentioning the use of HMAC without a colocated discussion of
% the need for key distribution and having a taxonomy of threats titled
% "threat model").

  Security aspects which are unique to DetNet are those whose aim is to
  provide the specific quality of service aspects of DetNet, which are
  primarily to deliver data flows with extremely low packet loss rates
  and bounded end-to-end delivery latency.

I recognize that this is essentially verbatim from RFC 8655, but it
still reads somewhat strangely to me: specifically, it seems to say that
there are "security aspects [...] whose aim is to provide [QoS, low
packet loss, and bounded latency]", and I don't think it's the security
aspects specifically that aim to provide those.  Rather, I think it's
the overall goal of DetNet to provide those attributes, and there are
some security aspepcts specific to attempting to provide those
attributes.

  The primary considerations for the data plane is to maintain
  integrity of data and delivery of the associated DetNet service
  traversing the DetNet network.  Application flows can be protected
  through whatever means is provided by the underlying technology.  For
  example, encryption may be used, such as that provided by IPSec
  [RFC4301] for IP flows and/or by an underlying sub-net using MACSec
  [IEEE802.1AE-2018] for IP over Ethernet (Layer-2) flows.

It's good that you call this out, so thank you for that.
I'd suggest a slight addition, prefacing the sentence that currently
starts with "Application flows" with a lead-in that "Since no
DetNet-specific fields are available for DetNet IP, data integrity must
be provided by a lower (or, potentially, higher) layer; application
flows can [...]".  I'd also consider noting that providing guaranteed
delivery is impossible in the face of a sufficiently powerful attacker
(that can drop all traffic, cut fiber, etc.), so the attacker in the
DetNet threat model is necessarily slightly weaker than a typical BCP 72
threat model.

Section 11.1

The way in which RFC 3473 is used does not seem to require a normative
reference, to me.

(RFC 4301 is perhaps in a similar situation, though given that we need
normative references to 4302 and 4303, it doesn't stick out as much.)

Section 11.2

Was it considered to make draft-ietf-detnet-data-plane-framework a
normative reference?  The reference in Section 3 that says "common data
plane procedures and control information for all DetNet data planes" can
be found in it makes me wonder whether it contains information that I
need to know in order to use detnet-ip properly.

[Ballot comment]
I support some of the other DISCUSS items as well.


[[ recommendations ]]

[ whole document ]

* Given the use of 2-, 3-, 5-, and 6-tuple would it be a readability
  improvement if section 3 rolled them all up in to one more general term,
  like N-tuple?

  Quite possibly I have misunderstood, though.

* Instead of L2, or in the terminology definition of L2, clarify "sub-IP layer"
  so as to avoid concerns about things like "layer 2.5" and handling in other
  future link types?


[[ nits ]]

[ section 3 ]

* "IP DetNet End Systems can communicate over DetNet IP network with
  IP End System"

  The grammar toward the end of the sentence is off.

  "...over DetNet IP networks with other IP End Systems", perhaps?

* "from data plane perspective" -> "from the data plane perspective"

* "discribed" -> "described"

[ section 4.2 ]

* Suggest, maybe, "DN adjacent" instead of "DN attached".

  This use of "attached" seems to stretch to meaning of the word.

[ section 5.1.1.5 ]

* If you feel you want a reference, check out RFC 6437.

[Ballot comment]
I support Alvaro’s DISCUSS points.  Otherwise, just a pile of nits here:

Section 1:

* "... defined to support IP flows, instead ..." -- "instead" should start a new sentence, or at least the comma should be a semi-colon

* "... data plane in Section 3, considerations that ..." -- add "and" before "considerations"

Section 3:

* The parentheses in the second paragraph are unbalanced.

* "Same can be valid for flow aggregates." -- To what does "Same" refer?

* "In such cases using smaller tuples are appropriate." -- s/are/is/

* "... forwarded unmodified, however ..." -- "however" should start a new sentence, or at least the comma should be a semi-colon

* "Note, that Figure 1 and ..." -- remove the comma

* "TSN over MPLS is discribed in ..." -- s/discribed/described/

Section 4.1:

* "... treatment on the connected sub-network, see ..." -- the comma should be a semi-colon, or the references should be in parentheses, etc.

Section 4.2:

* "... the underlying link / sub net specific ..." -- suggest "link/sub-network", if I'm reading the rest of this right (just to match other text, and tighten up the spaces)

* Some places in this section use "end-to-end", some use "end to end".  I'm not sure which is correct, but in any case the document should be consistent.

* "... link / sub-network ..." -- same point as before, twice more

* ""R" and "E" denotes replication ..." -- s/denotes/denote/

Section 4.3.2:

* "... subject of a completed reservation, can disrupt ..." -- remove the comma

* "Remarking packets ..." -- this should be "Re-marking" (two instances)

Section 4.3.3:

* "... when a single 5-tuple application flow experience reordering ..." -- s/experience/experiences/

Section 4.4:

* "... flows can be aggregated using any of the 6-tuple, ..." -- I can't quite parse this.  Do you mean "any subset of the elements of the 6-tuple"?

OLD:
  It is the responsibility of the DetNet controller plane to properly
  provision the use of these aggregation mechanisms.  This includes
  ensuring that aggregated flows have compatible e.g., the same or very
  similar QoS and/or CoS characteristics, see Section 4.3.2.  It also
  includes ensuring that per component-flow service requirements are
  satisfied by the aggregate, see Section 5.3.

NEW:
  It is the responsibility of the DetNet controller plane to properly
  provision the use of these aggregation mechanisms.  This includes
  ensuring that aggregated flows have compatible (e.g., the same or very
  similar) QoS and/or CoS characteristics, per Section 4.3.2.  It also
  includes ensuring that per component-flow service requirements are
  satisfied by the aggregate, per Section 5.3.

Section 5:

* "... Traffic classification, for example ..." -- that should be a semi-colon, or start a new sentence

Section 5.1:

* "Note, that additional ..." -- remove comma

Section 5.1.1.1:

* "... prefix matching for this field, see ..." -- parenthesize the "see" clause, or maybe change "see" to "per"

Section 5.1.1.2:

* Same issue with the tacked-on "see" and references.

* "Note: any IP address ..." -- capitalize "any"

Section 5.1.1.3:

* "Other, non-zero values, MUST be ..." -- remove the commas

Section 6:

* "When used, can be used ..." -- suggest "When used, the field can be used ..."

* "Exact and wildcard matching is required." (two instances) -- suggest "Support for both exact and wildcard matching is required."

Section 7:

* "... through whatever means is provided by the ..." -- s/is/are/

[Ballot discuss]
Several sections mandate actions to be taken where the specific mechanisms are not clearly defined.  This lack of specifics leaves me at a loss about what is being mandated.

Specifically:

(1) §4.3.2 (Quality of Service): "Quality of Service...MUST be provided
    locally by the DetNet-aware hosts and routers supporting DetNet flows. 
    The traffic control mechanisms used to deliver QoS...are expected to be
    defined in a future document."

(2) §5.2 (Forwarding Procedures): "Specifically...SHALL use management and
    control information to select the one or more outgoing interfaces and
    next hops..."  This sentence sounds very generic to me: using management
    and control information is what every forwarder does -- regardless of
    DetNet.  Not only is it a generic statement, but the management and
    control functions are not defined...

(3) §5.3 (DetNet IP Traffic Treatment Procedures): "MUST ensure that a
    DetNet flow receives the traffic treatment that is provisioned for
    it...Typical mechanisms used to provide different treatment to different
    flows includes the allocation of system resources...and provisioning or related parameters...Other mechanisms than the ones used in the TSN case are outside the scope of this document."


It is ok to define the mechanisms in a different document -- but there are no specific references.  What exactly is this document requiring (MUST)?  If there are no specifics on the mechanisms (or where they are defined), how can an implementation comply with this document?  What are the interoperability consequences if not all nodes comply with the same set of (undefined) mechanisms?

I am balloting DISCUSS because I believe that this omission makes the specification incomplete.  Adding details will satisfy my concern.

[Ballot comment]
(1) §4.2 (DetNet Domain-Specific Considerations):

  As a general rule, DetNet IP domains need to be able to forward any
  DetNet flow identified by the IP 6-tuple.  Doing otherwise would
  limit the number of 6-tuple flow ID combinations that could be used
  by the end systems.  From a practical standpoint this means that all
  nodes along the end-to-end path of DetNet flows need to agree on what
  fields are used for flow identification.

There is text in §5.1 requiring the ability to forward based on the 6-tuple...but there is nothing related to the "need to agree on what fields are used for flow identification" -- it seems to me that this agreement should also be required.  §6 does say:

  It is the responsibility of the DetNet controller plane to properly
  provision both flow identification information and the flow specific
  resources needed to provided the traffic treatment needed to meet
  each flow's service requirements.  This applies for aggregated and
  individual flows.

I guess that "to properly provision" can be a standin for the "need to agree on what fields are used".  I would still like to see something about the effect of not agreeing on/provisioning the information correctly/consistently.



(2) §4.3.1 (Class of Service): "...DetNet nodes...MUST ensure that the CoS service classes do not impact the congestion protection and latency control mechanisms used to provide DetNet QoS." 

(a) What enforceable action are the DetNet nodes expected to take to comply with this statement?  What does ensuring include? 

(b) Maybe it's just me, but I would think that the requirement is not at a node level (each node doing something), but within a DetNet domain; IOW, this sounds more like a provisioning requirement (even probably related to the text from §6 I quoted above).



(3) §5.1 (DetNet IP Flow Identification Procedures): s/The configuration and control information used to identify an individual DetNet flow MUST be ordered by an implementation./An implementation MUST support ordering of the configuration and control information used to identify an individual DetNet flow.

The current wording seems to imply that the implementation may order the information any way it wants...but proper identification through the domain depends on consistent ordering.



(4) §5.1.1.3 (IPv4 Protocol and IPv6 Next Header Fields):

  Implementations of this document MUST support DetNet flow
  identification based on the IPv4 Protocol field when processing IPv4
  packets, and the IPv6 Next Header Field when processing IPv6 packets.
  An implementation MUST support flow identification based on the next
  protocol values defined in Section 5.1.2.  Other, non-zero values,
  MUST be used for flow identification. 


The first sentence represents a superset of the second: in general, using the Protocol field includes more options than just what is defined in §5.1.2. 

The third sentence, again, goes back to a superset: anything else except 0.  BTW, 0 is the IPv6 HbH option -- do you really want to exclude it? 

Can that paragraph be summarized by just the first sentence?



(5) "Implementations SHOULD allow for this field to be ignored for a specific DetNet flow."  This sentence, or a "MUST allow" version, are used throughout the document.  Is there a strong reason (that I'm obviously missing) to sometimes use SHOULD and others MUST?



(6) A reference for ICMP is needed.



(7) §5.1.2.2 (ICMP): "Note that ICMP type is not included in the flow definition."  Does this mean that the ICMP type should not (SHOULD NOT/MUST NOT ??) be used in the flow definition?  That's what the text sounds to me as saying.

I found a thread in the archive [1] which talks about this sentence being added with the intention of supporting ICMP types...but even with that added context the text just sounds as if the opposite was intended. 

[1] https://mailarchive.ietf.org/arch/msg/detnet/wVA93y2cO2nt9ddFcDaTw-eHKK8



(8) I believe that these references should be Normative: I-D.ietf-detnet-data-plane-framework and RFC8655.



(9) Editorial nits:

s/uses "6-tuple" based flow identification, where 6-tuple refers to/uses 6-tuple based flow identification, where "6-tuple" refers to

s/6-tuple is (destination/6-tuple is destination

s/Same can be valid/The same can be valid

s/using smaller tuples are appropriate/using smaller tuples is appropriate

s/can communicate over DetNet IP network with IP End System./can communicate over a DetNet IP network with IP End Systems.

s/from data plane perspective/from [a|the] data plane perspective

s/end-system/end system/g

s/multiple methods that MAY be used...including but not limited to/multiple methods that may be used...including but not limited to

s/matching based on this field MUST allow for this field to be ignored/matching based on this field MUST allow for it to be ignored

s/found in the [I-D.ietf-detnet-data-plane-framework]/found in [I-D.ietf-detnet-data-plane-framework]/g

s/provisioning or related parameters/provisioning of related parameters

[Ballot discuss]
A few easy clarifications:

** Section 7.  Per “From a data plane perspective this document does not add or modify any header information”, this statement, which is also found in Section 9.1 of draft-ietf-detnet-security-10 does not seem consistent with Section 3 which states “… however modification of these fields is allowed, for example changing the DSCP value, when required by the DetNet service”.

** Section 7.  RFC8655 reminds us that “Security considerations for DetNet are constrained (compared to, for example, the open Internet) because DetNet is defined to operate only within a single administrative domain”.  However, the only IP-specific guidance on preventing escape from the DetNet domain is in Section 4.2 (“Note that not mixing DetNet and non-DetNet traffic within a single 5-tuple,  as described above, enables simpler 5-tuple filters to be used (or re-used) at the edges of a DetNet network to prevent non-congestion-responsive DetNet traffic from escaping the DetNet domain.”).  Please provide more prescriptive guidance in this section.

** Section 7.  The guidance from RFC8655 and draft-ietf-detnet-security needs to be deconflicted relative to confidentiality.  The following assertions are stated in a single paragraph:

(a) The primary considerations for the data plane is to maintain
  integrity of data and delivery of the associated DetNet service
  traversing the DetNet network. 

(b) Application flows can be protected
  through whatever means is provided by the underlying technology.  For
  example, encryption may be used, such as that provided by IPSec
  [RFC4301] for IP flows and/or by an underlying sub-net using MACSec
  [IEEE802.1AE-2018] for IP over Ethernet (Layer-2) flows.

(a) appears to be a cut-and-paste (or maybe vice versa) from Section 9 of draft-ietf-detnet-security-10

(b) appears to be a cut-and-paste from Section 5 of RFC8655.

The concatenation of (a) + (b) appears to be unique to this document.

When RFC8655 states (b), it prefaced with “[t]o maintain confidentiality of data traversing the DetNet, application flows can be protected through whatever means is provided by the underlying technology.”  (a) makes no references to confidentiality.  It seems like it should.

[Ballot comment]
Thanks for responding to the SECDIR review (and thank you Tero for doing it).

** Section 3.  I wasn’t able to follow how the reference architectures (Figure 1 and 2) in this section had bearing on the normative behavior in Section 5 and 6.

** Section 3. Editorial.  As a reader, I would have benefited from a forward reference to Section 5 somewhere in this section.  As I was reading this text, I kept looking for specify in exactly which fields go into the tuple and under what circumstances.

** Section 3.  Per “Same can be valid for flow aggregates”, I didn’t follow what this meant.  Did you mean, “The same can be true for flow aggregates”, editorially? But I’m still not sure what a “flow aggregates” is in this case.

** Section 3.  Per “… however modification of these fields is allowed, for example changing the DSCP value, when required by the DetNet service”, is the DSCP the only field that is permitted to be modified?  Perhaps I missed it, but I didn’t see this behavior covered in the subsequent guidance (i.e., outside of this overview) -- see related DISCUSS above.

** Section 4.  Per “This section provides informative considerations …”, is that the same thing as saying this entire section is not normative?  If so, I was surprised by the use of RFC2119 language in this section.

** Section 4.2.  Per “Note that not mixing DetNet and non-DetNet traffic within a single 5-tuple”, how does one do flow identification if such mixing is done?

** Section 4.3.1.  Is there a pointer that can be provided to explain how DetNet nodes are to “ensure that the CoS service classes do not impact the congestion protection and latency control mechanisms used to provide DetNet QoS?”

** Section 5.1.2.2.  Per “DetNet flow identification for ICMP is achieved based on the protocol’s header”, I recommend being precise by explicitly saying which protocol header field and which value (just as was done in for TCP, UDP and IPSec.).

** Section 7.  It wasn’t clear to me which security consideration mentioned here were specific to a DetNet data plane when IP is used for the forwarding sub-layer.  I have no issues restating key considerations, but this write-up was generic.

[Ballot comment]
Just a pile of nits here:

Section 1:

* "... defined to support IP flows, instead ..." -- "instead" should start a new sentence, or at least the comma should be a semi-colon

* "... data plane in Section 3, considerations that ..." -- add "and" before "considerations"

Section 3:

* The parentheses in the second paragraph are unbalanced.

* "Same can be valid for flow aggregates." -- To what does "Same" refer?

* "In such cases using smaller tuples are appropriate." -- s/are/is/

* "... forwarded unmodified, however ..." -- "however" should start a new sentence, or at least the comma should be a semi-colon

* "Note, that Figure 1 and ..." -- remove the comma

* "TSN over MPLS is discribed in ..." -- s/discribed/described/

Section 4.1:

* "... treatment on the connected sub-network, see ..." -- the comma should be a semi-colon, or the references should be in parentheses, etc.

Section 4.2:

* "... the underlying link / sub net specific ..." -- suggest "link/sub-network", if I'm reading the rest of this right (just to match other text, and tighten up the spaces)

* Some places in this section use "end-to-end", some use "end to end".  I'm not sure which is correct, but in any case the document should be consistent.

* "... link / sub-network ..." -- same point as before, twice more

* ""R" and "E" denotes replication ..." -- s/denotes/denote/

Section 4.3.2:

* "... subject of a completed reservation, can disrupt ..." -- remove the comma

* "Remarking packets ..." -- this should be "Re-marking" (two instances)

Section 4.3.3:

* "... when a single 5-tuple application flow experience reordering ..." -- s/experience/experiences/

Section 4.4:

* "... flows can be aggregated using any of the 6-tuple, ..." -- I can't quite parse this.  Do you mean "any subset of the elements of the 6-tuple"?

OLD:
  It is the responsibility of the DetNet controller plane to properly
  provision the use of these aggregation mechanisms.  This includes
  ensuring that aggregated flows have compatible e.g., the same or very
  similar QoS and/or CoS characteristics, see Section 4.3.2.  It also
  includes ensuring that per component-flow service requirements are
  satisfied by the aggregate, see Section 5.3.

NEW:
  It is the responsibility of the DetNet controller plane to properly
  provision the use of these aggregation mechanisms.  This includes
  ensuring that aggregated flows have compatible (e.g., the same or very
  similar) QoS and/or CoS characteristics, per Section 4.3.2.  It also
  includes ensuring that per component-flow service requirements are
  satisfied by the aggregate, per Section 5.3.

Section 5:

* "... Traffic classification, for example ..." -- that should be a semi-colon, or start a new sentence

Section 5.1:

* "Note, that additional ..." -- remove comma

Section 5.1.1.1:

* "... prefix matching for this field, see ..." -- parenthesize the "see" clause, or maybe change "see" to "per"

Section 5.1.1.2:

* Same issue with the tacked-on "see" and references.

* "Note: any IP address ..." -- capitalize "any"

Section 5.1.1.3:

* "Other, non-zero values, MUST be ..." -- remove the commas

Section 6:

* "When used, can be used ..." -- suggest "When used, the field can be used ..."

* "Exact and wildcard matching is required." (two instances) -- suggest "Support for both exact and wildcard matching is required."

Section 7:

* "... through whatever means is provided by the ..." -- s/is/are/

[Ballot comment]
Just a pile of nits here:

Section 1:
* "... defined to support IP flows, instead ..." -- "instead" should start a new sentence, or at least the comma should be a semi-colon
* "... data plane in Section 3, considerations that ..." -- add "and" before "considerations"

Section 3:
* The parentheses in the second paragraph are unbalanced.
* "Same can be valid for flow aggregates." -- To what does "Same" refer?
* "In such cases using smaller tuples are appropriate." -- s/are/is/
* "... forwarded unmodified, however ..." -- "however" should start a new sentence, or at least the comma should be a semi-colon
* "Note, that Figure 1 and ..." -- remove the comma
* "TSN over MPLS is discribed in ..." -- s/discribed/described/

Section 4.1:
* "... treatment on the connected sub-network, see ..." -- the comma should be a semi-colon, or the references should be in parentheses, etc.

Section 4.2:
* "... the underlying link / sub net specific ..." -- suggest "link/sub-network", if I'm reading the rest of this right (just to match other text, and tighten up the spaces)
* Some places in this section use "end-to-end", some use "end to end".  I'm not sure which is correct, but in any case the document should be consistent.
* "... link / sub-network ..." -- same point as before, twice more
* ""R" and "E" denotes replication ..." -- s/denotes/denote/

Section 4.3.2:
* "... subject of a completed reservation, can disrupt ..." -- remove the comma
* "Remarking packets ..." -- this should be "Re-marking" (two instances)

Section 4.3.3:
* "... when a single 5-tuple application flow experience reordering ..." -- s/experience/experiences/

Section 4.4:
* "... flows can be aggregated using any of the 6-tuple, ..." -- I can't quite parse this.  Do you mean "any subset of the elements of the 6-tuple"?
OLD:
  It is the responsibility of the DetNet controller plane to properly
  provision the use of these aggregation mechanisms.  This includes
  ensuring that aggregated flows have compatible e.g., the same or very
  similar QoS and/or CoS characteristics, see Section 4.3.2.  It also
  includes ensuring that per component-flow service requirements are
  satisfied by the aggregate, see Section 5.3.
NEW:
  It is the responsibility of the DetNet controller plane to properly
  provision the use of these aggregation mechanisms.  This includes
  ensuring that aggregated flows have compatible (e.g., the same or very
  similar) QoS and/or CoS characteristics, per Section 4.3.2.  It also
  includes ensuring that per component-flow service requirements are
  satisfied by the aggregate, per Section 5.3.

Section 5:
* "... Traffic classification, for example ..." -- that should be a semi-colon, or start a new sentence

Section 5.1:
* "Note, that additional ..." -- remove comma

Section 5.1.1.1:
* "... prefix matching for this field, see ..." -- parenthesize the "see" clause, or maybe change "see" to "per"

Section 5.1.1.2:
* Same issue with the tacked-on "see" and references.
* "Note: any IP address ..." -- capitalize "any"

Section 5.1.1.3:
* "Other, non-zero values, MUST be ..." -- remove the commas

Section 6:
* "When used, can be used ..." -- suggest "When used, the field can be used ..."
* "Exact and wildcard matching is required." (two instances) -- suggest "Support for both exact and wildcard matching is required."

Section 7:
* "... through whatever means is provided by the ..." -- s/is/are/

[Ballot comment]
Thank you for addressing most of the extensive tsvart comments.

Sec 3 says DetNet might alter the DSCPs. Sec 7 says “ From a data plane perspective this document does not add or modify any header information.” These appear to be in contradiction.

Sec 4.1 “In order to maximize reuse of existing mechanisms, DetNet-aware
  applications and end systems SHOULD NOT mix DetNet and non-DetNet
  traffic within a single 5-tuple.“

I don’t understand this. What’s the point of having a 6-tuple if you can’t keep 5 constant and vary the DSCP?

Sec 5.2 discourages the use of “multiple paths.” But Figure 4 clearly shows packets taking multiple paths to the destination.

Nit:
Sec 5.1 s/end systems/end system

Request for posting confirmation emailed to previous authors: Stewart Bryant , Lou Berger , Janos Farkas , Andrew Malis , Balazs Varga , Don Fedyk , detnet-chairs@ietf.org

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-detnet-ip-05, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2020-03-13):

From: The IESG
To: IETF-Announce
CC: detnet@ietf.org, db3546@att.com, eagros@dolby.com, Ethan Grossman , draft-ietf-detnet-ip@ietf.org, detnet-chairs@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (DetNet Data Plane: IP) to Proposed Standard


The IESG has received a request from the Deterministic Networking WG (detnet)
to consider the following document: - 'DetNet Data Plane: IP'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2020-03-13. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document specifies the Deterministic Networking data plane when
  operating in an IP packet switched network.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-detnet-ip/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-detnet-ip/ballot/


No IPR declarations have been submitted directly on this I-D.

Request for posting confirmation emailed to previous authors: Balazs Varga , Lou Berger , Stewart Bryant , Janos Farkas , Don Fedyk , Jouni Korhonen , Andrew Malis , detnet-chairs@ietf.org

> As required by RFC 4858, this is the current template for the Document
> Shepherd Write-Up.
>
> Changes are expected over time. This version is dated 24 February 2012.
>
> (1) What type of RFC is being requested (BCP, Proposed Standard,
> Internet Standard, Informational, Experimental, or Historic)?

Proposed Standard

> Why is this the proper type of RFC?

This document normatively specifies the use of IP to provide DetNet data plane service. 

> Is this type of RFC indicated in the title page header?

Yes

>
> (2) The IESG approval announcement includes a Document Announcement
> Write-Up. Please provide such a Document Announcement Write-Up. Recent
> examples can be found in the "Action" announcements for approved
> documents. The approval announcement contains the following sections:
>
> Technical Summary
>
>  Relevant content can frequently be found in the abstract
>  and/or introduction of the document. If not, this may be
>  an indication that there are deficiencies in the abstract
>  or introduction.
This document specifies the DetNet data plane operation for IP hosts and routers that provide DetNet service to IP encapsulated data.  No DetNet-specific encapsulation is defined to support IP flows; instead, the existing IP and higher layer protocol header information is used to support flow identification and DetNet service delivery.  Procedures and control information that is common to all DetNet data planes can be found in ietf-detnet-data-plane-framework.
> Working Group Summary
>
>  Was there anything in WG process that is worth noting? For
>  example, was there controversy about particular points or
>  were there decisions where the consensus was particularly
>  rough?
There were many technical debates in the process of creating this draft, but all were resolved with a clear consensus. It took awhile to get there but there is nothing worth noting.
> Document Quality
>
>  Are there existing implementations of the protocol?

The IPv4 and IPv6 protocols are used without modification. At this time there are no shipping implementations of DetNet per se.

> Have a significant number of vendors indicated their plan to
>  implement the specification?

Several major vendors have been core to the development of DetNet, including Cisco, Huawei, and Ericsson so it is assumed that they plan to implement it.

> Are there any reviewers that
>  merit special mention as having done a thorough review,
>  e.g., one that resulted in important changes or a
>  conclusion that the document had no substantive issues? If
>  there was a MIB Doctor, Media Type or other expert review,
>  what was its course (briefly)? In the case of a Media Type
>  review, on what date was the request posted?

The DetNet WG (including David Black, DetNet Technical Advisor) have made extensive reviews of the present drafts.
A dedicated Data Plane Design team have met informally, regularly, to review and progress the set of data plane drafts.
Preceding the WG decisions to use IP and MPLS for the DetNet Data Plane, an extensive review of candidate technologies was done by Jouni Korhonen and team (draft-ietf-detnet-dp-alt).

> Personnel
>
>  Who is the Document Shepherd?
Ethan Grossman

> Who is the Responsible Area Director?
Deborah Brungard

>
> (3) Briefly describe the review of this document that was performed by
> the Document Shepherd.  If this version of the document is not ready
> for publication, please explain why the document is being forwarded to
> the IESG.
>

I have reread this document as it progressed as well as in its final form, and have personally contributed a number of suggestions, mostly grammatical details.  All significant comments have been addressed. The document is ready for publication.

> (4) Does the document Shepherd have any concerns about the depth or
> breadth of the reviews that have been performed?

No.

> (5) Do portions of the document need review from a particular or from
> broader perspective, e.g., security, operational complexity, AAA, DNS,
> DHCP, XML, or internationalization? If so, describe the review that
> took place.
The draft was reviewed in detail by David Black with respect to backwards compatibility with Diffserv. All issues were resolved.

> (6) Describe any specific concerns or issues that the Document Shepherd
> has with this document that the Responsible Area Director and/or the
> IESG should be aware of? For example, perhaps he or she is uncomfortable
> with certain parts of the document, or has concerns whether there really
> is a need for it. In any event, if the WG has discussed those issues and
> has indicated that it still wishes to advance the document, detail those
> concerns here.

No concerns. The progress of this draft has been quite linear, and it is ready to be published.

Regarding the number of authors of this draft, this draft is one of a group that represents a substantial part of the output of the WG for a number of years. We realize that the author count is intended to be 5 or less however we have carefully reviewed the author counts of these drafts at the time of WG LC to validate the contributions, and we sincerely believe that it would not be fair to remove any of the listed authors.

> (7) Has each author confirmed that any and all appropriate IPR
> disclosures required for full conformance with the provisions of BCP 78
> and BCP 79 have already been filed. If not, explain why.

Yes, authors/contributors know of none, see
https://mailarchive.ietf.org/arch/msg/detnet/BI3lMBkzr2pebC__kb-eqVU-yEg

> (8) Has an IPR disclosure been filed that references this document?
> If so, summarize any WG discussion and conclusion regarding the IPR
> disclosures.
>

There were no IPR concerns raised during WG acceptance of the document, nor during the period of its development.
This is a link to the IPR call results:
https://mailarchive.ietf.org/arch/msg/detnet/BI3lMBkzr2pebC__kb-eqVU-yEg

> (9) How solid is the WG consensus behind this document? Does it
> represent the strong concurrence of a few individuals, with others
> being silent, or does the WG as a whole understand and agree with it?

Very solid.  The document (in the context of the full set of DetNet Data Plane drafts) is mature and has been discussed sufficiently among the broad DetNet WG audience.

> (10) Has anyone threatened an appeal or otherwise indicated extreme
> discontent? If so, please summarize the areas of conflict in separate
> email messages to the Responsible Area Director. (It should be in a
> separate email because this questionnaire is publicly available.)
>

No.

> (11) Identify any ID nits the Document Shepherd has found in this
> document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
> Checklist). Boilerplate checks are not enough; this check needs to be
> thorough.

IDNits passes without errors.
There are idnits warnings regarding "outdated references" but this is because this is one of a set of drafts that refer to each other and will all be published together, so the RFC editor can fix this once all edits are final. 
There is also a warning "Missing Reference: 'Network' is mentioned on line 174, but not defined" - however, what Idnits is finding is the text  “[Network]” in the figure text (which is part of a diagram) and looking for a corresponding reference, which makes no sense, i.e. this is due to a shortcoming of idnits, not the draft.

> (12) Describe how the document meets any required formal review
> criteria, such as the MIB Doctor, media type, and URI type reviews.
>

N/A

> (13) Have all references within this document been identified as
> either normative or informative?
>

Yes

> (14) Are there normative references to documents that are not ready for
> advancement or are otherwise in an unclear state?

No.

> If such normative references exist, what is the plan for their completion?

N/A.

> (15) Are there downward normative references references (see RFC 3967)?
> If so, list these downward references to support the Area Director in
> the Last Call procedure.

There is currently a downref for RFC 2475 but presumably that will be moved to Informative, or discussed here.
// No, N/A.

> (16) Will publication of this document change the status of any
> existing RFCs? Are those RFCs listed on the title page header, listed
> in the abstract, and discussed in the introduction? If the RFCs are not
> listed in the Abstract and Introduction, explain why, and point to the
> part of the document where the relationship of this document to the
> other RFCs is discussed. If this information is not in the document,
> explain why the WG considers it unnecessary.

No, N/A.

> (17) Describe the Document Shepherd's review of the IANA considerations
> section, especially with regard to its consistency with the body of the
> document. Confirm that all protocol extensions that the document makes
> are associated with the appropriate reservations in IANA registries.
> Confirm that any referenced IANA registries have been clearly
> identified. Confirm that newly created IANA registries include a
> detailed specification of the initial contents for the registry, that
> allocations procedures for future registrations are defined, and a
> reasonable name for the new registry has been suggested (see RFC 5226).

N/A, no IANA requests.

>
> (18) List any new IANA registries that require Expert Review for future
> allocations. Provide any public guidance that the IESG would find
> useful in selecting the IANA Experts for these new registries.

None.

>
> (19) Describe reviews and automated checks performed by the Document
> Shepherd to validate sections of the document written in a formal
> language, such as XML code, BNF rules, MIB definitions, etc.
>

The only automated review was idnits.

> As required by RFC 4858, this is the current template for the Document
> Shepherd Write-Up.
>
> Changes are expected over time. This version is dated 24 February 2012.
>
> (1) What type of RFC is being requested (BCP, Proposed Standard,
> Internet Standard, Informational, Experimental, or Historic)?

Proposed Standard

> Why is this the proper type of RFC?

This document normatively specifies the use of IP to provide DetNet data plane service. 

> Is this type of RFC indicated in the title page header?

Yes

>
> (2) The IESG approval announcement includes a Document Announcement
> Write-Up. Please provide such a Document Announcement Write-Up. Recent
> examples can be found in the "Action" announcements for approved
> documents. The approval announcement contains the following sections:
>
> Technical Summary
>
>  Relevant content can frequently be found in the abstract
>  and/or introduction of the document. If not, this may be
>  an indication that there are deficiencies in the abstract
>  or introduction.
This document specifies the DetNet data plane operation for IP hosts and routers that provide DetNet service to IP encapsulated data.  No DetNet-specific encapsulation is defined to support IP flows; instead, the existing IP and higher layer protocol header information is used to support flow identification and DetNet service delivery.  Procedures and control information that is common to all DetNet data planes can be found in ietf-detnet-data-plane-framework.
> Working Group Summary
>
>  Was there anything in WG process that is worth noting? For
>  example, was there controversy about particular points or
>  were there decisions where the consensus was particularly
>  rough?
There were many technical debates in the process of creating this draft, but all were resolved with a clear consensus. It took awhile to get there but there is nothing worth noting.
> Document Quality
>
>  Are there existing implementations of the protocol?

The IPv4 and IPv6 protocols are used without modification. At this time there are no shipping implementations of DetNet per se.

> Have a significant number of vendors indicated their plan to
>  implement the specification?

Several major vendors have been core to the development of DetNet, including Cisco, Huawei, and Ericsson so it is assumed that they plan to implement it.

> Are there any reviewers that
>  merit special mention as having done a thorough review,
>  e.g., one that resulted in important changes or a
>  conclusion that the document had no substantive issues? If
>  there was a MIB Doctor, Media Type or other expert review,
>  what was its course (briefly)? In the case of a Media Type
>  review, on what date was the request posted?

The DetNet WG (including David Black, DetNet Technical Advisor) have made extensive reviews of the present drafts.
A dedicated Data Plane Design team have met informally, regularly, to review and progress the set of data plane drafts.
Preceding the WG decisions to use IP and MPLS for the DetNet Data Plane, an extensive review of candidate technologies was done by Jouni Korhonen and team (draft-ietf-detnet-dp-alt).

> Personnel
>
>  Who is the Document Shepherd?
Ethan Grossman

> Who is the Responsible Area Director?
Deborah Brungard

>
> (3) Briefly describe the review of this document that was performed by
> the Document Shepherd.  If this version of the document is not ready
> for publication, please explain why the document is being forwarded to
> the IESG.
>

I have reread this document as it progressed as well as in its final form, and have personally contributed a number of suggestions, mostly grammatical details.  All significant comments have been addressed. The document is ready for publication.

> (4) Does the document Shepherd have any concerns about the depth or
> breadth of the reviews that have been performed?

No.

> (5) Do portions of the document need review from a particular or from
> broader perspective, e.g., security, operational complexity, AAA, DNS,
> DHCP, XML, or internationalization? If so, describe the review that
> took place.
The draft was reviewed in detail by David Black with respect to backwards compatibility with Diffserv. All issues were resolved.

> (6) Describe any specific concerns or issues that the Document Shepherd
> has with this document that the Responsible Area Director and/or the
> IESG should be aware of? For example, perhaps he or she is uncomfortable
> with certain parts of the document, or has concerns whether there really
> is a need for it. In any event, if the WG has discussed those issues and
> has indicated that it still wishes to advance the document, detail those
> concerns here.

No concerns.  This document is ready to be published.

> (7) Has each author confirmed that any and all appropriate IPR
> disclosures required for full conformance with the provisions of BCP 78
> and BCP 79 have already been filed. If not, explain why.

Yes, authors/contributors know of none, see
https://mailarchive.ietf.org/arch/msg/detnet/BI3lMBkzr2pebC__kb-eqVU-yEg

> (8) Has an IPR disclosure been filed that references this document?
> If so, summarize any WG discussion and conclusion regarding the IPR
> disclosures.
>

There were no IPR concerns raised during WG acceptance of the document, nor during the period of its development.
This is a link to the IPR call results:
https://mailarchive.ietf.org/arch/msg/detnet/BI3lMBkzr2pebC__kb-eqVU-yEg

> (9) How solid is the WG consensus behind this document? Does it
> represent the strong concurrence of a few individuals, with others
> being silent, or does the WG as a whole understand and agree with it?

Very solid.  The document (in the context of the full set of DetNet Data Plane drafts) is mature and has been discussed sufficiently among the broad DetNet WG audience.

> (10) Has anyone threatened an appeal or otherwise indicated extreme
> discontent? If so, please summarize the areas of conflict in separate
> email messages to the Responsible Area Director. (It should be in a
> separate email because this questionnaire is publicly available.)
>

No.

> (11) Identify any ID nits the Document Shepherd has found in this
> document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
> Checklist). Boilerplate checks are not enough; this check needs to be
> thorough.

IDNits passes without errors.
There are idnits warnings regarding "outdated references" but this is because this is one of a set of drafts that refer to each other and will all be published together, so the RFC editor can fix this once all edits are final. 
There is also a warning "Missing Reference: 'Network' is mentioned on line 174, but not defined" - however, what Idnits is finding is the text  “[Network]” in the figure text (which is part of a diagram) and looking for a corresponding reference, which makes no sense, i.e. this is due to a shortcoming of idnits, not the draft.

> (12) Describe how the document meets any required formal review
> criteria, such as the MIB Doctor, media type, and URI type reviews.
>

N/A

> (13) Have all references within this document been identified as
> either normative or informative?
>

Yes

> (14) Are there normative references to documents that are not ready for
> advancement or are otherwise in an unclear state?

No.

> If such normative references exist, what is the plan for their completion?

N/A.

> (15) Are there downward normative references references (see RFC 3967)?
> If so, list these downward references to support the Area Director in
> the Last Call procedure.

There is currently a downref for RFC 2475 but presumably that will be moved to Informative, or discussed here.
// No, N/A.

> (16) Will publication of this document change the status of any
> existing RFCs? Are those RFCs listed on the title page header, listed
> in the abstract, and discussed in the introduction? If the RFCs are not
> listed in the Abstract and Introduction, explain why, and point to the
> part of the document where the relationship of this document to the
> other RFCs is discussed. If this information is not in the document,
> explain why the WG considers it unnecessary.

No, N/A.

> (17) Describe the Document Shepherd's review of the IANA considerations
> section, especially with regard to its consistency with the body of the
> document. Confirm that all protocol extensions that the document makes
> are associated with the appropriate reservations in IANA registries.
> Confirm that any referenced IANA registries have been clearly
> identified. Confirm that newly created IANA registries include a
> detailed specification of the initial contents for the registry, that
> allocations procedures for future registrations are defined, and a
> reasonable name for the new registry has been suggested (see RFC 5226).

N/A, no IANA requests.

>
> (18) List any new IANA registries that require Expert Review for future
> allocations. Provide any public guidance that the IESG would find
> useful in selecting the IANA Experts for these new registries.

None.

>
> (19) Describe reviews and automated checks performed by the Document
> Shepherd to validate sections of the document written in a formal
> language, such as XML code, BNF rules, MIB definitions, etc.
>

The only automated review was idnits.

> As required by RFC 4858, this is the current template for the Document
> Shepherd Write-Up.
>
> Changes are expected over time. This version is dated 24 February 2012.
>
> (1) What type of RFC is being requested (BCP, Proposed Standard,
> Internet Standard, Informational, Experimental, or Historic)?

Proposed Standard

> Why is this the proper type of RFC?

This document normatively specifies the use of IP to provide DetNet data plane service. 

> Is this type of RFC indicated in the title page header?

Yes

>
> (2) The IESG approval announcement includes a Document Announcement
> Write-Up. Please provide such a Document Announcement Write-Up. Recent
> examples can be found in the "Action" announcements for approved
> documents. The approval announcement contains the following sections:
>
> Technical Summary
>
>  Relevant content can frequently be found in the abstract
>  and/or introduction of the document. If not, this may be
>  an indication that there are deficiencies in the abstract
>  or introduction.
This document specifies the DetNet data plane operation for IP hosts and routers that provide DetNet service to IP encapsulated data.  No DetNet-specific encapsulation is defined to support IP flows; instead, the existing IP and higher layer protocol header information is used to support flow identification and DetNet service delivery.  Procedures and control information that is common to all DetNet data planes can be found in ietf-detnet-data-plane-framework.
> Working Group Summary
>
>  Was there anything in WG process that is worth noting? For
>  example, was there controversy about particular points or
>  were there decisions where the consensus was particularly
>  rough?
There were many technical debates in the process of creating this draft, but all were resolved with a clear consensus. It took awhile to get there but there is nothing worth noting.
> Document Quality
>
>  Are there existing implementations of the protocol?

The IPv4 and IPv6 protocols are used without modification. At this time there are no shipping implementations of DetNet per se.

> Have a significant number of vendors indicated their plan to
>  implement the specification?

Several major vendors have been core to the development of DetNet, including Cisco, Huawei, and Ericsson so it is assumed that they plan to implement it.

> Are there any reviewers that
>  merit special mention as having done a thorough review,
>  e.g., one that resulted in important changes or a
>  conclusion that the document had no substantive issues? If
>  there was a MIB Doctor, Media Type or other expert review,
>  what was its course (briefly)? In the case of a Media Type
>  review, on what date was the request posted?

The DetNet WG (including David Black, DetNet Technical Advisor) have made extensive reviews of the present drafts.
A dedicated Data Plane Design team have met informally, regularly, to review and progress the set of data plane drafts.
Preceding the WG decisions to use IP and MPLS for the DetNet Data Plane, an extensive review of candidate technologies was done by Jouni Korhonen and team (draft-ietf-detnet-dp-alt).

> Personnel
>
>  Who is the Document Shepherd?
Ethan Grossman

> Who is the Responsible Area Director?
Deborah Brungard

>
> (3) Briefly describe the review of this document that was performed by
> the Document Shepherd.  If this version of the document is not ready
> for publication, please explain why the document is being forwarded to
> the IESG.
>

I have reread this document as it progressed as well as in its final form, and have personally contributed a number of suggestions, mostly grammatical details.  All significant comments have been addressed. The document is ready for publication.

> (4) Does the document Shepherd have any concerns about the depth or
> breadth of the reviews that have been performed?

No.

> (5) Do portions of the document need review from a particular or from
> broader perspective, e.g., security, operational complexity, AAA, DNS,
> DHCP, XML, or internationalization? If so, describe the review that
> took place.
The draft was reviewed in detail by David Black with respect to backwards compatibility with Diffserv. All issues were resolved.

> (6) Describe any specific concerns or issues that the Document Shepherd
> has with this document that the Responsible Area Director and/or the
> IESG should be aware of? For example, perhaps he or she is uncomfortable
> with certain parts of the document, or has concerns whether there really
> is a need for it. In any event, if the WG has discussed those issues and
> has indicated that it still wishes to advance the document, detail those
> concerns here.

No concerns.  This document is ready to be published.

> (7) Has each author confirmed that any and all appropriate IPR
> disclosures required for full conformance with the provisions of BCP 78
> and BCP 79 have already been filed. If not, explain why.

Yes, authors/contributors know of none, see
https://mailarchive.ietf.org/arch/msg/detnet/BI3lMBkzr2pebC__kb-eqVU-yEg

> (8) Has an IPR disclosure been filed that references this document?
> If so, summarize any WG discussion and conclusion regarding the IPR
> disclosures.
>

There were no IPR concerns raised during WG acceptance of the document, nor during the period of its development.
This is a link to the IPR call results:
https://mailarchive.ietf.org/arch/msg/detnet/BI3lMBkzr2pebC__kb-eqVU-yEg

> (9) How solid is the WG consensus behind this document? Does it
> represent the strong concurrence of a few individuals, with others
> being silent, or does the WG as a whole understand and agree with it?

Very solid.  The document (in the context of the full set of DetNet Data Plane drafts) is mature and has been discussed sufficiently among the broad DetNet WG audience.

> (10) Has anyone threatened an appeal or otherwise indicated extreme
> discontent? If so, please summarize the areas of conflict in separate
> email messages to the Responsible Area Director. (It should be in a
> separate email because this questionnaire is publicly available.)
>

No.

> (11) Identify any ID nits the Document Shepherd has found in this
> document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
> Checklist). Boilerplate checks are not enough; this check needs to be
> thorough.

IDNits passes without errors.
There are idnits warnings regarding "outdated references" but this is because this is one of a set of drafts that refer to each other and will all be published together, so the RFC editor can fix this once all edits are final. 
There is also a warning "Missing Reference: 'Network' is mentioned on line 174, but not defined" - however, what Idnits is finding is the text  “[Network]” in the figure text (which is part of a diagram) and looking for a corresponding reference, which makes no sense, i.e. this is due to a shortcoming of idnits, not the draft.

> (12) Describe how the document meets any required formal review
> criteria, such as the MIB Doctor, media type, and URI type reviews.
>

N/A

> (13) Have all references within this document been identified as
> either normative or informative?
>

Yes

> (14) Are there normative references to documents that are not ready for
> advancement or are otherwise in an unclear state?

No.

> If such normative references exist, what is the plan for their completion?

N/A.

> (15) Are there downward normative references references (see RFC 3967)?
> If so, list these downward references to support the Area Director in
> the Last Call procedure.

There is currently a downref for RFC 2475 but presumably that will be moved to Informative, or discussed here.
// No, N/A.

> (16) Will publication of this document change the status of any
> existing RFCs? Are those RFCs listed on the title page header, listed
> in the abstract, and discussed in the introduction? If the RFCs are not
> listed in the Abstract and Introduction, explain why, and point to the
> part of the document where the relationship of this document to the
> other RFCs is discussed. If this information is not in the document,
> explain why the WG considers it unnecessary.

No, N/A.

> (17) Describe the Document Shepherd's review of the IANA considerations
> section, especially with regard to its consistency with the body of the
> document. Confirm that all protocol extensions that the document makes
> are associated with the appropriate reservations in IANA registries.
> Confirm that any referenced IANA registries have been clearly
> identified. Confirm that newly created IANA registries include a
> detailed specification of the initial contents for the registry, that
> allocations procedures for future registrations are defined, and a
> reasonable name for the new registry has been suggested (see RFC 5226).

N/A, no IANA requests.

>
> (18) List any new IANA registries that require Expert Review for future
> allocations. Provide any public guidance that the IESG would find
> useful in selecting the IANA Experts for these new registries.

None.

>
> (19) Describe reviews and automated checks performed by the Document
> Shepherd to validate sections of the document written in a formal
> language, such as XML code, BNF rules, MIB definitions, etc.
>

The only automated review was idnits.

> As required by RFC 4858, this is the current template for the Document
> Shepherd Write-Up.
>
> Changes are expected over time. This version is dated 24 February 2012.
>
> (1) What type of RFC is being requested (BCP, Proposed Standard,
> Internet Standard, Informational, Experimental, or Historic)?

Proposed Standard

> Why is this the proper type of RFC?

This document normatively specifies the use of IP to provide DetNet data plane service. 

> Is this type of RFC indicated in the title page header?

Yes

>
> (2) The IESG approval announcement includes a Document Announcement
> Write-Up. Please provide such a Document Announcement Write-Up. Recent
> examples can be found in the "Action" announcements for approved
> documents. The approval announcement contains the following sections:
>
> Technical Summary
>
>  Relevant content can frequently be found in the abstract
>  and/or introduction of the document. If not, this may be
>  an indication that there are deficiencies in the abstract
>  or introduction.
This document specifies the DetNet data plane operation for IP hosts and routers that provide DetNet service to IP encapsulated data.  No DetNet-specific encapsulation is defined to support IP flows; instead, the existing IP and higher layer protocol header information is used to support flow identification and DetNet service delivery.  Procedures and control information that is common to all DetNet data planes can be found in ietf-detnet-data-plane-framework.
> Working Group Summary
>
>  Was there anything in WG process that is worth noting? For
>  example, was there controversy about particular points or
>  were there decisions where the consensus was particularly
>  rough?
There were many technical debates in the process of creating this draft, but all were resolved with a clear consensus. It took awhile to get there but there is nothing worth noting.
> Document Quality
>
>  Are there existing implementations of the protocol?

The IPv4 and IPv6 protocols are used without modification. At this time there are no shipping implementations of DetNet per se.

> Have a significant number of vendors indicated their plan to
>  implement the specification?

Several major vendors have been core to the development of DetNet, including Cisco, Huawei, and Ericsson so it is assumed that they plan to implement it.

> Are there any reviewers that
>  merit special mention as having done a thorough review,
>  e.g., one that resulted in important changes or a
>  conclusion that the document had no substantive issues? If
>  there was a MIB Doctor, Media Type or other expert review,
>  what was its course (briefly)? In the case of a Media Type
>  review, on what date was the request posted?

The DetNet WG (including David Black, DetNet Technical Advisor) have made extensive reviews of the present drafts.
A dedicated Data Plane Design team have met informally, regularly, to review and progress the set of data plane drafts.
Preceding the WG decisions to use IP and MPLS for the DetNet Data Plane, an extensive review of candidate technologies was done by Jouni Korhonen and team (draft-ietf-detnet-dp-alt).

> Personnel
>
>  Who is the Document Shepherd?
Ethan Grossman

> Who is the Responsible Area Director?
Deborah Brungard

>
> (3) Briefly describe the review of this document that was performed by
> the Document Shepherd.  If this version of the document is not ready
> for publication, please explain why the document is being forwarded to
> the IESG.
>

I have reread this document as it progressed as well as in its final form, and have personally contributed a number of suggestions, mostly grammatical details.  All significant comments have been addressed. The document is ready for publication.

> (4) Does the document Shepherd have any concerns about the depth or
> breadth of the reviews that have been performed?

No.

> (5) Do portions of the document need review from a particular or from
> broader perspective, e.g., security, operational complexity, AAA, DNS,
> DHCP, XML, or internationalization? If so, describe the review that
> took place.
The draft was reviewed in detail by David Black with respect to backwards compatibility with Diffserv. All issues were resolved.

> (6) Describe any specific concerns or issues that the Document Shepherd
> has with this document that the Responsible Area Director and/or the
> IESG should be aware of? For example, perhaps he or she is uncomfortable
> with certain parts of the document, or has concerns whether there really
> is a need for it. In any event, if the WG has discussed those issues and
> has indicated that it still wishes to advance the document, detail those
> concerns here.

No concerns.  This document is ready to be published.

> (7) Has each author confirmed that any and all appropriate IPR
> disclosures required for full conformance with the provisions of BCP 78
> and BCP 79 have already been filed. If not, explain why.

Yes, authors/contributors know of none, see
https://mailarchive.ietf.org/arch/msg/detnet/BI3lMBkzr2pebC__kb-eqVU-yEg

> (8) Has an IPR disclosure been filed that references this document?
> If so, summarize any WG discussion and conclusion regarding the IPR
> disclosures.
>

There were no IPR concerns raised during WG acceptance of the document, nor during the period of its development.
This is a link to the IPR call results:
https://mailarchive.ietf.org/arch/msg/detnet/BI3lMBkzr2pebC__kb-eqVU-yEg

> (9) How solid is the WG consensus behind this document? Does it
> represent the strong concurrence of a few individuals, with others
> being silent, or does the WG as a whole understand and agree with it?

Very solid.  The document (in the context of the full set of DetNet Data Plane drafts) is mature and has been discussed sufficiently among the broad DetNet WG audience.

> (10) Has anyone threatened an appeal or otherwise indicated extreme
> discontent? If so, please summarize the areas of conflict in separate
> email messages to the Responsible Area Director. (It should be in a
> separate email because this questionnaire is publicly available.)
>

No.

> (11) Identify any ID nits the Document Shepherd has found in this
> document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
> Checklist). Boilerplate checks are not enough; this check needs to be
> thorough.

IDNits passes without errors.

> (12) Describe how the document meets any required formal review
> criteria, such as the MIB Doctor, media type, and URI type reviews.
>

N/A

> (13) Have all references within this document been identified as
> either normative or informative?
>

Yes

> (14) Are there normative references to documents that are not ready for
> advancement or are otherwise in an unclear state?

No.

> If such normative references exist, what is the plan for their completion?

N/A.

> (15) Are there downward normative references references (see RFC 3967)?
> If so, list these downward references to support the Area Director in
> the Last Call procedure.

There is currently a downref for RFC 2475 but presumably that will be moved to Informative, or discussed here.
// No, N/A.

> (16) Will publication of this document change the status of any
> existing RFCs? Are those RFCs listed on the title page header, listed
> in the abstract, and discussed in the introduction? If the RFCs are not
> listed in the Abstract and Introduction, explain why, and point to the
> part of the document where the relationship of this document to the
> other RFCs is discussed. If this information is not in the document,
> explain why the WG considers it unnecessary.

No, N/A.

> (17) Describe the Document Shepherd's review of the IANA considerations
> section, especially with regard to its consistency with the body of the
> document. Confirm that all protocol extensions that the document makes
> are associated with the appropriate reservations in IANA registries.
> Confirm that any referenced IANA registries have been clearly
> identified. Confirm that newly created IANA registries include a
> detailed specification of the initial contents for the registry, that
> allocations procedures for future registrations are defined, and a
> reasonable name for the new registry has been suggested (see RFC 5226).

N/A, no IANA requests.

>
> (18) List any new IANA registries that require Expert Review for future
> allocations. Provide any public guidance that the IESG would find
> useful in selecting the IANA Experts for these new registries.

None.

>
> (19) Describe reviews and automated checks performed by the Document
> Shepherd to validate sections of the document written in a formal
> language, such as XML code, BNF rules, MIB definitions, etc.
>

The only automated review was idnits.

Request for posting confirmation emailed to previous authors: Balazs Varga , Stewart Bryant , Janos Farkas , Don Fedyk , Jouni Korhonen , Andrew Malis , Lou Berger

EAG Work in Progress 18Nov19

> As required by RFC 4858, this is the current template for the Document
> Shepherd Write-Up.
>
> Changes are expected over time. This version is dated 24 February 2012.
>
> (1) What type of RFC is being requested (BCP, Proposed Standard,
> Internet Standard, Informational, Experimental, or Historic)?

Proposed Standard

> Why is this the proper type of RFC?

This document normatively specifies the use of IP to provide DetNet data plane service. 

> Is this type of RFC indicated in the title page header?

Yes

>
> (2) The IESG approval announcement includes a Document Announcement
> Write-Up. Please provide such a Document Announcement Write-Up. Recent
> examples can be found in the "Action" announcements for approved
> documents. The approval announcement contains the following sections:
>
> Technical Summary
>
>  Relevant content can frequently be found in the abstract
>  and/or introduction of the document. If not, this may be
>  an indication that there are deficiencies in the abstract
>  or introduction.
This document specifies the DetNet data plane operation for IP hosts and routers that provide DetNet service to IP encapsulated data.  No DetNet-specific encapsulation is defined to support IP flows; instead, the existing IP and higher layer protocol header information is used to support flow identification and DetNet service delivery.  Procedures and control information that is common to all DetNet data planes can be found in ietf-detnet-data-plane-framework.
> Working Group Summary
>
>  Was there anything in WG process that is worth noting? For
>  example, was there controversy about particular points or
>  were there decisions where the consensus was particularly
>  rough?
There were many technical debates in the process of creating this draft, but all were resolved with a clear consensus. As an example, one point of extensive discussion was about the use of the ECN field within the IPv4 ToS field as part of the 6-tuple flow identification. It was decided to simply not say anything about the use of the ECN field, i.e. to place no requirement on it. There was no objection to this result, but it took awhile to get there.
> Document Quality
>
>  Are there existing implementations of the protocol?

The IPv4 and IPv6 protocols are used without modification. At this time there are no shipping implementations of DetNet per se.

> Have a significant number of vendors indicated their plan to
>  implement the specification?

Several major vendors have been core to the development of DetNet, including Cisco, Huawei, and Ericsson so it is assumed that they plan to implement it.

> Are there any reviewers that
>  merit special mention as having done a thorough review,
>  e.g., one that resulted in important changes or a
>  conclusion that the document had no substantive issues? If
>  there was a MIB Doctor, Media Type or other expert review,
>  what was its course (briefly)? In the case of a Media Type
>  review, on what date was the request posted?

The DetNet WG (including David Black, DetNet Technical Advisor) have made extensive reviews of the present drafts.
A dedicated Data Plane Design team have met informally, regularly, to review and progress the set of data plane drafts.
Preceding the WG decisions to use IP and MPLS for the DetNet Data Plane, an extensive review of candidate technologies was done by Jouni Korhonen and team (draft-ietf-detnet-dp-alt).

> Personnel
>
>  Who is the Document Shepherd?
Ethan Grossman

> Who is the Responsible Area Director?
Deborah Brungard

>
> (3) Briefly describe the review of this document that was performed by
> the Document Shepherd.  If this version of the document is not ready
> for publication, please explain why the document is being forwarded to
> the IESG.
>

I have reread this document as it progressed as well as in its final form, and have personally contributed a number of suggestions, mostly grammatical details.  All significant comments have been addressed. The document is ready for publication.

> (4) Does the document Shepherd have any concerns about the depth or
> breadth of the reviews that have been performed?

No.

> (5) Do portions of the document need review from a particular or from
> broader perspective, e.g., security, operational complexity, AAA, DNS,
> DHCP, XML, or internationalization? If so, describe the review that
> took place.
Regarding security considerations, in my role as Editor of the DeteNet Security Considerations draft, I have endeavored to draw as much review of the security considerations of the DetNet Data Plane and DetNet Security drafts as we could convince anyone to perform. The structure of the Security Considerations sections of these (and other) DetNet drafts has been to centralize security consideration discussions in the DetNet Security Considerations draft (to avoid duplication of lengthy text in every draft), and to put only security consideration text into other drafts when there is something specific about the content of that draft that is not covered by the Security draft. We believe that we have achieved an appropriate balance between individual drafts and the Security draft, but I personally wouldn’t mind having more eyes from the Security Area on these drafts. The part that seems tricky for reviewers to understand is that we are only addressing issues that are specific to the time-sensitive behavior of IP and MPLS networks, and deferring to existing documentation all other aspects of security. In other words, identifying and addressing only time-sensitive behavior and explicitly excluding other discussion is a challenge.

> (6) Describe any specific concerns or issues that the Document Shepherd
> has with this document that the Responsible Area Director and/or the
> IESG should be aware of? For example, perhaps he or she is uncomfortable
> with certain parts of the document, or has concerns whether there really
> is a need for it. In any event, if the WG has discussed those issues and
> has indicated that it still wishes to advance the document, detail those
> concerns here.

No concerns.  This document is ready to be published.

> (7) Has each author confirmed that any and all appropriate IPR
> disclosures required for full conformance with the provisions of BCP 78
> and BCP 79 have already been filed. If not, explain why.

Yes, authors/contributors know of none, see
https://mailarchive.ietf.org/arch/msg/detnet/BI3lMBkzr2pebC__kb-eqVU-yEg

> (8) Has an IPR disclosure been filed that references this document?
> If so, summarize any WG discussion and conclusion regarding the IPR
> disclosures.
>

There were no IPR concerns raised during WG acceptance of the document, nor during the period of its development.

> (9) How solid is the WG consensus behind this document? Does it
> represent the strong concurrence of a few individuals, with others
> being silent, or does the WG as a whole understand and agree with it?

Very solid.  The document (in the context of the full set of DetNet Data Plane drafts) is mature and has been discussed sufficiently among the broad DetNet WG audience.

> (10) Has anyone threatened an appeal or otherwise indicated extreme
> discontent? If so, please summarize the areas of conflict in separate
> email messages to the Responsible Area Director. (It should be in a
> separate email because this questionnaire is publicly available.)
>

N/A

> (11) Identify any ID nits the Document Shepherd has found in this
> document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
> Checklist). Boilerplate checks are not enough; this check needs to be
> thorough.
The 03 draft currently has one downref error which presumably will be fixed post-WGLC: 
** Downref: Normative reference to an Informational RFC: RFC 2475
// IDNits passes without errors.

> (12) Describe how the document meets any required formal review
> criteria, such as the MIB Doctor, media type, and URI type reviews.
>

N/A

> (13) Have all references within this document been identified as
> either normative or informative?
>

Yes

> (14) Are there normative references to documents that are not ready for
> advancement or are otherwise in an unclear state?

No.

> If such normative references exist, what is the plan for their completion?

N/A.

> (15) Are there downward normative references references (see RFC 3967)?
> If so, list these downward references to support the Area Director in
> the Last Call procedure.

There is currently a downref for RFC 2475 but presumably that will be moved to Informative, or discussed here.
// No, N/A.

> (16) Will publication of this document change the status of any
> existing RFCs? Are those RFCs listed on the title page header, listed
> in the abstract, and discussed in the introduction? If the RFCs are not
> listed in the Abstract and Introduction, explain why, and point to the
> part of the document where the relationship of this document to the
> other RFCs is discussed. If this information is not in the document,
> explain why the WG considers it unnecessary.

No, N/A.

> (17) Describe the Document Shepherd's review of the IANA considerations
> section, especially with regard to its consistency with the body of the
> document. Confirm that all protocol extensions that the document makes
> are associated with the appropriate reservations in IANA registries.
> Confirm that any referenced IANA registries have been clearly
> identified. Confirm that newly created IANA registries include a
> detailed specification of the initial contents for the registry, that
> allocations procedures for future registrations are defined, and a
> reasonable name for the new registry has been suggested (see RFC 5226).

N/A, no IANA requests.

>
> (18) List any new IANA registries that require Expert Review for future
> allocations. Provide any public guidance that the IESG would find
> useful in selecting the IANA Experts for these new registries.

None.

>
> (19) Describe reviews and automated checks performed by the Document
> Shepherd to validate sections of the document written in a formal
> language, such as XML code, BNF rules, MIB definitions, etc.
>

The only automated review was idnits.

EAG Work in Progress 18Nov19

> As required by RFC 4858, this is the current template for the Document
> Shepherd Write-Up.
>
> Changes are expected over time. This version is dated 24 February 2012.
>
> (1) What type of RFC is being requested (BCP, Proposed Standard,
> Internet Standard, Informational, Experimental, or Historic)?

Proposed Standard

> Why is this the proper type of RFC?

This document normatively specifies the use of IP to provide DetNet data plane service. 

> Is this type of RFC indicated in the title page header?

Yes

>
> (2) The IESG approval announcement includes a Document Announcement
> Write-Up. Please provide such a Document Announcement Write-Up. Recent
> examples can be found in the "Action" announcements for approved
> documents. The approval announcement contains the following sections:
>
> Technical Summary
>
>  Relevant content can frequently be found in the abstract
>  and/or introduction of the document. If not, this may be
>  an indication that there are deficiencies in the abstract
>  or introduction.
This document specifies the DetNet data plane operation for IP hosts and routers that provide DetNet service to IP encapsulated data.  No DetNet-specific encapsulation is defined to support IP flows; instead, the existing IP and higher layer protocol header information is used to support flow identification and DetNet service delivery.  Procedures and control information that is common to all DetNet data planes can be found in ietf-detnet-data-plane-framework.
> Working Group Summary
>
>  Was there anything in WG process that is worth noting? For
>  example, was there controversy about particular points or
>  were there decisions where the consensus was particularly
>  rough?
There were many technical debates in the process of creating this draft, but all were resolved with a clear consensus. As an example, one point of extensive discussion was about the use of the ECN field within the IPv4 ToS field as part of the 6-tuple flow identification. It was decided to simply not say anything about the use of the ECN field, i.e. to place no requirement on it. There was no objection to this result, but it took awhile to get there.
> Document Quality
>
>  Are there existing implementations of the protocol?

The IPv4 and IPv6 protocols are used without modification. At this time there are no shipping implementations of DetNet per se.

> Have a significant number of vendors indicated their plan to
>  implement the specification?

Several major vendors have been core to the development of DetNet, including Cisco, Huawei, and Ericsson so it is assumed that they plan to implement it.

> Are there any reviewers that
>  merit special mention as having done a thorough review,
>  e.g., one that resulted in important changes or a
>  conclusion that the document had no substantive issues? If
>  there was a MIB Doctor, Media Type or other expert review,
>  what was its course (briefly)? In the case of a Media Type
>  review, on what date was the request posted?

The DetNet WG (including David Black, DetNet Technical Advisor) have made extensive reviews of the present drafts.
A dedicated Data Plane Design team have met informally, regularly, to review and progress the set of data plane drafts.
Preceding the WG decisions to use IP and MPLS for the DetNet Data Plane, an extensive review of candidate technologies was done by Jouni Korhonen and team (draft-ietf-detnet-dp-alt).

> Personnel
>
>  Who is the Document Shepherd?
Ethan Grossman

> Who is the Responsible Area Director?
Deborah Brungard

>
> (3) Briefly describe the review of this document that was performed by
> the Document Shepherd.  If this version of the document is not ready
> for publication, please explain why the document is being forwarded to
> the IESG.
>

I have reread this document as it progressed as well as in its final form, and have personally contributed a number of suggestions, mostly grammatical details.  All significant comments have been addressed. The document is ready for publication.

> (4) Does the document Shepherd have any concerns about the depth or
> breadth of the reviews that have been performed?

No.

> (5) Do portions of the document need review from a particular or from
> broader perspective, e.g., security, operational complexity, AAA, DNS,
> DHCP, XML, or internationalization? If so, describe the review that
> took place.
Regarding security considerations, in my role as Editor of the DeteNet Security Considerations draft, I have endeavored to draw as much review of the security considerations of the DetNet Data Plane and DetNet Security drafts as we could convince anyone to perform. The structure of the Security Considerations sections of these (and other) DetNet drafts has been to centralize security consideration discussions in the DetNet Security Considerations draft (to avoid duplication of lengthy text in every draft), and to put only security consideration text into other drafts when there is something specific about the content of that draft that is not covered by the Security draft. We believe that we have achieved an appropriate balance between individual drafts and the Security draft, but I personally wouldn’t mind having more eyes from the Security Area on these drafts. The part that seems tricky for reviewers to understand is that we are only addressing issues that are specific to the time-sensitive behavior of IP and MPLS networks, and deferring to existing documentation all other aspects of security. In other words, identifying and addressing only time-sensitive behavior and explicitly excluding other discussion is a challenge.

> (6) Describe any specific concerns or issues that the Document Shepherd
> has with this document that the Responsible Area Director and/or the
> IESG should be aware of? For example, perhaps he or she is uncomfortable
> with certain parts of the document, or has concerns whether there really
> is a need for it. In any event, if the WG has discussed those issues and
> has indicated that it still wishes to advance the document, detail those
> concerns here.

No concerns.  This document is ready to be published.

> (7) Has each author confirmed that any and all appropriate IPR
> disclosures required for full conformance with the provisions of BCP 78
> and BCP 79 have already been filed. If not, explain why.

Yes, authors/contributors know of none, see
https://mailarchive.ietf.org/arch/search/?q=%22Regarding%20IPR%20on%20draft-ietf-detnet-ip%22

> (8) Has an IPR disclosure been filed that references this document?
> If so, summarize any WG discussion and conclusion regarding the IPR
> disclosures.
>

There were no IPR concerns raised during WG acceptance of the document, nor during the period of its development.

> (9) How solid is the WG consensus behind this document? Does it
> represent the strong concurrence of a few individuals, with others
> being silent, or does the WG as a whole understand and agree with it?

Very solid.  The document (in the context of the full set of DetNet Data Plane drafts) is mature and has been discussed sufficiently among the broad DetNet WG audience.

> (10) Has anyone threatened an appeal or otherwise indicated extreme
> discontent? If so, please summarize the areas of conflict in separate
> email messages to the Responsible Area Director. (It should be in a
> separate email because this questionnaire is publicly available.)
>

N/A

> (11) Identify any ID nits the Document Shepherd has found in this
> document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
> Checklist). Boilerplate checks are not enough; this check needs to be
> thorough.
The 03 draft currently has one downref error which presumably will be fixed post-WGLC: 
** Downref: Normative reference to an Informational RFC: RFC 2475
// IDNits passes without errors.

> (12) Describe how the document meets any required formal review
> criteria, such as the MIB Doctor, media type, and URI type reviews.
>

N/A

> (13) Have all references within this document been identified as
> either normative or informative?
>

Yes

> (14) Are there normative references to documents that are not ready for
> advancement or are otherwise in an unclear state?

No.

> If such normative references exist, what is the plan for their completion?

N/A.

> (15) Are there downward normative references references (see RFC 3967)?
> If so, list these downward references to support the Area Director in
> the Last Call procedure.

There is currently a downref for RFC 2475 but presumably that will be moved to Informative, or discussed here.
// No, N/A.

> (16) Will publication of this document change the status of any
> existing RFCs? Are those RFCs listed on the title page header, listed
> in the abstract, and discussed in the introduction? If the RFCs are not
> listed in the Abstract and Introduction, explain why, and point to the
> part of the document where the relationship of this document to the
> other RFCs is discussed. If this information is not in the document,
> explain why the WG considers it unnecessary.

No, N/A.

> (17) Describe the Document Shepherd's review of the IANA considerations
> section, especially with regard to its consistency with the body of the
> document. Confirm that all protocol extensions that the document makes
> are associated with the appropriate reservations in IANA registries.
> Confirm that any referenced IANA registries have been clearly
> identified. Confirm that newly created IANA registries include a
> detailed specification of the initial contents for the registry, that
> allocations procedures for future registrations are defined, and a
> reasonable name for the new registry has been suggested (see RFC 5226).

N/A, no IANA requests.

>
> (18) List any new IANA registries that require Expert Review for future
> allocations. Provide any public guidance that the IESG would find
> useful in selecting the IANA Experts for these new registries.

None.

>
> (19) Describe reviews and automated checks performed by the Document
> Shepherd to validate sections of the document written in a formal
> language, such as XML code, BNF rules, MIB definitions, etc.
>

The only automated review was idnits.

EAG Work in Progress 11Nov19

> As required by RFC 4858, this is the current template for the Document
> Shepherd Write-Up.
>
> Changes are expected over time. This version is dated 24 February 2012.
>
> (1) What type of RFC is being requested (BCP, Proposed Standard,
> Internet Standard, Informational, Experimental, or Historic)?

Proposed Standard

> Why is this the proper type of RFC?

This document normatively specifies the use of IP to provide DetNet data plane service. 

> Is this type of RFC indicated in the title page header?

Yes

>
> (2) The IESG approval announcement includes a Document Announcement
> Write-Up. Please provide such a Document Announcement Write-Up. Recent
> examples can be found in the "Action" announcements for approved
> documents. The approval announcement contains the following sections:
>
> Technical Summary
>
>  Relevant content can frequently be found in the abstract
>  and/or introduction of the document. If not, this may be
>  an indication that there are deficiencies in the abstract
>  or introduction.

EAG Continue here...

This document provides an overall framework for the DetNet data plane.  It covers concepts and considerations that are generally common to any Deterministic Networking data plane specification.

> Working Group Summary
>
>  Was there anything in WG process that is worth noting? For
>  example, was there controversy about particular points or
>  were there decisions where the consensus was particularly
>  rough?

Nothing specific to this Framework draft.

> Document Quality
>
>  Are there existing implementations of the protocol?

DetNet is based on well-known IETF protocols (IP, MPLS) which are used without modification. At this time there are no shipping implementations of DetNet per se.

> Have a significant number of vendors indicated their plan to
>  implement the specification?

Several major vendors have been core to the development of DetNet, including Cisco, Huawei, and Ericsson so it is assumed that they plan to implement it.

> Are there any reviewers that
>  merit special mention as having done a thorough review,
>  e.g., one that resulted in important changes or a
>  conclusion that the document had no substantive issues? If
>  there was a MIB Doctor, Media Type or other expert review,
>  what was its course (briefly)? In the case of a Media Type
>  review, on what date was the request posted?

The DetNet WG (including David Black, DetNet Technical Advisor) have made extensive reviews of the present drafts.
A dedicated Data Plane Design team have met informally, regularly, to review and progress the set of data plane drafts.
Preceding the WG decisions to use IP and MPLS for the DetNet Data Plane, an extensive review of candidate technologies was done by Jouni Korhonen and team (draft-ietf-detnet-dp-alt).

> Personnel
>
>  Who is the Document Shepherd?
Ethan Grossman

> Who is the Responsible Area Director?
Deborah Brungard

>
> (3) Briefly describe the review of this document that was performed by
> the Document Shepherd.  If this version of the document is not ready
> for publication, please explain why the document is being forwarded to
> the IESG.
>

I have reread this document as it progressed as well as in its final
form.  All significant comments have been addressed. The document is
ready for publication.

> (4) Does the document Shepherd have any concerns about the depth or
> breadth of the reviews that have been performed?

No.

> (5) Do portions of the document need review from a particular or from
> broader perspective, e.g., security, operational complexity, AAA, DNS,
> DHCP, XML, or internationalization? If so, describe the review that
> took place.

No. As an Informational document, requirements for external review of this Framework draft are less extensive compared with the Normative DetNet Data Plane drafts which will be submitted for publication in conjunction with this draft.

> (6) Describe any specific concerns or issues that the Document Shepherd
> has with this document that the Responsible Area Director and/or the
> IESG should be aware of? For example, perhaps he or she is uncomfortable
> with certain parts of the document, or has concerns whether there really
> is a need for it. In any event, if the WG has discussed those issues and
> has indicated that it still wishes to advance the document, detail those
> concerns here.

No concerns.  This document is ready to be published.

> (7) Has each author confirmed that any and all appropriate IPR
> disclosures required for full conformance with the provisions of BCP 78
> and BCP 79 have already been filed. If not, explain why.

Yes, authors/contributors know of none, see
https://mailarchive.ietf.org/arch/msg/detnet/pSxhsg-p6RUVc8GeBFi6f5D1g6g


> (8) Has an IPR disclosure been filed that references this document?
> If so, summarize any WG discussion and conclusion regarding the IPR
> disclosures.
>

There were no IPR concerns raised during WG acceptance of the document, nor during the period of its development.

> (9) How solid is the WG consensus behind this document? Does it
> represent the strong concurrence of a few individuals, with others
> being silent, or does the WG as a whole understand and agree with it?

Very solid.  The document (in the context of the full set of DetNet Data Plane drafts) is mature and has been discussed sufficiently among the broad DetNet WG audience.

> (10) Has anyone threatened an appeal or otherwise indicated extreme
> discontent? If so, please summarize the areas of conflict in separate
> email messages to the Responsible Area Director. (It should be in a
> separate email because this questionnaire is publicly available.)
>

N/A

> (11) Identify any ID nits the Document Shepherd has found in this
> document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
> Checklist). Boilerplate checks are not enough; this check needs to be
> thorough.

IDNits passes without errors.

> (12) Describe how the document meets any required formal review
> criteria, such as the MIB Doctor, media type, and URI type reviews.
>

N/A

> (13) Have all references within this document been identified as
> either normative or informative?
>

Yes

> (14) Are there normative references to documents that are not ready for
> advancement or are otherwise in an unclear state?

No.

> If such normative references exist, what is the plan for their completion?

N/A.

> (15) Are there downward normative references references (see RFC 3967)?
> If so, list these downward references to support the Area Director in
> the Last Call procedure.

No, N/A.

> (16) Will publication of this document change the status of any
> existing RFCs? Are those RFCs listed on the title page header, listed
> in the abstract, and discussed in the introduction? If the RFCs are not
> listed in the Abstract and Introduction, explain why, and point to the
> part of the document where the relationship of this document to the
> other RFCs is discussed. If this information is not in the document,
> explain why the WG considers it unnecessary.

No, N/A.

> (17) Describe the Document Shepherd's review of the IANA considerations
> section, especially with regard to its consistency with the body of the
> document. Confirm that all protocol extensions that the document makes
> are associated with the appropriate reservations in IANA registries.
> Confirm that any referenced IANA registries have been clearly
> identified. Confirm that newly created IANA registries include a
> detailed specification of the initial contents for the registry, that
> allocations procedures for future registrations are defined, and a
> reasonable name for the new registry has been suggested (see RFC 5226).

N/A, no IANA requests.

>
> (18) List any new IANA registries that require Expert Review for future
> allocations. Provide any public guidance that the IESG would find
> useful in selecting the IANA Experts for these new registries.

None.

>
> (19) Describe reviews and automated checks performed by the Document
> Shepherd to validate sections of the document written in a formal
> language, such as XML code, BNF rules, MIB definitions, etc.
>

The only automated review was idnits.

Request for posting confirmation emailed to previous authors: Balazs Varga , Stewart Bryant , Janos Farkas , Don Fedyk , Jouni Korhonen , Andrew Malis , Lou Berger

Request for posting confirmation emailed to previous authors: Balazs Varga , Stewart Bryant , Janos Farkas , Don Fedyk , Jouni Korhonen , Andrew Malis , Lou Berger

Request for posting confirmation emailed to previous authors: Balazs Varga , Stewart Bryant , Janos Farkas , Don Fedyk , Jouni Korhonen , Andrew Malis , Lou Berger