Extensible Provisioning Protocol (EPP) Transport over QUIC
draft-ietf-regext-epp-quic-12

[Ballot comment]
Thank you for submitting this document, I have the following (non-blocking) comments:

## I couldn't really understand why this RFC is specifying transport over QUIC, but expect there was some specific need. I think that ought to be clearer.
GF: DONE in rev -12

## The security properties of QUIC do differ to those of TLS/TCP, in as much as QUIC us an encrypted transport - see 21.1 in the security considerations of RFC9000.
GF: DONE in rev -12

# Please address the issues raised by Zahed as a part of his TSVART review:

## Even though section 3 explains it the correct way, in section 6, it says -

      The EoQ Connection Start Packet is written by the client after creating
      a QUIC stream to signal to the server to create the QUIC stream.

  This is inaccurate when client-initiated bi-directional streams are used. The
  server does not create streams; it just uses the streams created by the
  client. The snipped emphasizes that "signal to the server to create stream "
  that needs to be fixed. If there are no specific explanations, then it would
  suggest to rewrite the sentence to --

    The EoQ Connection Start Packet is sent by the client after creating a
    QUIC connection to signal to the server, on the client-initiated stream,
    respond with EPP.
GF: DONE in rev -12

# Nits -

- Section 7 : the references to RFC9000 are out of order in the description of
"Stateful Nature". RFC 9000 section 2 is about streams and section 5 is about
connections.
GF: DONE in rev -12

I thank you for addressing my discussion topics in rev -12.
Best wishes,
Gorry

[Ballot comment]
Seeing all the helpful points already raised by others in their reviews, the only additional comment I have is with respect to the reuse of port 700.

I see the WG discussed and reached consensus to reassign the reference for UDP port 700 to the EPP-over-QUIC specification rather than assign a new port number, citing the absence of any known legacy UDP implementations. In order to safely accommodate any implementation that may exist now or in the future, it might be helpful to add a reference to RFC 9443 and mention that this mechanism can be used to demultiplex EPP over UDP from EPP over QUIC.

[Ballot comment]
Thanks to Mike O. for the SECDIR review.

Thanks for the well written draft.

* Please consider protections against excessively long messages as noted in Mike's SECDIR review.

* Is a “MUST” with an “unless” really a MUST?
Section 3 ¶2: `By default, an EPP server MUST listen for QUIC connection requests on a well-known UDP port number assigned by IANA (see Section 9.2), unless there is a mutual agreement to use another port number.`

* I will echo the comment of other ADs - I'm not sure what the support of multiple QUIC streams does or why its useful; parallel processing on the EPP server maybe?

* Most of my other comments are already covered by other ADs.

The port expert wrote,"This reassignment seems fine if the protocol explains clearly how QUIC could co-exist on that port with DTLS," adding today that this still needs to be addressed. He continued, "The example I found is port 853. However, I strongly encourage use of a new user port instead. The distinction associated with system ports was deprecated per RFC7605, and we should not continue to try to deploy new services that make any assumptions about such port numbers." The TLS ALPN registration was approved.

[Ballot discuss]
# Andy Newton, ART AD, comments for draft-ietf-regext-epp-quic-10
CC @anewton1998

* line numbers:
  - https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-regext-epp-quic-10.txt&submitcheck=True

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Discuss

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/,
a DISCUSS ballot is just a request to have a discussion on the following topics.

### MUST or must

389       Batch-oriented processing (combining multiple EPP commands in a
390       single data unit) is not permitted.  Each EPP data unit must
391       contain a single EPP message.

Should this be a normative MUST?

### Server Requirement for Client Fall Back

407 8.1.  Clients Fall Back with Management of Multiple Transport

409   If the establishment of an EoQ connection fails, clients MAY attempt
410   to fall back to EPP over TCP as specified in [RFC5734], depending on
411   local deployment and security policy.  It is up to clients to
412   determine the mix of transports that best meets their business needs.

While it is up to the client to determine if fall back is necessary, what are the requirements on the server?
If a client falls back to EoT but the server doesn't have EoT, isn't that an interoperability issue?
I think this can be solved with the following addition:

    Servers MUST offer service over TCP (EoT [RFC5374]) for clients that fall back to TCP.

[Ballot comment]

# Éric Vyncke INT AD comments for draft-ietf-regext-epp-quic-10
CC @evyncke

Thank you for the work put into this document.

Special thanks to Med Boucadair, the responsible AD, to point me to the last paragraph of section 7 (which could use a MUST though) to handle my previously [DISCUSS ballot](https://mailarchive.ietf.org/arch/msg/regext/4zJiC7I3GlGPdjPuVqXi5smwYpQ/)

Please find below some non-blocking COMMENT points/nits (replies would be appreciated even if only for my own education).

I hope that this review helps to improve the document,

Regards,

-éric

Note: this ballot comments follow the Markdown syntax of https://github.com/mnot/ietf-comments/tree/main, i.e., they can be processed by a tool to create github issues.

## COMMENTS (non-blocking)

### Gorry's DISCUSS

I second Gorry's DISCUSS issues as they are sensible

### Why QUIC in Section 1

I failed to find why using QUIC is useful, especially with `EPP sessions use a single QUIC stream for all command and response exchanges` especially when reading section 3 `This means that a single QUIC connection may support multiple EoQ sessions.` The introduction should probably state that there could be several EPP sessions (for different domains ?) over a single QUIC connection.

### Section 3

`As shown in Figure 1 in Section 4,` it is painful for the reader to scroll down. Suggest moving the figure in section 3.

s/on a well-known UDP port number assigned by IANA/on *the* well-known UDP port number assigned by IANA/ (if there is only one)

### Section 4

Why not a "MUST" in `Absent local policy, a server SHOULD end an EoQ session and close the QUIC stream if a well-formed command is not received within the time limit` ?

Also note https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/ (and thanks for the guidance provided for previous "SHOULD")

### Section 5

s/The 32 bits total length/The *32-bit* total length/

### Use of SVG graphics

To make a much nicer HTML rendering, suggest using the aasvg tool to generate SVG graphics. It is worth a try especially if the I-D uses the Kramdown file format ;-)

[Ballot discuss]

# Éric Vyncke INT AD comments for draft-ietf-regext-epp-quic-10
CC @evyncke

Thank you for the work put into this document.

Please find below some blocking DISCUSS points (trivial to address), some non-blocking COMMENT points/nits (replies would be appreciated even if only for my own education).

Special thanks to  for the shepherd's detailed write-up including the WG consensus and the justification of the intended status.

I hope that this review helps to improve the document,

Regards,

-éric

Note: this ballot comments follow the Markdown syntax of https://github.com/mnot/ietf-comments/tree/main, i.e., they can be processed by a tool to create github issues.

## DISCUSS (blocking)

As noted in https://datatracker.ietf.org/doc/statement-iesg-handling-ballot-positions-20220121/, a DISCUSS ballot is a request to have a discussion on the points below; I really think that the document would be improved with a change here, but can be convinced otherwise.

### Section 6

Please state the expected behavior of the EPP server when `The length of a valid data unit MUST be 24 octets` is not correct, even if somehow obvious, it should be stated in a PS.

[Ballot comment]

## COMMENTS (non-blocking)

### Gorry's DISCUSS

I second Gorry's DISCUSS issues as they are sensible

### Why QUIC in Section 1

I failed to find why using QUIC is useful, especially with `EPP sessions use a single QUIC stream for all command and response exchanges` especially when reading section 3 `This means that a single QUIC connection may support multiple EoQ sessions.` The introduction should probably state that there could be several EPP sessions (for different domains ?) over a single QUIC connection.

### Section 3

`As shown in Figure 1 in Section 4,` it is painful for the reader to scroll down. Suggest moving the figure in section 3.

s/on a well-known UDP port number assigned by IANA/on *the* well-known UDP port number assigned by IANA/ (if there is only one)

### Section 4

Why not a "MUST" in `Absent local policy, a server SHOULD end an EoQ session and close the QUIC stream if a well-formed command is not received within the time limit` ?

Also note https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/ (and thanks for the guidance provided for previous "SHOULD")

### Section 5

s/The 32 bits total length/The *32-bit* total length/

### Use of SVG graphics

To make a much nicer HTML rendering, suggest using the aasvg tool to generate SVG graphics. It is worth a try especially if the I-D uses the Kramdown file format ;-)

[Ballot discuss]
Please find below a blocking DISCUSS points (easy to address), some non-blocking COMMENT points/nits (replies would be appreciated even if only for my own education).

As noted in https://datatracker.ietf.org/doc/statement-iesg-handling-ballot-positions-20220121/, a DISCUSS ballot is a request to have a discussion on the point below, which I expect will be very easy to resolve:

## The current text says: "Operators are encouraged to provision network paths with appropriate MTU sizes to avoid packet fragmentation for EPP message delivery."
- I don't really understand what this is asking for and what is needed, please clarify.
-  When I started reading I assumed this was the standard QUIC datagram size (as in section 14), but maybe this means to say more, or I was just thrown by the term "MTU" here?
- And please explain what is the fragmentation described here?

## Please consider and respond to Zahed's review comment:
RFC 9000 defines max_ideal_timeout (
https://datatracker.ietf.org/doc/html/rfc9000#idle-timeout ), section 3 of this
draft does not relate to usage of that max_ideal_timeout but states -"the
server MAY end the QUIC connection immediately". How is it supposed to work
with the max_ideal_timeout if that is negotiated at the connection setup?


## Section 4 says -

        A server SHOULD limit a client to a maximum number of QUIC streams per
        QUIC connection based on server capabilities and operational load.

  How do you do that via RFC9000? Or is this something new? If you are using
  RFC9000, then add a reference to the concurrency control described in
  RFC9000. or explain how your intent to enforce the SHOULD.

## Section 10.6 says -

    EoQ servers MUST utilize the QUIC Retry Packet mechanism described in
    Section 8.1.2 of [RFC9000].

As RFC9000 does not apply MUST to use QUIC Retry Packets for address
validation, what is the justification for the MUST here?

[Ballot comment]
Thank you for submitting this document, I have the following (non-blocking) comments:

## I couldn't really understand why this RFC is specifying transport over QUIC, but expect there was some specific need. I think that ought to be clearer.

## The security properties of QUIC do differ to those of TLS/TCP, in as much as QUIC us an encrypted transport - see 21.1 in the security considerations of RFC9000.

# Please address the issues raised by Zahed as a part of his TSVART review:

## Even though section 3 explains it the correct way, in section 6, it says -

      The EoQ Connection Start Packet is written by the client after creating
      a QUIC stream to signal to the server to create the QUIC stream.

  This is inaccurate when client-initiated bi-directional streams are used. The
  server does not create streams; it just uses the streams created by the
  client. The snipped emphasizes that "signal to the server to create stream "
  that needs to be fixed. If there are no specific explanations, then it would
  suggest to rewrite the sentence to --

    The EoQ Connection Start Packet is sent by the client after creating a
    QUIC connection to signal to the server, on the client-initiated stream,
    respond with EPP.

# Nits -

- Section 7 : the references to RFC9000 are out of order in the description of
"Stateful Nature". RFC 9000 section 2 is about streams and section 5 is about
connections.


Best wishes,
Gorry

[Ballot discuss]
Section 8.8, 0-RTT and Session Resumption:

472 >    Using 0-RTT for EoQ allows clients to establish connections and
473 >    initiate EPP transactions without round-trip delay, enabling servers
474 >    to use shorter idle timers and reduce connection overhead.  Session
475 >    resumption and 0-RTT introduce privacy and replay risks.  EoQ
476 >    implementations SHOULD follow [RFC8446] and [RFC9001] guidance to
477 >    balance performance and risk mitigation.  Failure to do so increases
478 >    privacy exposure and replay attack risks.

RFC 9001 Section 5.6 states: "An application protocol that uses QUIC
MUST include a profile that defines acceptable use of 0-RTT; otherwise,
0-RTT can only be used to carry QUIC frames that do not carry
application data."  EoQ defines no such profile.  Directing
implementers to "SHOULD follow [RFC8446] and [RFC9001] guidance" is
not a substitute for defining that profile, and this document therefore
does not satisfy the MUST from RFC 9001.

The absence is made more serious by the text above asserting that 0-RTT
allows clients to "initiate EPP transactions."  If EoQ defines no
profile permitting EPP application data in 0-RTT, RFC 9001 prohibits
exactly that use.  The text and the RFC 9001 requirement are directly
contradictory. EPP commands, including  itself, are
not safe to replay without application-layer protections that this
document does not specify.

In my view, this section must be revised.  At a minimum, the document
should either:

(a) explicitly prohibit EPP application data (including ) from
being carried in 0-RTT data, specifying only the EoQ Connection Start
Packet as a candidate for 0-RTT, or

(b) define a specific 0-RTT profile — including which EPP messages
may be included, what replay mitigations are required, and how session authentication
state interacts with resumed sessions — thereby satisfying the RFC 9001
MUST.

[Ballot comment]
Section 5, Data Unit Format:

305 >    The EPP data unit contains two fields: a 32-bit header that describes
306 >    the total length of the data unit, and the EPP XML instance.  The
307 >    length of the EPP XML instance is determined by subtracting four
308 >    octets from the total length of the data unit.  A receiver must
309 >    successfully read that many octets to retrieve the complete EPP XML
310 >    instance before processing the EPP message.

The 32-bit Total Length field permits a declared length of up to
approximately 4 GB.  The SECDIR review (thanks, Mike) against -09 raised this concern.
RFC 5734 is equally silent on length-field bounds checking for the
identical framing it defines.  In my opinion, the Security
Considerations section should recommend that
implementations validate the declared length against a locally
configured maximum before allocating memory or attempting to read the
declared number of octets.  Without such guidance, a single crafted
packet with an oversized length field can exhaust a receiver's memory.
I would suggest adding a sentence to Section 11 to this effect.

---

Section 6, EoQ Connection Start Packet, error handling:

337 >    Absent processing errors or local policy, the server accepts the
338 >    QUIC stream, reads the EoQ Connection Start Packet, and returns
339 >    the EPP  to the client on same QUIC stream.

The document specifies that a valid EoQ Connection Start Packet MUST be
exactly 24 octets containing the literal string "EoQ Connection Start"
(Section 6).  However, it does not specify what the server MUST or
SHOULD do if it receives a stream-opening packet that does not conform
to this format — for example, if the Total Length field is not 24, or
if the payload does not match the expected constant.  Section 7
addresses error handling for malformed EPP commands, but not for a
malformed EoQ Connection Start Packet.  In my opinion, the document
should specify the required server behavior in this case (e.g., close
the QUIC stream, with or without returning an error).

---

Section 4, Message Exchange, stream limiting:

229 >    A server SHOULD limit a client to a maximum number of QUIC
230 >    streams per QUIC connection based on server capabilities and
231 >    operational load.  Absent such limit, a server may be subject to
232 >    overload and resource exhaustion.

RFC 9000 Section 4.6 defines the normative QUIC mechanism for this:
servers use the max_streams transport parameter and MAX_STREAMS frames
to limit the number of streams a peer may open, and endpoints MUST NOT
exceed the limit set by their peer.  In my opinion, this section should
reference that mechanism explicitly, so that implementers understand
both how to enforce the limit and the QUIC-level error (STREAM_LIMIT_ERROR)
that results from a client exceeding it.  The TSV-ART review against
-09 also noted this gap.

---

Section 3, Session Management, max_idle_timeout:

207 >    The max_idle_timeout transport parameter defined in
208 >    Section 18.2 of [RFC9000] MUST NOT be set to a non-zero value by the
209 >    client or server.  Once the last QUIC stream for a QUIC connection is
210 >    closed, the server MAY end the QUIC connection immediately.

I understand the intent. However, a consequence of setting max_idle_timeout to 0 is that a
QUIC connection with no open streams can remain open indefinitely.
The server is permitted but not required to close the connection when
the last stream closes.  In my opinion, the document should say
something about the expected behavior in this state, perhaps elevating
the "MAY end the QUIC connection immediately" to SHOULD, to help
operators avoid accumulating zombie connections.

---

Section 9.2, Registration of Port Number:

511 >    This document requests IANA to update that entry so that it is
512 >    reassigned to EPP and add a reference to this document.

The phrase "reassigned to EPP" is confusing because port 700/UDP is
already assigned to the EPP service (service name "epp").  What the
document is requesting is an update to the Description field (from the
current generic EPP text to "EPP run over QUIC") and the addition of
this RFC as an additional reference alongside [RFC5734]. 
The IANA request should be stated precisely: for example,
"This document requests IANA to update the Description field of the
EPP UDP/700 entry to 'EPP run over QUIC' and to add this document as
an additional Reference alongside [RFC5734]."

[Ballot discuss]
Please find below a blocking DISCUSS points (easy to address), some non-blocking COMMENT points/nits (replies would be appreciated even if only for my own education).

As noted in https://datatracker.ietf.org/doc/statement-iesg-handling-ballot-positions-20220121/, a DISCUSS ballot is a request to have a discussion on the point below, which I expect will be very easy to resolve:

The current text says: "Operators are encouraged to provision network paths with appropriate MTU sizes to avoid packet fragmentation for EPP message delivery."
- I don't really understand what this is asking for and what is needed, please clarify.
-  When I started reading I assumed this was the standard QUIC datagram size (as in section 14), but maybe this means to say more, or I was just thrown by the term "MTU" here?
- And please explain what is the fragmentation described here?

[Ballot comment]
Thank you for submitting this document, I have the following comments:

(1) I couldn't really understand why this RFC is specifying transport over QUIC, but expect there was some specific need. I think that ought to be clearer.

(2) The security properties of QUIC do differ to those of TLS/TCP, in as much as QUIC us an encrypted transport - see 21.1 in the security considerations of RFC9000.

Best wishes,
Gorry

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-regext-epp-quic-09. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there are two actions that we must complete.

First, in the TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs registry in the Transport Layer Security (TLS) Extensions registry group located at:

https://www.iana.org/assignments/tls-extensiontype-values/

a single new extension is to be made as follows:

Protocol: EoQ
Identification Sequence: 0x45 0x6F 0x51 ("EoQ")
Reference: [ RFC-to-be ]
Comment:

As this document requests a registration in an Expert Review or Specification Required (see RFC 8126) registry, we have completed the required Expert Review via a separate request.

Second, in the Service Name and Transport Protocol Port Number Registry located at:

https://www.iana.org/assignments/service-names-port-numbers/

there is an existing entry for EPP UDP/700. Upon approval of this document that entry will be updated so that it is reassigned to EPP and has a reference to [ RFC-to-be ].

Service Name: epp
Port Number: 700
Transport Protocol(s): UDP
Assignee: IESG
Contact: IETF
Description: EPP run over QUIC
Reference: [RFC5734][ RFC-to-be ]

As this also requests a registration update in the Service Name and Transport Protocol Port Number Registry, we have initiated an advisory Expert Review via a separate request.

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

NOTE: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2026-06-22):

From: The IESG
To: IETF-Announce
CC: draft-ietf-regext-epp-quic@ietf.org, gavin.brown@icann.org, mohamed.boucadair@orange.com, regext-chairs@ietf.org, regext@ietf.org, zalbanna@verisign.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Extensible Provisioning Protocol (EPP) Transport over QUIC) to Proposed Standard


The IESG has received a request from the Registration Protocols Extensions WG
(regext) to consider the following document: - 'Extensible Provisioning
Protocol (EPP) Transport over QUIC'
  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-06-22. 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


  This document specifies how an Extensible Provisioning Protocol (EPP)
  session is mapped onto a QUIC connection.  EPP over QUIC (EoQ)
  leverages features of the QUIC protocol.




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



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

Shepherd writeup
draft-ietf-regext-epp-quic
Document Shepherd Write-Up for draft-ietf-regext-epp-quic

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?

  Yes, a broad agreement was reached. There have been 5 expressions of support
  (not counting the editors or document shepherd) and no objections.

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

    Existing implementation can be found in the Verisign EPP SDK 1.17.0.2,
    published at:
    https://www.verisign.com/resources/registrar-resources/epp-sdk/ which needs
    to be updated in the draft from
    https://www.verisign.com/en_US/channel-resources/domain-registry-products/epp-sdks

    At the time of composing this document no public plans to deploy this transport were found.


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

  Review was received from the QUIC group (Lucas Pardue) that addressed
  materials in sections 1,3,5, and 6. Lucas Pardue recommended adding
  versioning to the ALPN value (e.g., “eoq/0.1”), which was done in
  draft-ietf-regext-epp-quic-02.  Martin Thompson from the QUIC working group
  recommended removing the versioning, so the document editors looked to what
  was done for DNS over QUIC in RFC 9250, which was to not using versioning in
  the form “DoQ”.  The ALPN value was updated to “EoQ” in
  draft-ietf-regext-epp-quic-04 and a reference was made to RFC 7301 in
  draft-ietf-regext-epp-quic-05.

  Please see
  https://mailarchive.ietf.org/arch/msg/regext/Thll_wlvPo-BRGfY57JGDXUBYXc/
  for more details.

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.

  This document does not use any MIB, YANG, or media types, as such it does not
  require a formal expert review.

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

  This document 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.

  The document does not contain any formal specification language that
  requires validation.

## 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, after the URL for the Verisign EPP SDK implementation is updated to
  https://www.verisign.com/resources/registrar-resources/epp-sdk/. This
  document describes how an Extensible Provisioning Protocol (EPP) session is
  mapped onto a QUIC connection and details how this mechanism leverages the
  performance and security features of the QUIC protocol as an EPP transport.

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?

    No such issues have been identified or addressed.

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. Datatracker stated attributes correctly reflect proposed
    standard. The intended status is appropriate as the document specifies
    normative behaviors that impact interoperability between EPP Clients and Servers.

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, I have confirmed with the editor that all disclosure obligations have
    been met and no disclosures are required. Please see the links below:

    https://mailarchive.ietf.org/arch/browse/regext/?qdr=y&q=draft-ietf-regext-epp-quic%20IPR

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 total number of authors is 5.

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

    There are no errors to address in draft-regext-epp-quic-06


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?

        There are no such references.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

        There are no such references.

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?

        There are no such references.

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. This publication does not change the status of any existing RFC.

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 document's IANA consideration section 8 lists two points with
        regard to IANA registry update. The first point in section 8.1 contains
        a request for a new IANA registry for EoQ Identification String for the
        identification of EoQ in the "TLS Application-Layer Protocol Negotiation
        (ALPN) Protocol IDs".
        The second point in section 8.2 contains a request for reassigning an
        existing entry for EPP UDP/700 to this draft.

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.

        1- Registration of an EoQ Identification String for the identification
        of EoQ in the "TLS Application-Layer Protocol Negotiation (ALPN)
        Protocol IDs" registry [RFC7301].

        2- Registration of Port Number for the "Service Name and Transport
        Protocol Port Number Registry" contains an entry for EPP UDP/700 based
        on [RFC6335].  However, no known implementations of EPP over UDP exist. 
        The entry will be reassigned to reference this draft.

[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 draft-ietf-regext-epp-quic

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?

  Yes, a broad agreement was reached. There have been 5 expressions of support
  (not counting the editors or document shepherd) and no objections.

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

    Existing implementation can be found in the Verisign EPP SDK 1.17.0.2,
    published at https://www.verisign.com/resources/registrar-resources/epp-sdk/ which needs to be updated in the draft from https://www.verisign.com/en_US/channel-resources/domain-registry-products/epp-sdks

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

  Review was received from the QUIC group (Lucas Pardue) that addressed materials in
  sections 1,3,5, and 6. Lucas Pardue recommended adding versioning to the ALPN value (e.g., “eoq/0.1”), which was done in draft-ietf-regext-epp-quic-02.  Martin Thompson from the QUIC working group recommended removing the versioning, so the document editors looked to what was done for DNS over QUIC in RFC 9250, which was to not using versioning in the form “DoQ”.  The ALPN value was updated to “EoQ” in draft-ietf-regext-epp-quic-04 and a reference was made to RFC 7301 in draft-ietf-regext-epp-quic-05.

  Please see https://mailarchive.ietf.org/arch/msg/regext/Thll_wlvPo-BRGfY57JGDXUBYXc/
  for more details.

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.

  This document does not use any MIB, YANG, or media types, as such it does not
  require a formal expert review.

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

  This document 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.

  The document does not contain any formal specification language that requires validation.

## 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, after the URL for the Verisign EPP SDK implementation is updated to  https://www.verisign.com/resources/registrar-resources/epp-sdk/. This document describes how an Extensible Provisioning Protocol (EPP)
  session is mapped onto a QUIC connection and details how this mechanism
  leverages the performance and security features of the QUIC protocol
  as an EPP transport.

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?

    No such issues have been identified or addressed.

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. Datatracker stated attributes correctly reflect proposed standard.

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, I have confirmed with the editor that all disclosure obligations have
    been met and no disclosures are required. Please see the links below:

    https://mailarchive.ietf.org/arch/browse/regext/?qdr=y&q=draft-ietf-regext-epp-quic%20IPR

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 total number of authors is 5.

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 errors below were found in draft-ietf-regext-epp-quic-05. These errors were
    corrected in draft-regext-epp-quic-06. There are no erros to address in
    draft-regext-epp-quic-06

Errors:

(1) ** The document seems to lack a both a reference to RFC 2119 and the
    recommended RFC 2119 boilerplate, even if it appears to use RFC 2119
    keywords.

    RFC 2119 keyword, line 131: '...lled the "server".  An EPP server MUST...'
    RFC 2119 keyword, line 139: '... established, the EPP client MUST then...'
    RFC 2119 keyword, line 152: '...receiving an EPP  command MUST...'
    RFC 2119 keyword, line 153: '... the QUIC stream.  A client MAY end an...'
    RFC 2119 keyword, line 154: '...UIC stream and the server MUST end the...'
    (20 more instances...)

(2) ** The document contains RFC2119-like boilerplate, but doesn't seem to
    mention RFC 2119.  The boilerplate contains a reference [BCP14], but that
    reference does not seem to mention RFC 2119 either.

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?

There are no such references.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

There are no such references.

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?

There are no such references.

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. This publication does not change the status of any existing RFC.

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 document's IANA consideration section 8 lists two points with regard to IANA registry update.
The first point in section 8.1 contains a request for a new IANA registry for EoQ Identification String for the identification of
EoQ in the "TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs".
The second point in section 8.2 contains a request for reassigning an existing entry for EPP UDP/700 to this draft.

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.

1- Registration of an EoQ Identification String for the identification of
EoQ in the "TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs"
registry [RFC7301].

2- Registration of Port Number for the "Service Name and Transport Protocol Port Number Registry"
  contains an entry for EPP UDP/700 based on [RFC6335].  However, no
  known implementations of EPP over UDP exist.  The entry will be
  reassigned to reference this draft.


[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 draft-ietf-regext-epp-quic

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?

  Yes, a broad agreement was reached. There have been 5 expressions of support
  (not counting the editors or document shepherd) and no objections.

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

    Existing implementation can be found in the Verisign EPP SDK 1.17.0.2,
    published at https://www.verisign.com/resources/registrar-resources/epp-sdk/ which needs to be updated in the draft from https://www.verisign.com/en_US/channel-resources/domain-registry-products/epp-sdks

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

  Review was received from the QUIC group (Lucas Pardue) that addressed materials in
  sections 1,3,5, and 6. Lucas Pardue recommended adding versioning to the ALPN value (e.g., “eoq/0.1”), which was done in draft-ietf-regext-epp-quic-02.  Martin Thompson from the QUIC working group recommended removing the versioning, so the document editors looked to what was done for DNS over QUIC in RFC 9250, which was to not using versioning in the form “DoQ”.  The ALPN value was updated to “EoQ” in draft-ietf-regext-epp-quic-04 and a reference was made to RFC 7301 in draft-ietf-regext-epp-quic-05.

  Please see https://mailarchive.ietf.org/arch/msg/regext/Thll_wlvPo-BRGfY57JGDXUBYXc/
  for more details.

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.

  This document does not use any MIB, YANG, or media types, as such it does not
  require a formal expert review.

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

  This document 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.

  The document does not contain any formal specification language that requires validation.

## 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, after the URL for the Verisign EPP SDK implementation is updated to  https://www.verisign.com/resources/registrar-resources/epp-sdk/. This document describes how an Extensible Provisioning Protocol (EPP)
  session is mapped onto a QUIC connection and details how this mechanism
  leverages the performance and security features of the QUIC protocol
  as an EPP transport.

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?

    No such issues have been identified or addressed.

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. Datatracker stated attributes correctly reflect proposed standard.

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, I have confirmed with the editor that all disclosure obligations have
    been met and no disclosures are required. Please see the links below:

    https://mailarchive.ietf.org/arch/browse/regext/?qdr=y&q=draft-ietf-regext-epp-quic%20IPR

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 total number of authors is 5.

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 errors below were found in draft-ietf-regext-epp-quic-05. These errors were
    corrected in draft-regext-epp-quic-06. There are no erros to address in
    draft-regext-epp-quic-06

Errors:

(1) ** The document seems to lack a both a reference to RFC 2119 and the
    recommended RFC 2119 boilerplate, even if it appears to use RFC 2119
    keywords.

    RFC 2119 keyword, line 131: '...lled the "server".  An EPP server MUST...'
    RFC 2119 keyword, line 139: '... established, the EPP client MUST then...'
    RFC 2119 keyword, line 152: '...receiving an EPP  command MUST...'
    RFC 2119 keyword, line 153: '... the QUIC stream.  A client MAY end an...'
    RFC 2119 keyword, line 154: '...UIC stream and the server MUST end the...'
    (20 more instances...)

(2) ** The document contains RFC2119-like boilerplate, but doesn't seem to
    mention RFC 2119.  The boilerplate contains a reference [BCP14], but that
    reference does not seem to mention RFC 2119 either.

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?

There are no such references.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

There are no such references.

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?

There are no such references.

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. This publication does not change the status of any existing RFC.

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 document's IANA consideration section 8 lists two points with regard to IANA registry update.
The first point in section 8.1 contains a request for a new IANA registry for EoQ Identification String for the identification of
EoQ in the "TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs".
The second point in section 8.2 contains a request for reassigning an existing entry for EPP UDP/700 to this draft.

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.

1- Registration of an EoQ Identification String for the identification of
EoQ in the "TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs"
registry [RFC7301].

2- Registration of Port Number for the "Service Name and Transport Protocol Port Number Registry"
  contains an entry for EPP UDP/700 based on [RFC6335].  However, no
  known implementations of EPP over UDP exist.  The entry will be
  reassigned to reference this draft.


[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 draft-ietf-regext-epp-quic

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?

  Yes, a broad agreement was reached. There have been 5 expressions of support
  (not counting the editors or document shepherd) and no objections.

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

    Existing implementation can be found in the Verisign EPP SDK 1.17.0.2,
    published at https://www.verisign.com/resources/registrar-resources/epp-sdk/ which needs to be updated in the draft from https://www.verisign.com/en_US/channel-resources/domain-registry-products/epp-sdks

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

  Review was received from the QUIC group (Lucas Pardue) that addressed materials in
  sections 1,3,5, and 6. Lucas Pardue recommended adding versioning to the ALPN value (e.g., “eoq/0.1”), which was done in draft-ietf-regext-epp-quic-02.  Martin Thompson from the QUIC working group recommended removing the versioning, so the document editors looked to what was done for DNS over QUIC in RFC 9250, which was to not using versioning in the form “DoQ”.  The ALPN value was updated to “EoQ” in draft-ietf-regext-epp-quic-04 and a reference was made to RFC 7301 in draft-ietf-regext-epp-quic-05.

  Please see https://mailarchive.ietf.org/arch/msg/regext/Thll_wlvPo-BRGfY57JGDXUBYXc/
  for more details.

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.

  This document does not use any MIB, YANG, or media types, as such it does not
  require a formal expert review.

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

  This document 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.

  The document does not contain any formal specification language that requires validation.

## 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, after the URL for the Verisign EPP SDK implementation is updated to  https://www.verisign.com/resources/registrar-resources/epp-sdk/. This document describes how an Extensible Provisioning Protocol (EPP)
  session is mapped onto a QUIC connection and details how this mechanism
  leverages the performance and security features of the QUIC protocol
  as an EPP transport.

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?

    No such issues have been identified or addressed.

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. Datatracker stated attributes correctly reflect proposed standard.

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, I have confirmed with the editor that all disclosure obligations have
    been met and no disclosures are required. Please see the links below:

    https://mailarchive.ietf.org/arch/browse/regext/?qdr=y&q=draft-ietf-regext-epp-quic%20IPR

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 total number of authors is 5.

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

Errors:

(1) ** The document seems to lack a both a reference to RFC 2119 and the
    recommended RFC 2119 boilerplate, even if it appears to use RFC 2119
    keywords.

    RFC 2119 keyword, line 131: '...lled the "server".  An EPP server MUST...'
    RFC 2119 keyword, line 139: '... established, the EPP client MUST then...'
    RFC 2119 keyword, line 152: '...receiving an EPP  command MUST...'
    RFC 2119 keyword, line 153: '... the QUIC stream.  A client MAY end an...'
    RFC 2119 keyword, line 154: '...UIC stream and the server MUST end the...'
    (20 more instances...)

(2) ** The document contains RFC2119-like boilerplate, but doesn't seem to
    mention RFC 2119.  The boilerplate contains a reference [BCP14], but that
    reference does not seem to mention RFC 2119 either.

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?

There are no such references.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

There are no such references.

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?

There are no such references.

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. This publication does not change the status of any existing RFC.

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 document's IANA consideration section 8 lists two points with regard to IANA registry update.
The first point in section 8.1 contains a request for a new IANA registry for EoQ Identification String for the identification of
EoQ in the "TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs".
The second point in section 8.2 contains a request for reassigning an existing entry for EPP UDP/700 to this draft.

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.

1- Registration of an EoQ Identification String for the identification of
EoQ in the "TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs"
registry [RFC7301].

2- Registration of Port Number for the "Service Name and Transport Protocol Port Number Registry"
  contains an entry for EPP UDP/700 based on [RFC6335].  However, no
  known implementations of EPP over UDP exist.  The entry will be
  reassigned to reference this draft.


[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/