> 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?
This is an Informational RFC that describes how other standards
documents can be combined. No new mechanisms or recommendations are
defined.
> 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 describes how the Deterministic Networking IP data
plane can operate over a TSN sub-network data plane. This document
does not define new procedures or processes.
> 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?
The document is an Informational document. Early implementations of IP
over DetNet were demonstrated by WG members.
> Personnel:
> Who is the Document Shepherd?
Lou Berger
> 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.
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, assuming published as Informational.
> (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/tddrU04N0JdW2qUgX0-MerAdizQ/
> (8) Has an IPR disclosure been filed that references this document? If
> so, summarize any WG discussion and conclusion regarding the IPR
> disclosures.
No IPR has been disclosed.
> (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 a narrow set of WG participants.
> (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 issues have been fixed.
> (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.
> (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 models.