Extension Registry for the Extensible Provisioning Protocol
draft-ietf-regext-ext-registry-epp-09

[Ballot comment]
Thank you very much for addressing my comments. 

I'm leaving the comments below, for historical purposes...

Section 2, general comment:  Remove all of the RFC 8126 text (you don't want to have to update this specification when that RFC gets replaced and yes, there is a 8126bis already), it adds no value, just makes it harder to maintain this specification.

Section 2.2.1, Registrant name and email address:  Wait, one can merely use IETF, and the IESG's email address?  How will this work?  Don't we really want a person who knows more about the registration?  For some other registries, it is acceptable to use a working group name and email address (Mediatypes, for example).

Section 2.2.3, para 2 and 3:  This is incomprehensible.  Registrations that were created w/ IETF and w/out IETF consensus can be approved by the IESG?  But external registrations can just be summarily deactivated by the DEs?

Section 5:  I'm baffled by this section.  This is a process specification, why are there operational considerations? Everything that exists in this section could be either moved elsewhere or removed. Para 1 belongs in Section 1, para 2 belongs in Section 2 with the rest of the DE instructions, para 3 can be removed.

[Ballot comment]
Thanks to the author and the WG for this document.

< moving this from DISCUSS to COMMENTS after Med's explanation during the telechat >
I have a discussion point that should be trivial to address. This has got to do with the part that details about the IANA registries, format of requests, DE guidance, etc. should be under the IANA Considerations section per RFC8126. A trivial way to address this is to move all the content from under Section 2 into the IANA Considerations.

I also have a few comments to offer:

1) Doesn't the following belong under DE guidance?

An English language version of the extension specification MUST be referenced from the registry, though non- English versions of the specification may also be provided. Note that Section 2.1 of RFC 3735 [RFC3735] (or its future replacement) provides specific guidelines for documenting EPP extensions.

2) Regarding the following text:

"For this registry, acceptable specifications include RFC documents and proprietary specifications that meet the "permanent and readily available" requirement described in Section 4.6 of [RFC8126]. Internet-Draft documents are not acceptable specifications for this registry."

FYI - there is a 8126bis in the works that provides more flexibility in this matter (it is still work-in-progress). Please check https://www.ietf.org/archive/id/draft-ietf-ianabis-rfc8126bis-01.html#section-4.6.1.1
I am not suggesting that anything be changed though; just sharing in case this was not already known.

3) Regarding the following text:

"If the specification for an extension is an IETF Standards Track document, no review is required by the designated expert."

Is that "document" or more specifically "RFC"? I ask because I-Ds are not considered for allocation.

[Ballot comment]
Thanks to the author for the effort on the draft.

Thanks to Tero for his SECDIR review.  As Deb mentioned, the draft would improve taking the feedback into account.


I support the discuss positions of Deb, Mahesh, and Roman.

[Ballot comment]
I support the DISCUSS from Mahesh.

Regarding the considerations for the DE, I have a few additional comments.

Section 2.2.1. Required Information

"Name of Extension: A case-insensitive, ASCII text string that contains the name of the extension specification and does not overlap with an existing registered extension."

Should checking that this requirement is met be added to the instructions to the DE?

[Ballot discuss]
While I have divided my comments up into those I think are 'discuss worthy' and 'mere comments', I do believe all of my comments should be considered carefully.  The goal of this process specification is to have a clear and concise set of instructions for those with submissions/changes to this registry and the DEs who will be doing the work to consider them.

Many thanks to Tero Kivinen for their secdir review.  I will also state that I agree with his points about: the status of the specification, the format of the references, the inclusion of '(or its future replacement)' - it should be deleted.

Process specifications are not protocol documents.  There is no reason to make it PS when BCP works just fine - and especially when BCP was working group consensus. (Even if there is one example process specification that is standards track, the vast majority are not.)

Section 2.1, second para, last sentence:  Why aren't Internet Drafts are not acceptable?  Do they not meet the 'permanent and readily available' requirement?  What if someone takes the contents of an I-D, posts it to a site that is considered 'permanent and readily available', can it be used then? This deviation from what is normally acceptable for 'specification required' needs to be explained.

Section 2.1.1, para 2:  Under what circumstances is it ok for a DE with a COI not defer?  The SHOULD is currently naked, without rationale about when it is ok to ignore it.

Section 2.2.3, para 1:  How are requests to modify or deactivate registrations authenticated?  Can anyone just masquerade as the POC make the request?

Section 4:  Consider how an unauthenticated attacker could disrupt this registry.  Email addresses are super easy to spoof, what keeps this from happening to either modify or deactivate an entry?

[Ballot comment]
Section 2, general comment:  Remove all of the RFC 8126 text (you don't want to have to update this specification when that RFC gets replaced and yes, there is a 8126bis already), it adds no value, just makes it harder to maintain this specification.

Section 2.2.1, Registrant name and email address:  Wait, one can merely use IETF, and the IESG's email address?  How will this work?  Don't we really want a person who knows more about the registration?  For some other registries, it is acceptable to use a working group name and email address (Mediatypes, for example).

Section 2.2.3, para 2 and 3:  This is incomprehensible.  Registrations that were created w/ IETF and w/out IETF consensus can be approved by the IESG?  But external registrations can just be summarily deactivated by the DEs?

Section 5:  I'm baffled by this section.  This is a process specification, why are there operational considerations? Everything that exists in this section could be either moved elsewhere or removed. Para 1 belongs in Section 1, para 2 belongs in Section 2 with the rest of the DE instructions, para 3 can be removed.

[Ballot discuss]
** Section 2.1.1
  The IESG should appoint a primary designated expert and a small
  number of individuals (perhaps 3 - 5) to serve as backup designated
  experts as described in Section 5.2 of [RFC8126].  The primary
  designated expert is responsible for conducting all reviews requested
  by IANA.  The secondary designated experts are responsible for
  conducting reviews as a consensus-based group if the primary
  designated expert is unavailable.  In cases where a registration
  decision could be perceived as creating a conflict of interest for a
  particular Designated Expert, that Expert SHOULD defer to the
  judgment of the other Experts.  The designated experts MUST use the
  existing regext mailing list (regext@ietf.org) or its successor for
  public discussion of registration requests.

This language above is a slight reinterpretation of Section 5.2, RFC8126.  Is that really necessary as the following are underspecified:

-- What is a “consensus-based group” (e.g., rough consensus, majority, unanimity)

-- When should a DE NOT recuse if there is a COI?

-- Is there a requirement being set on the IESG that it has to approved more than one DE here (as the language reads, the “IESG should …”)?

** Section 2.1.1
  Should they decline to do so, perceived similarity SHOULD NOT be a
  sufficient reason for rejection as long as all other requirements are
  met.

When is “perceived similarity” a sufficient reason to reject, as the guidance says similarity is sometimes adequate justification (since MUST NOT is not used)?

** Section 2.2.3
  IESG Approval (Section 4.10 of [RFC8126]) is REQUIRED to remove or
  deactivate registrations created through IETF consensus.

What does it mean to “deactivate” a registration?

[Ballot comment]
** Section 2.1.1. Are these three statement providing unique normative guidance?
  The designated experts MUST use the
  existing regext mailing list (regext@ietf.org) or its successor for
  public discussion of registration requests.
…
  The results of the evaluation MUST be shared via email with the
  registrant and the regext mailing list or its successor.
…
  The designated experts MUST make an
  explicit decision and that decision MUST be shared via email with the
  registrant and the regext mailing list or its successor.

** Section 2.2.3
  On receipt of a registration request, IANA will initiate review by
  the designated expert(s), who will evaluate the request using the
  criteria in Section 2.1.1 in consultation with the current working
  group mailing list focused on the development of EPP extensions if
  such working group exists.

Why is this text needed.  It is restating what IANA already does for “Specification Required”.

[Ballot discuss]
Thanks to the author and the WG for this document.

I have a discussion point that should be trivial to address. This has got to do with the part that details about the IANA registries, format of requests, DE guidance, etc. should be under the IANA Considerations section per RFC8126. A trivial way to address this is to move all the content from under Section 2 into the IANA Considerations.

[Ballot comment]
I also have a few comments to offer:

1) Doesn't the following belong under DE guidance?

An English language version of the extension specification MUST be referenced from the registry, though non- English versions of the specification may also be provided. Note that Section 2.1 of RFC 3735 [RFC3735] (or its future replacement) provides specific guidelines for documenting EPP extensions.

2) Regarding the following text:

"For this registry, acceptable specifications include RFC documents and proprietary specifications that meet the "permanent and readily available" requirement described in Section 4.6 of [RFC8126]. Internet-Draft documents are not acceptable specifications for this registry."

FYI - there is a 8126bis in the works that provides more flexibility in this matter (it is still work-in-progress). Please check https://www.ietf.org/archive/id/draft-ietf-ianabis-rfc8126bis-01.html#section-4.6.1.1
I am not suggesting that anything be changed though; just sharing in case this was not already known.

3) Regarding the following text:

"If the specification for an extension is an IETF Standards Track document, no review is required by the designated expert."

Is that "document" or more specifically "RFC"? I ask because I-Ds are not considered for allocation.

[Ballot discuss]
Section 2.1.1, paragraph 1
>    If the specification for an extension is an IETF Standards Track
>    document, no review is required by the designated expert.

It appears that the author has already agreed to remove this paragraph
from the document. This DISCUSS has been put in to track and make sure
that it is addressed in the next version.

As noted by the SECDIR reviewer (Tero Kivinen, May 28, 2026, thanks Tero),
IANA normally requests a DE review regardless of RFC status. This sentence
could be read as an instruction to IANA to skip that request, contrary to
standard practice.

[Ballot comment]
Section 2.1.1, paragraph 1
>    The IESG should appoint a primary designated expert and a small
>    number of individuals (perhaps 3 - 5) to serve as backup designated
>    experts as described in Section 5.2 of [RFC8126].  The primary
>    designated expert is responsible for conducting all reviews requested
>    by IANA.  The secondary designated experts are responsible for
>    conducting reviews as a consensus-based group if the primary
>    designated expert is unavailable.  In cases where a registration
>    decision could be perceived as creating a conflict of interest for a
>    particular Designated Expert, that Expert SHOULD defer to the
>    judgment of the other Experts.  The designated experts MUST use the
>    existing regext mailing list (regext@ietf.org) or its successor for
>    public discussion of registration requests.

A SHOULD permits an expert with a perceived conflict of interest to decide
not to recuse in the above paragraph. Conflict-of-interest provisions
in governance contexts are typically mandatory. MUST would better reflect
the intent. I support Éric Vyncke who made a similar ballot comment.

Section 5, paragraph 1
>    Section 2 includes provisions for modifying and deleting existing
>    registration entries by registrants.  Such requests MUST NOT be
>    granted if the requested action has operational implication on other
>    entities that deploy that extension, assuming that those entities can
>    be identified.  This guidance can be overridden if the requested
>    action MUST be taken to comply with actions that are beyond the
>    control of the experts and/or IANA, e.g., to comply with legal
>    actions.  Note that the registry does not include a history mechanism
>    and there is no way to track deleted entries once they have been
>    removed.

The second sentence in this paragraph makes the prohibition conditional:
if affected parties cannot be identified, the constraint does not apply
and the removal could proceed despite potential operational impact.
If this is the intended policy, a brief rationale should be provided.
If not, the language should be tightened.

No reference entries found for these items, which were mentioned in the text:
[RFC5730].

-------------------------------------------------------------------------------
NIT
-------------------------------------------------------------------------------

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 1, paragraph 1
>    RFCs 3735 [RFC3735] and 5730 RFC5730 do not describe how extension
>    development can be managed and coordinated.  This has led to a
>    situation in which server operators can develop different extensions
>    to address similar needs, such as the provisioning of Value Added Tax
>    (VAT) information.  Clients then need to support multiple extensions
>    that serve similar purposes, and interoperability suffers as a
>    result.

s/RFC5730/[RFC5730]/

You are missing the square brackets.

Section 2.1.1, paragraph 1
>    Extensions should be evaluated for architectural soundness using the
>    guidelines described in RFC 3735 [RFC3735] (or its future
>    replacement, including the Security Considerations section of that
>    document.  Expert evaluation should explicitly include consideration
>    of the privacy consequences of proposed extensions, and, at a
>    minimum, ensure that any privacy considerations are fully documented
>    in the relevant specification(s).

s/(or its future replacement/(or its future replacement)/)

You are missing the closing parenthesis.

[Ballot comment]
Thanks for the work done in this document.

The guidance for the Designated Experts is at an unusual location, but this is OK.

# Section 2.1.1

Why not a "MUST" in `that Expert SHOULD defer to the judgment of the other Experts` ? I was about to ballot a blocking DISCUSS on this issue.

# Section 3

Strongly suggest to add an informative URL for the newly created registry.

IANA has questions about the actions requested in the IANA Considerations section of this document.

IANA understands that, upon approval of this document, there are two actions to complete. Both actions affect the existing Extensions for the Extensible Provisioning Protocol (EPP) located at

https://www.iana.org/assignments/epp-extensions/

Actions:

1) The reference for the registry itself will be changed from [RFC7451] to [ RFC-to-be ].

2) For all registrations that don't list an RFC or I-D in the registration's "Reference" field, IANA will change the "Document Status" field entry from "Informational" to "Other." A list of affected registrations is included below.

IANA Question --> IANA notes that [ RFC-to-be, Section 2.1 ] puts a language restriction on any specification that would request registration in this registry. Should a note be added to the top of the registry?

IANA Question --> IANA notes that [ RFC-to-be, Section 2.1 ] suggests that Internet-Draft document are not acceptable specifications for the registry. However, "Verification Code Extension for the Extensible Provisioning Protocol (EPP)" lists expired I-D draft-ietf-regext-verificationcode-06 as its only reference. What should happen to this existing registration? Should "Internet-Draft documents are not acceptable specifications for this registry" be changed to something like "Internet-Draft documents are not acceptable specifications for future registrations, barring use of the RFC 7120 early allocation procedure"? (RFC 7120 is available to Specification Required registrations. IANA does request expert approval in addition to chair and AD approval for this type of early allocation.)

IANA Question --> If "Verification Code Extension for the Extensible Provisioning Protocol (EPP)" can remain in place, can its Document Status still be listed as "Informational"? (If not, we would also ask whether early allocations could have their status listed as "Informational" or "Standards Track" rather than "Other.")

IANA Question --> [ RFC-to-be, Section 2.2.1 ] says, "The designated experts MUST use the existing regext mailing list (regext@ietf.org) or its successor for public discussion of registration requests." Should a note be added to the top of the registry?

List of registrations that will have their Document Status changed from "Informational" to "Other":

Common Object Attribute (COA) Extension for the Extensible Provisioning Protocol (EPP) Informational
Namestore Extension Mapping for the Extensible Provisioning Protocol (EPP) Informational
RGP Poll Mapping for the Extensible Provisioning Protocol (EPP) Informational
ConsoliDate Mapping for the Extensible Provisioning Protocol Informational
IDN Language Tag for the Extensible Provisioning Protocol (EPP) Informational
Extensible Provisioning Protocol Mapping: WhoWas Informational
Extensible Provisioning Protocol Mapping: Email Forwarding Informational
Extensible Provisioning Protocol Mapping: Defensive Registration Informational
Extensible Provisioning Protocol Mapping: NameWatch Informational
Extensible Provisioning Protocol Mapping: Personal Registration Informational
Extensible Provisioning Protocol Mapping: Suggestion Informational
Whois Info Extension for the Extensible Provisioning Protocol (EPP) Informational
Extensible Provisioning Protocol Extension Mapping: Jobs Contact Informational
Low Balance Mapping for the Extensible Provisioning Protocol (EPP) Informational
Premium Domain Extension for the Extensible Provisioning Protocol (EPP) Informational
Balance Mapping for the Extensible Provisioning Protocol (EPP) Informational
Registry Mapping for the Extensible Provisioning Protocol (EPP) Informational
Related Domain Extension for the Extensible Provisioning Protocol (EPP) Informational
DK Hostmaster local data extensions Informational
.at EPP Verification Extension Informational
Domain Charge Extension for the Extensible Provisioning Protocol (EPP) Informational
Finance Mapping for the Extensible Provisioning Protocol (EPP) Informational
Internationalized Domain Name Mapping for the Extensible Provisioning Protocol (EPP) Informational
Swedish Internet Foundation EPP Extensions Informational
Swedish Internet Foundation Registry Lock Extension Informational
CIRA Fury RGP Information for the Extensible Provisioning Protocol (EPP) Informational
CIRA Fury 2.1 Extension for the Extensible Provisioning Protocol (EPP) Informational
IDN EPP Extension for the TANGO Registration System Informational

We understand that these are the only actions required upon approval of this document.

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

During the WGLC there were six participants in favor, a few suggestions, and no
objections. This is typical for regext and typically signifies broad consensus.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

As mentioned above, there were a few suggestions which the author accepted, but
no controversy.

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

Not applicable.

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

Not applicable.

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.

Not applicable.

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

Not applicable.

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.

Not applicable.

## 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, this document solves significant issues with the existing specification,
and does so clearly and correctly.

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?

Not applicable.

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. The WG concluded that it should be a BCP, as it defines an
IETF process, and that RFC 7451 (the document it obsoletes) was published under
the wrong category (Informational). However, this was changed to Proposed
Standard during AD review.

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.

THe author is aware of his IPR disclosure obligations.

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, the author is willing to be listed as such.

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

idnits3 complains about the References section but it looks fine to me, I
suspect this is a false positive or a minor XML issue.

The document date could not be determined, but this seems like a very minor
issue.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

None.

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.

There are downrefs to RFC 7451 (which this document obsoletes) and RFC 3735.
These are acceptable given the guidance found in RFC 3967, which permits
downrefs in BCP documents that describe best current practices for informational
specifications.

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?

None.

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.

This document will obsolete RFC 7451. The document and the Datatracker metadata
correctly reflects this.

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]).

The IANA Considerations section asks IANA to make updates to the EPP Extension
Registry that are consistent with the rest of the document. All aspects of the
document requiring IANA assignments are associated with the appropriate
reservations in IANA registries which are clearly identified. No new registries
are created by this document.

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.

None. This document updates the instructions to the Designated Expert of the EPP
Extension Registry, and is intended to clarify them.

[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://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/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/

The following Last Call announcement was sent out (ends 2026-05-26):

From: The IESG
To: IETF-Announce
CC: draft-ietf-regext-ext-registry-epp@ietf.org, gavin.brown@icann.org, mohamed.boucadair@orange.com, regext-chairs@ietf.org, regext@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Extension Registry for the Extensible Provisioning Protocol) to Proposed Standard


The IESG has received a request from the Registration Protocols Extensions WG
(regext) to consider the following document: - 'Extension Registry for the
Extensible Provisioning Protocol'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2026-05-26. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  The Extensible Provisioning Protocol (EPP) includes features to add
  functionality by extending the protocol.  It does not, however,
  describe how those extensions are maintained.  This document
  describes a procedure for the registration and management of
  extensions to EPP, and it specifies a format for an IANA registry to
  record those extensions.  If approved, this document obsoletes RFC
  7451.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-regext-ext-registry-epp/



No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc3735: Guidelines for Extending the Extensible Provisioning Protocol (EPP) (Informational - Internet Engineering Task Force (IETF) stream)

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

During the WGLC there were six participants in favor, a few suggestions, and no objections. This is typical for regext and typically signifies broad consensus.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

As mentioned above, there were a few suggestions which the author accepted, but no controversy.

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

Not applicable.

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

Not applicable.

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.

Not applicable.

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

Not applicable.

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.

Not applicable.

## 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, this document solves significant issues with the existing specification, and does so
clearly and correctly.

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?

Not applicable.

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?

Best Current Practice. The WG concluded that it should be a BCP, as it defines an IETF process, and that RFC 7451 (the document it obsoletes) was published under the wrong category.

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.

THe author is aware of his IPR disclosure obligations.

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, the author is willing to be listed as such.

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

idnits3 complains about the References section but it looks fine to me, I suspect this is a false positive or a minor XML issue.

The document date could not be determined, but this seems like a very minor issue.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

None.

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.

There are downrefs to RFC 7451 (which this document obsoletes) and RFC 3735. These are acceptable given the guidance found in RFC 3967, which permits downrefs in BCP documents that describe best current practices for informational specifications.

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?

None.

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.

This document will obsolete RFC 7451. The document and the Datatracker metadata correctly reflects this.

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]).

The IANA Considerations section asks IANA to make updates to the EPP Extension Registry that are consistent with the rest of the document. All aspects of the document requiring IANA assignments are associated with the appropriate reservations in IANA registries which are clearly identified. No new registries are created by this document.

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.

None. This document updates the instructions to the Designated Expert of the EPP Extension Registry, and is intended to clarify them.

[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://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/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/

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

During the WGLC there were six participants in favor, a few suggestions, and no objections. This is typical for regext and typically signifies broad consensus.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

As mentioned above, there were a few suggestions which the author accepted, but no controversy.

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

Not applicable.

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

Not applicable.

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.

Not applicable.

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

Not applicable.

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.

Not applicable.

## 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, this document solves significant issues with the existing specification, and does so
clearly and correctly.

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?

Not applicable.

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?

Best Current Practice. The WG concluded that it should be a BCP, as it defines an IETF process, and that RFC 7451 (the document it obsoletes) was published under the wrong category.

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.

THe author is aware of his IPR disclosure obligations.

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, the author is willing to be listed as such.

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

idnits3 complains about the References section but it looks fine to me, I suspect this is a false positive or a minor XML issue.

The document date could not be determined, but this seems like a very minor issue.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

None.

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.

There are downrefs to RFC 7451 (which this document obsoletes) and RFC 3735. These are acceptable given the guidance found in RFC 3967, which permits downrefs in BCP documents that describe best current practices for informational specifications.

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?

None.

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.

This document will obsolete RFC 7451. The document and the Datatracker metadata correctly reflects this.

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]).

The IANA Considerations section asks IANA to make updates to the EPP Extension Registry that are consistent with the rest of the document. All aspects of the document requiring IANA assignments are associated with the appropriate reservations in IANA registries which are clearly identified. No new registries are created by this document.

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.

None. This document updates the instructions to the Designated Expert of the EPP Extension Registry, and is intended to clarify them.

[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://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/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/

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

During the WGLC there were six participants in favor, a few suggestions, and no objections. This is typical for regext and typically signifies broad consensus.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

As mentioned above, there were a few suggestions which the author accepted, but no controversy.

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

Not applicable.

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

Not applicable.

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.

Not applicable.

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

Not applicable.

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.

Not applicable.

## 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, this document solves significant issues with the existing specification, and does so
clearly and correctly.

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?

Not applicable.

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?

Best Current Practice. The WG concluded that it should be a BCP, as it defines an IETF process, and that RFC 7451 (the document it obsoletes) was published under the wrong category.

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.

THe author is aware of his IPR disclosure obligations.

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, the author is willing to be listed as such.

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

idnits3 complains about the References section but it looks fine to me, I suspect this is a false positive or a minor XML issue.

The document states that it obsoletes RFC 7451, but doesn't explicitely mention it in the  section. I have confirmed with the author that this is an oversight, and I very much doubt that the WG would object to its inclusion at this point.

The document date could not be determined, but this seems like a very minor issue.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

None.

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.

There are downrefs to RFC 7451 (which this document obsoletes) and RFC 3735. These are acceptable given the guidance found in RFC 3967, which permits downrefs in BCP documents that describe best current practices for informational specifications.

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?

None.

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.

This document will obsolete RFC 7451. The Datatracker metadata correctly reflects this, however, as noted above, it is not discussed in the abstract.

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]).

The IANA Considerations section asks IANA to make updates to the EPP Extension Registry that are consistent with the rest of the document. All aspects of the document requiring IANA assignments are associated with the appropriate reservations in IANA registries which are clearly identified. No new registries are created by this document.

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.

None. This document updates the instructions to the Designated Expert of the EPP Extension Registry, and is intended to clarify them.

[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://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/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/

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

During the WGLC there were six participants in favor, a few suggestions, and no objections. This is typical for regext and typically signifies broad consensus.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

As mentioned above, there were a few suggestions which the author accepted, but no controversy.

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

Not applicable.

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

Not applicable.

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.

Not applicable.

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

Not applicable.

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.

Not applicable.

## 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, this document solves significant issues with the existing specification, and does so
clearly and correctly.

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?

Not applicable.

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?

Best Current Practice. The WG concluded that it should be a BCP, as it defines an IETF process, and that RFC 7451 (the document it obsoletes) was published under the wrong category.

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.

THe author is aware of his IPR disclosure obligations.

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, the author is willing to be listed as such.

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 introduction section is missing the BCP 14 statement clarifying the significance of uppercase keywords. I have confirmed with the author that this is an oversight, and I very much doubt that the WG would object to its inclusion at this point.

idnits3 complains about the References section but it looks fine to me, I suspect this is a false positive or a minor XML issue.

The document states that it obsoletes RFC 7451, but doesn't explicitely mention it in the  section. As with the BCP 14 statement, this is an oversight.

The document date could not be determined, but this seems like a very minor issue.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

None.

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.

There are downrefs to RFC 7451 (which this document obsoletes) and RFC 3735. These are acceptable given the guidance found in RFC 3967, which permits downrefs in BCP documents that describe best current practices for informational specifications.

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?

None.

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.

This document will obsolete RFC 7451. The Datatracker metadata correctly reflects this, however, as noted above, it is not discussed in the abstract.

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]).

The IANA Considerations section asks IANA to make updates to the EPP Extension Registry that are consistent with the rest of the document. All aspects of the document requiring IANA assignments are associated with the appropriate reservations in IANA registries which are clearly identified. No new registries are created by this document.

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.

None. This document updates the instructions to the Designated Expert of the EPP Extension Registry, and is intended to clarify them.

[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://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/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/