Skip to main content

Shepherd writeup

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

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


# 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:

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


# Document any remaining I-D nits in this document. Simply running the idnits
# tool is not enough; please review the "Content Guidelines" on
# (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

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

Answer: Can be addressed if additional IETF LC are received.

  -- Possible downref: Normative reference to a draft: ref.

Answer: This I-D can wait for the publication so it will not be a DOWNREF.

  == Outdated reference: A later version (-14) exists of

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.