Shepherd Write-Up for:
Updates to Using the NETCONF Protocol over Transport Layer Security (TLS)
with Mutual X.509 Authentication (draft-ietf-netconf-over-tls13)
Template from https://datatracker.ietf.org/doc/shepherdwriteup-template/workinggroup
# 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) reviewers, and your
# diligence in completing it is appreciated. The full role of the shepherd is
# further described in RFC 4858. 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
# Does the working group (WG) consensus represent the strong concurrence of a
# few individuals, with others being silent, or did it reach broad agreement?
The working group has reached broad agreement on this document.
# Was there controversy about particular points, or were there decisions where
# the consensus was particularly rough?
Not particularly, but the 1st WGLC did surface the desire to add guidance for
TLS 1.2 implementations as well as TLS 1.3. Prior to the -02 version the I-D
only provided requirements for TLS 1.3 and was not an "updates" I-D. The -02
version added "updates: 7589" and changed the title to "Updates to Using the
NETCONF Protocol over Transport Layer Security (TLS) with Mutual X.509
Authentication". Note that the recommendations are from BCP 195 (RFC 9525).
# 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 one has filed an appeal or otherwise indicated extreme discontent.
# 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 recommends) or elsewhere
# (where)?
The shepherd assumes that implementations using TLS 1.3 exist already, and that
all NETCONF-over-TLS implmentations will migrate to TLS 1.3 in time.
# Additional Reviews
# 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 document relies on the TLS protocol, following the recommendations from
the UTA WG. No other Working Groups or external organizations were solicited
for reviews.
# Describe how the document meets any required formal expert review criteria,
# such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
N/A, as the document doesn’t define anything new requiring expert review.
# If the document contains a YANG module, has the final version of the module
# been checked with any of the recommended validation 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 RFC 8342?
N/A, as the document does not define a YANG module.
# 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.
N/A, as the document does not contain any examples.
# Document Shepherd Checks
# 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
# Several IETF Areas have assembled lists of common issues that their
# reviewers encounter. For which areas have such issues been identified
# and addressed? For which does this still need to happen in subsequent
# reviews?
None. This is a simple updates I-D.
# What type of RFC publication is being requested on the IETF stream (Best
# Current Practice, Proposed Standard, Internet Standard,
# Informational, Experimental or Historic)? Why is this the proper type
# of RFC? Do all Datatracker state attributes correctly reflect this intent?
This document is on the Internet Standard track because it updates an
existing Proposed Standard.
# Have reasonable efforts been made to remind all authors of the intellectual
# property rights (IPR) disclosure obligations described in BCP 79? 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, the WG chairs asked for IPR declarations:
https://mailarchive.ietf.org/arch/msg/netconf/Kyxz5vuG4xVj800QaA2LptqTsHc.
# 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.
# Document any remaining I-D nits in this document. Simply running the idnits
# tool is not enough; please review the "Content Guidelines" on
# authors.ietf.org. (Also note that the current idnits tool generates
# some incorrect warnings; a rewrite is underway.)
Misc Warnings:
-- The document date (10 March 2023) is 152 days in the past. Is this
intentional?
Answer: Yes
Checking references:
== Missing Reference: 'THIS RFC' is mentioned on line 188, but not defined
Answer: Correct the 'THIS RFC' will be updated by IANA.
== Outdated reference: A later version (-09) exists of
draft-ietf-tls-rfc8446bis-05
Answer: Can be addressed if additional IETF LC are received.
-- Possible downref: Normative reference to a draft: ref.
'I-D.ietf-tls-rfc8446bis'
Answer: This I-D can wait for the publication so it will not be a DOWNREF.
== Outdated reference: A later version (-14) exists of
draft-ietf-uta-rfc6125bis-11
Answer: Can be addressed if additional IETF LC are received.
** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446)
Answer: Intentional reference to RFC 5426.
# Should any informative references be normative or vice-versa? See the IESG
# Statement on Normative and Informative References.
All references are normative.
# List any normative references that are not freely available to anyone. Did
# the community have sufficient access to review any such normative
# references?
N/A, as all the references are IETF-documents freely available to everyone.
# Are there any normative downward references (see RFC 3967 and BCP
# 97) that are not already listed in the DOWNREF registry? If so,
# list them.
N/A, as there are no normative downward references.
# 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. For the two works-in-progress refs:
- rfc6125bis is on the 8/10 telechat.
- rfc8446bis has completed WGLC and is awaiting shepherd write-up.
# 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.
Yes this document updates RFC 7589.
- the header, abstract, and intro all indicate this.
# 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).
IANA consideration section was reviewed and appears to be in order.
# 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.
N/A