Deterministic Networking (DetNet) Bounded Latency
draft-ietf-detnet-bounded-latency-10

Request for posting confirmation emailed to previous authors: Balazs Varga , Ehsan Mohammadpour , Janos Farkas , Jean-Yves Le Boudec , Jiayi Zhang , Norman Finn , detnet-chairs@ietf.org

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

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

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


[BennettDelay]

This seems to be a broken reference in section 4.2.2

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

But shepherds write up said:

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

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


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

[Ballot comment]
Thank you for the work on this document.

Many thanks to Robert Sparks for his ART ART review: https://mailarchive.ietf.org/arch/msg/art/IVotuLgxpTSyiLdkNk9O1RdkrVI/ , and thanks to the authors for addressing it.

I agree with Robert (and with Murray, who has brought it up in the context of the shepherd write-up) that it is not completely clear to me why this document is Informational. This is not a major comment that should stop publication, nor it rises to the level of a blocking DISCUSS, but it might be good to have a short discussion during the telechat on its intended status, to understand its purpose and audience. Is it expected that this document will be referenced by Standard Track RFCs in the future?

Francesca

[Ballot comment]
The shepherd writeup doesn't answer the question of why Informational is the right type of RFC.

Just wanted to check here with the sponsoring AD that we're OK with more authors than the guidelines recommend.

Section 2 defines "PROEF", but that term appears nowhere in the document.

[Ballot comment]
Thank you to Watson Ladd for the SECDIR review.

** Section 8.  It wasn’t clear to me that outright control of a resource (e.g., relay) was needed impact the latency bound calculation.  Recommending a bit more flexibility on what an attack would take:

OLD
  but may have the
  ability to control some resources within the boundary of the DetNet
  domain.

NEW

but may have the ability to control or change the behavior of some resources within the boundary of the DetNet domain.

** Section 8.

An example of such attacks is to make some
  traffic sources under the control of the attacker send more traffic
  than their assumed T-SPECs.  This type of attack is typically avoided
  by ingress conditioning at the edge of a DetNet domain

If a traffic source _in the DetNet_ is induced to send more than their T-SPEC, how does ingress conditioning at the edge help with mitigation?  This DetNet node is already in the DetNet domain.

** Section 8.  Figure 1 presented a taxonomy of delays (#1 – 6) for the timing model.  It would be helpful to explicitly extend this taxonomy to a threat analysis, or to rule out that mitigating certain threats are out of scope.  For example:

-- 1: Output delay: ?
-- 2: Link delay: somewhat covered by the discussion of timing; and violating T-SPECs.
-- 3: Frame preemption delay: ?
-- 4: Processing delay: ?
-- 5: Regulation delay: ?
-- 6: Queuing delay: covered by “Some queuing mechanisms require time synchronization and operate correctly only if the time synchronization works correctly ...”

[Ballot comment]
Section 11.2. , paragraph 7, comment:
>    [IEEE8021Qcr]
>              IEEE 802.1, "IEEE P802.1Qcr: IEEE Draft Standard for Local
>              and metropolitan area networks - Bridges and Bridged
>              Networks - Amendment: Asynchronous Traffic Shaping", 2017,
>              .

Please link to a public version of this document, if possible.

The document has six authors, which exceeds the recommended author limit. I
assume the sponsoring AD has agreed that this is appropriate?

Thanks to Gyan S. Mishra for their General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/yMbUVrUjPZYqHTfNd8XwqMwg0FI).

-------------------------------------------------------------------------------
NIT
-------------------------------------------------------------------------------
All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Document references draft-ietf-detnet-controller-plane-framework-00, but -01 is
the latest available revision.

These URLs in the document did not return content:
* http://www.ieee802.org/1/files/private/cr-drafts/

These URLs in the document can probably be converted to HTTPS:
* http://ieeexplore.ieee.org/document/8403927
* http://www.ieee802.org/1/

Section 6.4. , paragraph 6, nit:
> cussed in Section 4.2.2; an interleaved regulators does not increase the dela
>                          ^^^^^^^^^^^^^^^^^^^^^^^^^
The plural noun "regulators" cannot be used with the article "an". Did you mean
"an interleaved regulator" or "interleaved regulators"?

Section 6.4.2. , paragraph 9, nit:
> T, CQF with more buffers can be used and a cycle identification label can be
>                                    ^^^^
Use a comma before "and" if it connects two independent clauses (unless they
are closely connected and short).

Section 6.6. , paragraph 3, nit:
> to entrance of the first node in sub-network 2, and d3_p the delay bound of p
>                                  ^^^^^^^^^^^
This word is normally spelled as one. (Also elsewhere.)

[Ballot comment]
Thank you for the work put into this document. It was a fascinating read and most of the text is easy to understand. Good job ! Could even end up as educational material ;-)

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits.

Special thanks to:

- Lou Berger for the shepherd's write-up including the absence of implementations

- Ralf Weber for his IETF last call INT directorate review at: https://datatracker.ietf.org/doc/review-ietf-detnet-bounded-latency-08-intdir-lc-weber-2022-02-06/. Ralf's review was acted upon by Mohammadpour Ehsan ;-)

I hope that this helps to improve the document,

Regards,

-éric

Please note that I am not a DetNet expert, hence some comments are possibly not relevant. The use of "regulator" instead of "shaper" was also surprising to me ;-) There may even be a semantic difference between a shaper and a regulator that I have to learn.

More generally, the document is about a bound on the latency, but would it be possible to compute an aggregate latency curve, which could also be interesting?

## Abstract

The document goes beyond "it provides a methodology to compute end-to-end latency" as it describes how admission control is important and gives formulas to compute the latency bounds in many technologies. The content is great but the abstract should reflect the actual content.

## Section 1

"DetNet flows are characterized by" is followed by only 2 characteristics of DetNet and does not mention low packet loss. Even if this I-D is about latency, why not adding "notably" in the text ?

## Section 2

As noted by other ADs, either the acronym "PROEF" or its expansion is wrong ;-)

## Section 3.1.1

Perhaps some examples of "static latency" could be added to ease the reading ? E.g., does it include serialisation and propagation times ?

Have the authors considered the use of "constant" rather than "static" ?


## Section 3.2

Does DetNet support some link having some flow control / congestion at layer-2 or layer-1 ?

Are there any DetNet relay able to start forwarding packet after receiving just a couple of bytes of the frame w/o having to wait for the full frame reception ? Similarly, should the deserialisation delay be taken into account ? Or any congestion inside a relay node (e.g., contention to a backplane bus)

## Section 4.1

Is "end-to-end delay" defined in DetNet architecture ? I.e., is it from first bit out from the source to the last bit received by the destination ? Or other variation ? Or the difference is so small that it does not care ?

## Section 4.4

Sorry couldn't resist in suggesting to rename "DetNet-unaware island" into "DetNet-unaware swamp" ;-) (comment to be ignored of course)

## Section 5

Should some assumptions be listed ? E.g., no packet replication/generation/encapsulation/discard by the relay node ?

## Section 6.1

Is the list at the end of this section exhaustive ? If so, then why not adding "IP protocol (e.g., UDP or TCP)" ? Else, please let's be clear that it is not exhaustive.


# NITS 

AFAIK, XML2RFCv3 has features for mathematical formulas that could be used for this document to increase readability.

Usually, "e.g." is followed by a coma. Same for "i.e.".

## Section 1

Multiple lists in the section would benefit from a correct markup to put one bullet per line.

In "It disregards the in-band packets", and accept all my apologies for not being a native English speaker, but "disregards" sounds really negative.

## Section 6.3

s/Time Aware Shaper/Time-Aware Shaper/ ?

[Ballot comment]
# Internet AD comments for draft-ietf-detnet-bounded-latency-09
CC @ekline

### S2

Super-nitty, but I feel like the acronym should be PREOF, given the
expansion and the use of PREOF later on.  If it should be PROEF then
perhaps update the expanded text and the use of PREOF later on.

### S6.4.1

"an interleaved regulators" -> "an interleaved regulator"

[Ballot comment]
I don't understand this sentence in the introduction:

"It disregards the in-band packets that can be part of the stream such as OAM and necessary re-transmissions"

Are you referring to retransmissions of user data? If so, that sounds like an important consideration for latency bounds!

Thanks to Yoshi for the TSVART review.

Nits:

(2) s/PROEF/PREOF

(6.6) s/is the same cycle/in the same cycle (or maybe I just don't understand this sentence?)

Request for posting confirmation emailed to previous authors: Balazs Varga , Ehsan Mohammadpour , Janos Farkas , Jean-Yves Le Boudec , Jiayi Zhang , Norman Finn

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

The IANA Functions Operator has reviewed draft-ietf-detnet-bounded-latency-08, 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
Lead IANA Services Specialist

The following Last Call announcement was sent out (ends 2022-02-08):

From: The IESG
To: IETF-Announce
CC: detnet-chairs@ietf.org, detnet@ietf.org, draft-ietf-detnet-bounded-latency@ietf.org, jgs@juniper.net, lberger@labn.net
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (DetNet Bounded Latency) to Informational RFC


The IESG has received a request from the Deterministic Networking WG (detnet)
to consider the following document: - 'DetNet Bounded Latency'
  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 2022-02-08. 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 references specific queuing mechanisms, defined in
  other documents, that can be used to control packet transmission at
  each output port and achieve the DetNet qualities of service.  This
  document presents a timing model for sources, destinations, and the
  DetNet transit nodes that relay packets that is applicable to all of
  those referenced queuing mechanisms.  Using the model presented in
  this document, it is possible for an implementor, user, or standards
  development organization to select a particular set of queuing
  mechanisms for each device in a DetNet network, and to select a
  resource reservation algorithm for that network, so that those
  elements can work together to provide the DetNet service.




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


The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/4581/

Request for posting confirmation emailed to previous authors: Balazs Varga , Ehsan Mohammadpour , Janos Farkas , Jean-Yves Le Boudec , Jiayi Zhang , Norman Finn

Request for posting confirmation emailed to previous authors: Balazs Varga , Ehsan Mohammadpour , Janos Farkas , Jean-Yves Le Boudec , Jiayi Zhang , Norman Finn

> 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 1 November 2019.


> (1) What type of RFC is being requested (BCP, Proposed Standard,
> Internet Standard, Informational, Experimental, or Historic)? Why is
> this the proper type of RFC? Is this type of RFC indicated in the title
> page header?

Informational

  This document references specific queuing mechanisms, defined in
  other documents, that can be used to control packet transmission at
  each output port and achieve the DetNet qualities of service.

> 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 references specific queuing mechanisms, defined in
  other documents, that can be used to control packet transmission at
  each output port and achieve the DetNet qualities of service.  This
  document presents a timing model for sources, destinations, and the
  DetNet transit nodes that relay packets that is applicable to all of
  those referenced queuing mechanisms.  Using the model presented in
  this document, it should be possible for an implementor, user, or
  standards development organization to select a particular set of
  queuing mechanisms for each device in a DetNet network, and to select
  a resource reservation algorithm for that network, so that those
  elements can work together to provide the DetNet service.

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

> Document Quality:
> Are there existing implementations of the protocol? Have a significant
> number of vendors indicated their plan to implement the specification?
> 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, YANG 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?

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

> Personnel:

> Who is the Document Shepherd?
Lou Berger

> Who is the Responsible Area Director?
John Scudder

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

The Shepherd reviewed this document as it progressed through the WG as
well as part of Last Call.  All significant comments have been resolved.

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

> (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 document basically says use other standards in a
specific way to ensure interoperability.  There's slightly more left for
further documents than I would have hoped, but the approach of defining
data-plane first is reasonable.

> (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, see
https://mailarchive.ietf.org/arch/msg/detnet/lKuo26qd_iKj_vChjOlKreqmXGM/

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

Yes,
https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-detnet-bounded-latency

Other than the WG being made of the IPR, there was no specific discussion.


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

I think the document has good support from the narrow set of WG
participants interested in this problem space.

> (10) Has anyone threatened an appeal or otherwise indicated extreme
> discontent? If so, please summarise 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 http://www.ietf.org/tools/idnits/ and the Internet-Drafts
> Checklist). Boilerplate checks are not enough; this check needs to be
> thorough.

No.

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

Idnits passes, showing only one false warning.

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

N/A. YANG support will be done speperatley based on other work in the WG.

> (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? If such normative
> references exist, what is the plan for their completion?

No.

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

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

No requests are made in the document.

> (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, YANG modules,
> etc.

N/A

> (20) If the document contains a YANG module, has the module been checked
> with any of the recommended validation tools
> (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and
> formatting validation? If there are any resulting errors or warnings,
> what is the justification for not fixing them at this time? Does the
> YANG module comply with the Network Management Datastore Architecture
> (NMDA) as specified in RFC8342?

There are no yang modules.

> 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 1 November 2019.


> (1) What type of RFC is being requested (BCP, Proposed Standard,
> Internet Standard, Informational, Experimental, or Historic)? Why is
> this the proper type of RFC? Is this type of RFC indicated in the title
> page header?

Informational

  This document references specific queuing mechanisms, defined in
  other documents, that can be used to control packet transmission at
  each output port and achieve the DetNet qualities of service.

> 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 references specific queuing mechanisms, defined in
  other documents, that can be used to control packet transmission at
  each output port and achieve the DetNet qualities of service.  This
  document presents a timing model for sources, destinations, and the
  DetNet transit nodes that relay packets that is applicable to all of
  those referenced queuing mechanisms.  Using the model presented in
  this document, it should be possible for an implementor, user, or
  standards development organization to select a particular set of
  queuing mechanisms for each device in a DetNet network, and to select
  a resource reservation algorithm for that network, so that those
  elements can work together to provide the DetNet service.

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

> Document Quality:
> Are there existing implementations of the protocol? Have a significant
> number of vendors indicated their plan to implement the specification?
> 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, YANG 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?

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

> Personnel:

> Who is the Document Shepherd?
Lou Berger

> Who is the Responsible Area Director?
John Scudder

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

The Shepherd reviewed this document as it progressed through the WG as
well as part of Last Call.  All significant comments have been resolved.

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

> (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 document basically says use other standards in a
specific way to ensure interoperability.  There's slightly more left for
further documents than I would have hoped, but the approach of defining
data-plane first is reasonable.

> (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, see
https://mailarchive.ietf.org/arch/msg/detnet/lKuo26qd_iKj_vChjOlKreqmXGM/

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

Yes,
https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-detnet-bounded-latency

Other than the WG being made of the IPR, there was no specific discussion.


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

I think the document has good support from the narrow set of WG
participants interested in this problem space.

> (10) Has anyone threatened an appeal or otherwise indicated extreme
> discontent? If so, please summarise 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 http://www.ietf.org/tools/idnits/ and the Internet-Drafts
> Checklist). Boilerplate checks are not enough; this check needs to be
> thorough.

No.

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

Idnits passes, showing only one false warning.

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

N/A. YANG support will be done speperatley based on other work in the WG.

> (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? If such normative
> references exist, what is the plan for their completion?

No.

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

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

No requests are made in the document.

> (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, YANG modules,
> etc.

N/A

> (20) If the document contains a YANG module, has the module been checked
> with any of the recommended validation tools
> (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and
> formatting validation? If there are any resulting errors or warnings,
> what is the justification for not fixing them at this time? Does the
> YANG module comply with the Network Management Datastore Architecture
> (NMDA) as specified in RFC8342?

There are no yang modules.

Request for posting confirmation emailed to previous authors: Balazs Varga , Ehsan Mohammadpour , Janos Farkas , Jean-Yves Le Boudec , Jiayi Zhang , Norman Finn

> 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 1 November 2019.


> (1) What type of RFC is being requested (BCP, Proposed Standard,
> Internet Standard, Informational, Experimental, or Historic)? Why is
> this the proper type of RFC? Is this type of RFC indicated in the title
> page header?

Informational

  This document references specific queuing mechanisms, defined in
  other documents, that can be used to control packet transmission at
  each output port and achieve the DetNet qualities of service.

> 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 references specific queuing mechanisms, defined in
  other documents, that can be used to control packet transmission at
  each output port and achieve the DetNet qualities of service.  This
  document presents a timing model for sources, destinations, and the
  DetNet transit nodes that relay packets that is applicable to all of
  those referenced queuing mechanisms.  Using the model presented in
  this document, it should be possible for an implementor, user, or
  standards development organization to select a particular set of
  queuing mechanisms for each device in a DetNet network, and to select
  a resource reservation algorithm for that network, so that those
  elements can work together to provide the DetNet service.

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

> Document Quality:
> Are there existing implementations of the protocol? Have a significant
> number of vendors indicated their plan to implement the specification?
> 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, YANG 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?

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

> Personnel:

> Who is the Document Shepherd?
Lou Berger

> Who is the Responsible Area Director?
John Scudder

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

The Shepherd reviewed this document as it progressed through the WG as
well as part of Last Call.  All significant comments have been resolved.

One minor issue is outstanding.

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

> (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 document basically says use other standards in a
specific way to ensure interoperability.  There's slightly more left for
further documents than I would have hoped, but the approach of defining
data-plane first is reasonable.

> (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, see
https://mailarchive.ietf.org/arch/msg/detnet/lKuo26qd_iKj_vChjOlKreqmXGM/

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

Yes,
https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-detnet-bounded-latency

Other than the WG being made of the IPR, there was no specific discussion.


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

I think the document has good support from the narrow set of WG
participants interested in this problem space.

> (10) Has anyone threatened an appeal or otherwise indicated extreme
> discontent? If so, please summarise 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 http://www.ietf.org/tools/idnits/ and the Internet-Drafts
> Checklist). Boilerplate checks are not enough; this check needs to be
> thorough.

No.

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

Idnits passes, showing only one false warning.

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

N/A. YANG support will be done speperatley based on other work in the WG.

> (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? If such normative
> references exist, what is the plan for their completion?

No.

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

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

No requests are made in the document.

> (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, YANG modules,
> etc.

N/A

> (20) If the document contains a YANG module, has the module been checked
> with any of the recommended validation tools
> (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and
> formatting validation? If there are any resulting errors or warnings,
> what is the justification for not fixing them at this time? Does the
> YANG module comply with the Network Management Datastore Architecture
> (NMDA) as specified in RFC8342?

There are no yang modules.

Request for posting confirmation emailed to previous authors: Balazs Varga , Ehsan Mohammadpour , Janos Farkas , Jean-Yves Le Boudec , Jiayi Zhang , Norman Finn

Request for posting confirmation emailed to previous authors: Balazs Varga , Ehsan Mohammadpour , Janos Farkas , Jean-Yves Le Boudec , Jiayi Zhang , Norman Finn

Request for posting confirmation emailed to previous authors: Balazs Varga , Ehsan Mohammadpour , Janos Farkas , Jean-Yves Le Boudec , Jiayi Zhang , Norman Finn

Request for posting confirmation emailed to previous authors: Ehsan Mohammadpour , Balazs Varga , Janos Farkas , Norman Finn , Jiayi Zhang , Jean-Yves Le Boudec

Request for posting confirmation emailed to previous authors: Balazs Varga , Janos Farkas , Jean-Yves Le Boudec , Ehsan Mohammadpour , Norman Finn , Jiayi Zhang