Deterministic Networking (DetNet) Data Plane Framework
draft-ietf-detnet-data-plane-framework-06

[Ballot comment]
Sorry, I ran out of time to fully review this document, but one surprise what that the title and abstract only mentions the dataplane, but then the document also has a reasonably sized section on control plane considerations, and I didn't know whether it would be helpful for the abstract to also mention this fact.

[Ballot comment]
Sorry, I ran out of time to fully review this document, but one surprise what the the title and abstract only mentions the dataplane, but then the document also has a reasonably sized section on control plane considerations, and I didn't know whether it would be helpful for the abstract to also mention this fact.

[Ballot comment]
I ran out of time to fully review this document, but one surprise what the the title and abstract only mentions the dataplane, but then the document also has a reasonably sized section on control plane considerations, and I didn't know whether it would be helpful for the abstract to also mention this fact.

[Ballot comment]
Other than some remarks on the security considerations, I basically just
have a bunch of editorial comments.  I've tried to deduplicate with what was
already reported by other ADs, but no doubt have kept a few things in that
have already been mentioned.

Section 1

  The DetNet Architecture models the DetNet related data plane
  functions decomposed into two sub-layers: a service sub-layer and a
  forwarding sub-layer.  The service sub-layer is used to provide

nit: "models" needs two objects to act on/compare, so maybe "as being
decomposed into".

  replicated in other forwarding technologies.  Most of DetNet benefits
  can be gained by running over a data link layer that has not been
  specifically enhanced to support all TSN capabilities but for certain
  networks and traffic mixes delay and jitter performance may vary due
  to the forwarding sub-layer intrinsic properties.

nit: I think the "certain networks and traffic mixes" are supposed to be
contingent on "a data link layer that [is not a TSN]" but the current text
does not quite match that.  Perhaps "certain such networks" is the smallest
fix, though it does conflate "data link layer" and "network" in an
unfortunate manner.

Section 3

  connectivity function of the forwarding sub-layer.  An example of
  this is Packet Replication, Elimination, and Ordering functions see
  Section 4.3.  The ordering (POF) uses sequence numbers added to

nit: the punctuation around the reference should be tweaked.

  The method of instantiating each of the layers is specific to the
  particular DetNet data plane method, and more than one approach may
  be applicable to a given bearer network type.

What is a "bearer network"?

Section 3.1.1

  applying existing standardized headers and/or encapsulations.  The
  Detnet forwarding sub-layer may provide capabilities leveraging that
  same header or encapsulation technology (e.g., DN IP or DN MPLS) or
  it may be achieved by other technologies (e.g., Figure 2).  DetNet is

nit: Figure 2 is not a technology; maybe "as shown in Figure 2".

Section 3.1.2

  number) in packets.  For example, in DetNet IP, zero encapsulation is
  used and no sequence number is available, and in DetNet MPLS, DetNet
  specific information may be added explicitly to the packets in the
  format of S-label and d-CW [I-D.ietf-detnet-mpls] .

nit: s/format of/form of/

Section 3.3

  Number (for PREOF) for each DetNet flow.  The DetNet Service sub-
  layer requires both; the DetNet forwarding sub-layer requires only
  Flow-ID.  Metadata can also be used for OAM indications and

nit(?): to say that "the service sublayer requires both" to me implies that
it always and unconditionally requires both, but IIUC the PREOF functions
are optional, and so for a given flow the service sublayer might not require
the sequence number.  Perhaps swapping it around to be structured more like
"the flow-ID is used by both the service and forwarding sub-layers, but the
sequence number is only used by the service layer" would help?

  Some MPLS examples of implicit metadata include the sequence number
  for use by the PREOF function, or even all the essential information
  being included into the DetNet over MPLS label stack (the DetNet
  Control Word and the DetNet Service label).

I would have thought that the detnet elements in the label stack would be
considered explicit metadata, but perhaps I'm just looking through the wrong
lens.

Section 3.4

  One method of operating an IP DetNet data plane without encapsulation
  is to use "6-tuple" based flow identification, where "6-tuple" refers
  to information carried in IP and higher layer protocol headers.
  General background on the use of IP headers, and "6-tuples", to
  identify flows and support Quality of Service (QoS) can be found in
  [RFC3670].  [RFC7657] provides useful background on differentiated

I did not see the explicit phrase "6-tuple" used in RFC 3670, so I don't
think this text is quite right as written.  (7657 does talk about it, but is
not currently being referenced for that purpose.)

Section 3.6.1.5

Is there a difference between "packet-by-packet distribution [of the same
flow]" and "packet-by-packet load sharing"?

Section 3.6.1.6

  as those in use by IP and MPLS networks.  At the Application layer a
  client of a DetNet service can use existing techniques to detect and
  monitor delay and loss.

[Is there a good reference for these "existing techniques"?  I recognize
that we shouldn't go into extensive detail here, and absent a single
consolidated reference, no-reference may be best.]

Section 3.6.2

  Service protection allow DetNet services to increase reliability and
  maintain a DetNet Service Assurance in the case of network congestion
  or network failure.  Detnet relies on the underlying technology

My understanding is that the whole point of DetNet was to provide
reliability in the face of network congestion (e.g., by resource
reservation).  So is it really only the "network failure" case that benefits
from service protection?

Section 3.6.3.1

  IP aggregation has both data plane and controller plane aspects.  For
  the data plane, flows may be aggregated for treatment based on shared
  characteristics such as 6-tuple.  Alternatively, an IP encapsulation

In what way would 6-tuple be a "shared characteristic" for *different*
flows?  I thought 6-tuple was typically used as a unique flow identifier...
(I see in Section 4.2.1 we refer to flows that "share 6-tuple attributes".)

Section 4.1

  However, from a practical and implementation standpoint, they are not
  equivalent at all.  Some approaches are more scalable than others in
  terms of signaling load on the network.  Some can take advantage of
  global tracking of resources in the DetNet domain for better overall
  network resource optimization.  Some are more resilient than others
  if link, node, or management equipment failures occur.  While a
  detailed analysis of the control plane alternatives is out of the
  scope of this document, the requirements from this document can be
  used as the basis of a later analysis of the alternatives.

side note: using "some" so much requires the reader to know which are which
... that may be reasonable, but perhaps we want the reader's brainpower
working on other things.

Section 4.2

nit: RestConf and YANG probably are best considered together as a single
"management mechanism" for these purposes.

Section 4.2.2

  DetNet application with the required service.  A requirement for the
  DetNet Controller Plane will be the ability to assign a particular
  identified DetNet IP flow to a path through the DetNet domain that
  has been assigned the required nodal resources.  This provides the

nit: I don't think that "nodal" is quite the right word, here, as it refers
to a property of the (network) graph more than the specific element
colocated with the node in the graph.  "per-node" seems like a better fit,
to me.

Section 4.3

  domain requires explicit support.  There may be capabilities that can
  be used, or extended, for example GMPLS end-to-end recovery [RFC4872]
  and GMPLS segment recovery [RFC4873].

nit: maybe this is "existing capabilities"?

Section 5

I guess there's some standard security considerations for when flow
aggregation is in play, namely that misbehavior from one component flow can
affect sibling flows as collateral damage.

  Security considerations for DetNet are described in detail in
  [I-D.ietf-detnet-security].  General security considerations are

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").  I would like to know what the current maturity state of the
detnet-security document is believed to be, so as to judge how appropriate
it is for the data-plane-framework to refer to it in this manner.

  described in [RFC8655].  This section considers general security

I think this is more like "Architecture-level DetNet" than "Generic", as the
current formulation sounds like it should be referring to BCP 72 :)

  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 can't find a way to read this other than "security aspects [...] whose aim
is to provide the specific quality of service aspects", and I'm puzzling at
why it's phrased in this way.  Specifically, I thought that *providing* the
QoS aspects is the core role of DetNet, and thus that the *security* aspects
would be protecting those aspects in the face of (some class of) attackers.
Would it be appropriate to replace this with something like the following?

% Part of what makes DetNet unique is its ability to provide specific and
% reliable quality of service (delivering data flows with extremely low
% packet loss rates and bounded end-to-end delivery latency), and the
% security-related aspects of protecting that quality of service are
% similarly unique.

This might also be a good place to note that correct operation of the PREOF
functions is pretty critical, and failures there could lead to pretty
catastrophic situations for the operational technology relying on them.  I
don't think there are ways for an attacker to try to attack them directly,
but Murphy's Law can be a pretty effective attacker, too.

  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

I'd suggest leading in to this with "As for all communications protocols,"
to be clear that this paragraph is not trying to cover the bits that are
"unique to DetNet" as much as remind the reader of general best practices.

  At the management and control level DetNet flows are identified on a
  per-flow basis, which may provide controller plane attackers with
  additional information about the data flows (when compared to
  controller planes that do not include per-flow identification).  This
  is an inherent property of DetNet which has security implications
  that should be considered when determining if DetNet is a suitable
  technology for any given use case.

I might also note that attackers with access to the controller plan already
have pretty significant attacks available to them.

  To provide uninterrupted availability of the DetNet service,
  provisions can be made against DOS attacks and delay attacks.  To
  protect against DOS attacks, excess traffic due to malicious or
  malfunctioning devices can be prevented or mitigated, for example
  through the use of existing mechanism such as policing and shaping
  applied at the input of a DetNet domain.  To prevent DetNet packets

In my head this would include things like disabling switch ports that are
receiving traffic floods that might overload the switch CPU, in order to
protect the DetNet traffic on other ports.  I don't see much value in saying
that in the document, though, since it's more of an operational practice
thing.

Section 9.1

RFC 3209 is cited only once, and it does not seem like a particularly
normative one.  Similarly, RFC 3473 is cited only as a "such as" example
(though several times).

[Ballot comment]
Doh! I had collected a whole pile of editorial nits and comments, but see that others have already covered them -  that'll larn me to procrastinate...

[Ballot comment]
(1) References:  I don't think that RFC3209, RFC3473 or RFC4385 need to be Normative as they seem to be used mostly as examples.


(2) [nits]

s/reproduced from the [RFC8655],shows/reproduced from [RFC8655] shows

s/[RFC4385],can be used/[RFC4385], can be used

s/constraint on its size of/constraint on the size of

s/RFC5575/draft-ietf-idr-rfc5575bis

[Ballot comment]
Thanks for this document.  Just lots of editorial comments here:

The RPC will need to do a lot of comma editing.  I’m not going to call them all out here.

— Section 1 —

  It describes the function
  and operation of the Packet Replication (PRF) Packet Elimination
  (PEF) and the Packet Ordering (POF) functions

You need commas between the items in the list.  I also find “the fuction of the functions” to be very odd, and suggest eliminating “functiin and” from the beginning of the sentence.

  Furthermore, it also describes the forwarding sub-layer.

“Furthermore” and “also” together is redundant, and I suggest eliminating one of them.

  Different application flows (e.g., Ethernet, IP, etc.) can be mapped

“e.g.” and “etc.” together is redundant, and I suggest “Different application flows, such as Ethernet or IP, can be mapped”.  If you keep the parentheses, the comma needs to disappear.

— Section 3 —

  The DetNet Architecture, [RFC8655],
  models the DetNet related data plane functions

You don’t need the commas to set off the citation, as the brackets already do that.  And “DetNet-related” needs a hyphen.

  Figure 1 reproduced from the [RFC8655],shows

Make this, “Figure 1, reproduced from [RFC8655], shows”

— Section 3.1.1 —

  currently defined for operation over packet switched (IP) networks or
  label switched (MPLS) networks.

Hyphenate “packet-switched” and “label-switched”.

— Section 3.1.2 —

  used and no sequence number is available, and in DetNet MPLS, DetNet
  specific information

Hyphenate “DetNet-specific”.

— Section 3.2 —

  An example of such metadata is
  the inclusion of a sequence number required by the PREOF function.

“PREOF function” is redundant, as the “F” already means “function”.  Also later in the document.

— Section 3.4 —

  may be deployed, for example GRE, IPSec etc.

“for example” and “etc.” together is redundant.

— Section 3.6.1.1 —

  Reservation of resources can allocate resources to specific DetNet
  flows.

This sounds a bit odd.  Maybe, “Resources might be reserved in order to make them available for allocation to specific DetNet flows.” ?

  Misbehaving DetNet flows
  must be able to be detected and ensure that they do not compromise
  QoS of other flows.

This sounds like it’s something that misbehaving DetNet flows have to do.  It would be better this way:

NEW
  It must be possible to detect misbehaving DetNet flows
  and to ensure that they do not compromise QoS of other flows.
END

— Section 3.6.1.2 —

  Explicit route
  computation can encompass a wide set of constraints and optimize the
  path for a certain characteristic e.g. highest bandwidth or lowest
  jitter.

This would sound better with “and can optimize”.  And “e.g.” needs commas bith before and after it, always.

— Section 3.6.1.4 —

  DetNet could utilized Network coding

Make it “utilize” (or, better, “use”).

— Section 3.6.2.1 —

  traffic over each segment of the end to end path.

Hyphenate “end-to-end” here.

  In this case there is no PRF
  function

“PRF function” is redundant.

— Section 3.6.2.2 —

  DetNet uses flow specific requirements (e.g., maximum
  number of out-of-order packets, maximum latency of the flow, etc.)
  for configuration of POF related buffers.

Hyphenate “flow-specific” and “POF-related”, and eliminate either “e.g.” or “etc.”

— Section 3.6.2.3 —

  Many of the same concepts apply however rings are

There needs to be a comma before “however”.

— Section 3.6.3 —

  How this is accomplished is data plane or control plane dependent.

NEW
  How this is accomplished is data-plane or control-plane dependent.
END

  When aggregating
  DetNet flows the flows should be compatible i.e. the same or very
  similar QoS and CoS characteristics.

NEW
  When aggregating
  DetNet flows, the flows should be compatible, i.e., have the same or
  very similar QoS and CoS characteristics.
END

— Section 3.6.5 —

  MPLS nodes may interconnected by different sub-network

“may be interconnected”

  Each of these
  sub-network technologies need to provide appropriate service

The subject is “each”, which is singular, so “needs to provide”.

— Section 4.2 —

  While management plane and control planes are traditionally
  considered separately, from the Data Plane perspective

Don’t capitalize “data plane” here.

— Section 4.2.1 —

  There are many techniques to achieve aggregation,
  for example in case of IP, it can be grouping of IP flows that share
  6-tuple attributes or flow identifiers at the DetNet sub-layer.

Very awkward sentence.  Split and rephrase:

NEW
  There are many techniques to achieve aggregation.
  For example, in the case of IP,  IP flows that share 6-tuple
  attributes or flow identifiers at the DetNet sub-layer can be
  grouped.
END

— Section 5 —

  The primary considerations for the data plane is to maintain
  integrity of data and delivery of the associated DetNet service

“consideration”, singular.

  through the use of existing mechanism such as policing and shaping

Make it “an existing mechanism” or “existing mechanisms”.

[Ballot comment]
Editorial nits mostly.  The more interesting stuff first:

Throughout the document, various terms are sometimes capitalized and sometimes not.  A pass should be done to make this uniform throughout the document.  This becomes especially confusing in Section 3.6.2.1.  Examples: "App-flows". "Service sub-layer", "Forwarding sub-layer", "Packet".

Section 2.2:
* "CW" by itself doesn't appear anywhere in this document.  Neither do "LSR", "MPLS-TE", or "PW".

Section 3.1:
* Given the sentence in 3.1, I would expect the "technology" and "encapsulation" sections to be at the same level in the Table Of Contents tree, but they aren't.  That is, since "Data Plane Technology" is 3.1.1, I would expect "Encapsulation" to be 3.1.2.  Is some adjustment in order here?

Section 3.3:
* This paragraph needs a bit of editing:
-- OLD --
  Metadata can be included implicit or explicit.  Explicit means that a
  dedicated header field is used to include metadata in a DetNet
  packet.  In case of implicit method a part of an already existing
  header field is used to encode the metadata.
-- SUGGEST --
  Metadata inclusion can be implicit or explicit.  Explicit inclusions
  involve a dedicated header field that is used to include metadata
  in a DetNet packet.  In the implicit method, part of an already existing
  header field is used to encode the metadata.

Section 3.6.1.2:
* "Use of a specific path for a flow." -- this isn't a sentence; suggest: "A flow can be routed over a specific, pre-computed path."

Section 3.6.1.3:
* "Use of multiple packet streams using multiple paths, for example 1+1 or 1:1 linear protection." -- again not a sentence; maybe start with "Service protection involves use of ..."

Section 3.6.1.8:
* "... are currently out of scope for this document." -- remove "currently"; these issues won't be in scope for this document later

Section 3.6.2.1:
* "An OAM scheme that monitors the paths detects the loss of path or traffic is required to initiate the switch." -- I can't parse this sentence.  Maybe "detects" should be "to detect"?

Section 3.6.3:
* "the sum of the reservations should be the sum of all the individual reservations" -- there may be a term of art in play here, but that phrase seems self-redundant; what else could the latter be but the former?

Section 4.2.1:
-- OLD --
        The assignment of resources along the path depends on the
        technology and it includes assignment of specific links and
        coordination of the queuing and other traffic management
        capabilities such as policing and shaping.
-- NEW --
The assignment of resources along the path depends on the technology
and includes assignment of specific links, coordination of queueing, and
other traffic management capabilities such as policing and shaping.

And now the boring stuff, to save the RFC Editor some work:

Section 1:
* "Different application flows (e.g., Ethernet, IP, etc.), can be mapped on top of DetNet." -- remove the comma

Section 3:
* "Figure 1 reproduced from the [RFC8655],shows ..." -- remove "the" and replace the comma with a space
* "The ordering (POF) uses sequence numbers ..." -- should probably be "The ordering function (POF) uses sequence numbers ..."

Section 3.3:
* "... can provide or carry metadata:" -- add "the following" after "carry"

Section 3.4:
* "... for example GRE, IPSec etc." -- comma after "IPSec"

Section 3.5:
* "... the d-CW [I-D.ietf-detnet-mpls], [RFC4385],can be used." -- add a space before "can"
* "... no architectural constraint on its size of this structure ... -- s/its/the/

Section 3.6.1.2:
* "... for a certain characteristic e.g. highest ..." -- s/characteristic e.g. highest/characteristic, e.g., highest/

Section 3.6.1.3:
* "For DetNet this primarily ..." -- add a comma after "DetNet"

Section 3.6.1.4:
* "Network Coding, [nwcrg] not to ..." -- move the comma to after "[nwcrg]"
* "DetNet could utilized Network coding ..." -- s/utilized/utilize/ (or simply "use")

Section 3.6.2:
* "Service protection allow DetNet services ..." -- s/allow/allows/

Section 3.6.2.1:
* "Figure 3: Example Packet Flow in DetNet protected Network" -- capitalize "protected"
* "copy of packet 1.2 etc." -- add a comma after "1.2"
* "...entities shown in Figure 3 ." -- s/3 ./3./
* "... traffic at a time, could use the ..." -- remove comma

Section 3.6.2.3:
* "Many of the same concepts apply however rings ..." -- add a comma after "apply"

Section 3.6.3:
* "When aggregating DetNet flows the flows should ..." -- add a comma after the first "flows"
* "... should be compatible i.e. the same ..." -- s/compatible i.e./compatible, i.e.,/
* "When an encapsulation is used the choice ..." -- add comma after "used"

Section 3.6.5:
* "L2 represent a generic ..." s/represent/represents/

Section 4.1.:
* The second citation of RFC8655 in the first paragraph is probably not needed.

Section 4.2:
* "While management plane and control planes ..." -- maybe "While the management and control planes ..."
* Add a comma after "For example" in the last paragraph.

Section 4.2.1:
* "... provisioned or requested one or more ..." -- add comma after "requested"

Section 4.2.4:
-- OLD --
An example control plane solution for MPLS can be
  found in [RFC3473] , [RFC6387] and [RFC7551].
-- NEW --
Example control plane solutions for MPLS can be found in
[RFC3473], [RFC6387], and [RFC7551].

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

The IANA Functions Operator has reviewed draft-ietf-detnet-data-plane-framework-04, 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: db3546@att.com, Ethan Grossman , draft-ietf-detnet-data-plane-framework@ietf.org, detnet@ietf.org, eagros@dolby.com, detnet-chairs@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (DetNet Data Plane Framework) to Informational RFC


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

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 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.




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

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-detnet-data-plane-framework/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)?

Informational

> Why is this the proper type of RFC?

This document provides an overall framework for the DetNet data  plane, without specifying normative behavior; there are accompanying drafts for each of the data plane technologies (IP, MPLS, TSN) which provide the normative aspects of the use of each of these technologies, as well as their interaction (e.g. "DetNet MPLS over UDP/IP").

> 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 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.)
>

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.

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)?

Informational

> Why is this the proper type of RFC?

This document provides an overall framework for the DetNet data  plane, without specifying normative behavior; there are accompanying drafts for each of the data plane technologies (IP, MPLS, TSN) which provide the normative aspects of the use of each of these technologies, as well as their interaction (e.g. "DetNet MPLS over UDP/IP").

> 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 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.)
>

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.

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)?

Informational

> Why is this the proper type of RFC?

This document provides an overall framework for the DetNet data  plane, without specifying normative behavior; there are accompanying drafts for each of the data plane technologies (IP, MPLS, TSN) which provide the normative aspects of the use of each of these technologies, as well as their interaction (e.g. "DetNet MPLS over UDP/IP").

> 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 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.

> 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)?

Informational

> Why is this the proper type of RFC?

This document provides an overall framework for the DetNet data  plane, without specifying normative behavior; there are accompanying drafts for each of the data plane technologies (IP, MPLS, TSN) which provide the normative aspects of the use of each of these technologies, as well as their interaction (e.g. "MPLS over UDP/IP").

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

There was a lot of discussion about the use of the DSCP and ECN IP header fields for flow identification, but they were each resolved to unanimous agreement.

> 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.

Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 0 comments (--).
Details:
  == Outdated reference: draft-ietf-detnet-architecture has been published as
    RFC 8655
  == Outdated reference: A later version (-02) exists of
    draft-ietf-detnet-ip-01
  == Outdated reference: A later version (-02) exists of
    draft-ietf-detnet-mpls-01
  Miscellaneous warnings:
  == Line 205 has weird spacing: '...e stack  v    ...'

> (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