Looks good to me! I think we’ll let the line lengths be handled by the RFC editor.
Best, Tommy > On Oct 20, 2022, at 12:11 AM, Brian Trammell (IETF) <[email protected]> wrote: > > Greetings, all, > > The shepherd writeup for the implementation draft is at > https://datatracker.ietf.org/doc/draft-ietf-taps-impl/shepherdwriteup/ and is > copied below; if any WG contributors have issues with the text here, please > speak up now. > > The only potential issue found by IDNITS with the document are overlong lines > in 6.2 and 6.3; I presume these can be fixed with any other editorial changes > in the RFC Editor process (and indeed, I’m a little confused about how much > we care about line printer formats in 2022), so noted the issue and will > leave a fix to editors’ prerogative. > > Cheers, > > Brian > > > # Document Shepherd Write-Up for Group Documents > > *This version is dated 4 July 2022.* > > Thank you for your service as a document shepherd. Among the responsibilities > is > answering the questions in this write-up to give helpful context to Last Call > and Internet Engineering Steering Group ([IESG][1]) reviewers, and your > diligence in completing it is appreciated. The full role of the shepherd is > further described in [ > RFC 4858 > ][2]. You will need the cooperation of the authors > and editors to complete these checks. > > Note that some numbered items contain multiple related questions; please be > sure > to answer all of them. > > ## Document History > > 1. Does the working group (WG) consensus represent the strong concurrence of a > few individuals, with others being silent, or did it reach broad agreement? > > This document reached broad agreement, with contributions from most active WG > members. > > 2. Was there controversy about particular points, or were there decisions > where > the consensus was particularly rough? > > No. > > 3. 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. > > 4. For protocol documents, are there existing implementations of the contents > of > the document? Have a significant number of potential implementers indicated > plans to implement? Are any existing implementations reported somewhere, > either in the document itself (as [RFC 7942][3] recommends) or elsewhere > (where)? > > This document gives implementation guidelines for the Transport Services > reference architecture and API describe in the -arch and -interface drafts; it > reflects experience gained in one widely deployed production implementation > and two open implementations deployed for research purposes, as listed in > Appendix C. > > ## Additional Reviews > > 5. Do the contents of this document closely interact with technologies in > other > IETF working groups or external organizations, and would it therefore > benefit > from their review? Have those reviews occurred? If yes, describe which > reviews took place. > > The implementation draft has benefited from broad TSV area review within the > WG > itself, and has had artart early review. > > 6. Describe how the document meets any required formal expert review criteria, > such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. > > No formal review necessary. > > 7. If the document contains a YANG module, has the final version of the module > been checked with any of the [recommended validation tools][4] 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 [RFC 8342][5]? > > No YANG module. > > 8. Describe reviews and automated checks performed to validate sections of the > final version of the document written in a formal language, such as XML > code, > BNF rules, MIB definitions, CBOR's CDDL, etc. > > No formal notation, so no automated checks. > > ## Document Shepherd Checks > > 9. Based on the shepherd's review of the document, is it their opinion that > this > document is needed, clearly written, complete, correctly designed, and ready > to be handed off to the responsible Area Director? > > Yes. > > 10. Several IETF Areas have assembled [lists of common issues that their > reviewers encounter][6]. For which areas have such issues been identified > and addressed? For which does this still need to happen in subsequent > reviews? > > The artart early review was relatively thorough; secdir comments apply more to > the companion drafts, as do comments recieved for many of the int area topics > (esp. v6). > > 11. What type of RFC publication is being requested on the IETF stream ([Best > Current Practice][12], [Proposed Standard, Internet Standard][13], > [Informational, Experimental or Historic][14])? Why is this the proper type > of RFC? Do all Datatracker state attributes correctly reflect this intent? > > Informational is appropriate for experience-driven implementation guidelines. > > 12. Have reasonable efforts been made to remind all authors of the > intellectual > property rights (IPR) disclosure obligations described in [BCP 79][7]? To > the best of your knowledge, have all required disclosures been filed? If > not, explain why. If yes, summarize any relevant discussion, including > links > to publicly-available messages when applicable. > > To the best of my knowledge, all appropriate IPR claims (i.e., none) have been > filed. > > 13. Has each author, editor, and contributor shown their willingness to be > listed as such? If the total number of authors and editors on the front > page > is greater than five, please provide a justification. > > Yes; there are five listed authors. > > 14. Document any remaining I-D nits in this document. Simply running the > [idnits > tool][8] is not enough; please review the ["Content Guidelines” on > authors.ietf.org][15]. > (Also note that the current idnits tool generates some incorrect warnings; > a rewrite is underway.) > > Overlong lines in sections 6.2 and 6.3 may need an editorial fix. Reference > issues will be fixed by a document rebuild. > > 15. Should any informative references be normative or vice-versa? See the > [IESG > Statement on Normative and Informative References][16]. > > Verified. > > 16. List any normative references that are not freely available to anyone. Did > the community have sufficient access to review any such normative > references? > > No non-IETF normative references. > > 17. Are there any normative downward references (see [RFC 3967][9] and [BCP > 97][10]) > that are not already listed in the [DOWNREF registry][17]? If so, > list them. > > No. > > 18. Are there normative references to documents that are not ready to be > submitted to the IESG for publication or are otherwise in an unclear state? > If so, what is the plan for their completion? > > No: the companion drafts will be submitted and published together. > > 19. Will publication of this document change the status of any existing RFCs? > If > so, does the Datatracker metadata correctly reflect this and are those RFCs > listed on the title page, in the abstract, and discussed in the > introduction? If not, explain why and point to the part of the document > where the relationship of this document to these other RFCs is discussed. > > No. > > 20. 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 aspects of the document requiring IANA assignments are > associated with the appropriate reservations in IANA registries. Confirm > that any referenced IANA registries have been clearly identified. Confirm > that each newly created IANA registry specifies its initial contents, > allocations procedures, and a reasonable name (see [RFC 8126][11]). > > This document has no actions for IANA, which is appropriate. > > 21. List any new IANA registries that require Designated Expert Review for > future allocations. Are the instructions to the Designated Expert clear? > Please include suggestions of designated experts, if appropriate. > > No new IANA registries > > [1]: > https://www.ietf.org/about/groups/iesg/ > > [2]: > https://www.rfc-editor.org/rfc/rfc4858.html > > [3]: > https://www.rfc-editor.org/rfc/rfc7942.html > > [4]: > https://trac.ietf.org/trac/ops/wiki/yang-review-tools > > [5]: > https://www.rfc-editor.org/rfc/rfc8342.html > > [6]: > https://trac.ietf.org/trac/iesg/wiki/ExpertTopics > > [7]: > https://www.rfc-editor.org/info/bcp79 > > [8]: > https://www.ietf.org/tools/idnits/ > > [9]: > https://www.rfc-editor.org/rfc/rfc3967.html > > [10]: > https://www.rfc-editor.org/info/bcp97 > > [11]: > https://www.rfc-editor.org/rfc/rfc8126.html > > [12]: > https://www.rfc-editor.org/rfc/rfc2026.html#section-5 > > [13]: > https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1 > > [14]: > https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2 > > [15]: > https://authors.ietf.org/en/content-guidelines-overview > > [16]: > > https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/ > > [17]: > https://datatracker.ietf.org/doc/downref/ > > _______________________________________________ > Taps mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/taps _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
