[Taps] shepherd writeup for -arch draft
Michael Welzl <michawe@ifi.uio.no> Fri, 21 October 2022 07:38 UTC
Return-Path: <michawe@ifi.uio.no>
X-Original-To: taps@ietfa.amsl.com
Delivered-To: taps@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FC4DC1524B8 for <taps@ietfa.amsl.com>; Fri, 21 Oct 2022 00:38:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.007
X-Spam-Level:
X-Spam-Status: No, score=-2.007 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ifi.uio.no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10xJnz77i2AX for <taps@ietfa.amsl.com>; Fri, 21 Oct 2022 00:38:45 -0700 (PDT)
Received: from mail-out02.uio.no (mail-out02.uio.no [IPv6:2001:700:100:8210::71]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CBAAC14F74F for <taps@ietf.org>; Fri, 21 Oct 2022 00:38:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ifi.uio.no; s=key2103; h=To:Date:Message-Id:Subject:Mime-Version:Content-Type:From:Sender :Reply-To:Cc:Content-Transfer-Encoding:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=Zz47ednGaxcNpynTe5vMyoxKirq42972c+stwp1G/Vg=; b=pYJhjBeVJD6lTzpfMOPMdxyAks a19V8+6kQs2LltWXFbS78BKnpp/fdastYhISvkNHJc2QHdi2gMsbgRld5DiTeOJ9Kq+XOdqu885Wk 07RtVYDGIdw9uE0Vx4rd3weSjCrwvZqekyO0wiu4Y4IfHIfbj1QKpckaTQvJIXQt8JzC18f+z7GAM SmgFsv5FBZPFPAJj8niJwpE7mXsZYMWLvL7VzIEUTTOAIsBp48L3WkoWLyZlPmC6hfGEUoUjM9MXT EZ5HwrDB1Ss1cDm4FccpBmEdJF2kzxd3fjbIZ530CH3TVWWqIX2jJo0t/o3iRBxzUqHYsgBrCHlG8 OXUq0OcA==;
Received: from mail-mx01.uio.no ([129.240.10.26]) by mail-out02.uio.no with esmtps (TLS1.2) tls TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from <michawe@ifi.uio.no>) id 1olmc7-008j7Y-29 for taps@ietf.org; Fri, 21 Oct 2022 09:38:43 +0200
Received: from c2371584d.static.as2116.net ([77.88.113.35] helo=smtpclient.apple) by mail-mx01.uio.no with esmtpsa (TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.96) (envelope-from <michawe@ifi.uio.no>) id 1olmc5-0007TN-23 for taps@ietf.org; Fri, 21 Oct 2022 09:38:43 +0200
From: Michael Welzl <michawe@ifi.uio.no>
Content-Type: multipart/alternative; boundary="Apple-Mail=_695E0B72-2787-436A-839E-FC153663DEE1"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
Message-Id: <349AF9DE-8799-4E87-A8F9-140B4C63B589@ifi.uio.no>
Date: Fri, 21 Oct 2022 09:38:41 +0200
To: taps WG <taps@ietf.org>
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-UiO-SPF-Received: Received-SPF: neutral (mail-mx01.uio.no: 77.88.113.35 is neither permitted nor denied by domain of ifi.uio.no) client-ip=77.88.113.35; envelope-from=michawe@ifi.uio.no; helo=smtpclient.apple;
X-UiO-Spam-info: not spam, SpamAssassin (score=-4.9, required=5.0, autolearn=disabled, AWL=-0.100, HTML_MESSAGE=0.001, UIO_HTTP=0.2, UIO_MAIL_IS_INTERNAL=-5)
X-UiO-Scanned: 321FC57199EE730910C15A49B626EFFAE06BE674
X-UiOonly: B9CE7EF87213086895461A3365699DA75E9187FC
Archived-At: <https://mailarchive.ietf.org/arch/msg/taps/Us1ATRtvIF37ajDwGXR3UpXYvg8>
Subject: [Taps] shepherd writeup for -arch draft
X-BeenThere: taps@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "IETF Transport Services \(TAPS\) Working Group" <taps.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/taps>, <mailto:taps-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/taps/>
List-Post: <mailto:taps@ietf.org>
List-Help: <mailto:taps-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/taps>, <mailto:taps-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Oct 2022 07:38:51 -0000
Hi everyone! I’m now done with the shepherd writeup for the -arch draft; see https://datatracker.ietf.org/doc/draft-ietf-taps-arch/shepherdwriteup/ <https://datatracker.ietf.org/doc/draft-ietf-taps-arch/shepherdwriteup/> and below. If any WG contributors have issues with the text here, please speak up now. Cheers, Michael ****************** # 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)? I guess this one doesn't count as a "protocol document". ## 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. This draft has benefited from broad TSV area review within the WG itself, and has had secdir and 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 MIB models, YANG models, media types, URI types etc. are used in the document, and so I think such a formal expert review is not needed. 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]? It does not contain a 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 sections of the document are written in a formal language. ## 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? None of these issues have been identified. Since the document only gives a high-level overview, it is not prone to the typical problems listed for transport documents, such as issues with PDU sizes, port number use, hijacking codepoints, etc. 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? Proposed Standard. Why is this the proper type: the charter of the TAPS WG says that this document shall take that status. The status is correctly reflected in the Datatracker state attribute: "Intended RFC status". I don't see any other related state attribute. 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. Yes; no IPR issues are known. 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, they have all shown their willingness to be listed as such. There are five 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.) The idnits tool complains about an Umlaut "ü". The authors decide to ignore this and leave it up to the RFC Editor. The document has a "Security and Privacy Considerations" Section. According to the idnits tool and https://authors.ietf.org/recommended-content these should be two separate sections. The authors decided to leave this as it is for now and let the ADs decide about this matter. 15. Should any informative references be normative or vice-versa? See the [IESG Statement on Normative and Informative References][16]. No. 16. List any normative references that are not freely available to anyone. Did the community have sufficient access to review any such normative references? None. 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. None. 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. 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]). There are no IANA considerations. 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. There are no IANA considerations. [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] shepherd writeup for -arch draft Michael Welzl