Re: [regext] Shepherd's nits on draft-ietf-regext-unhandled-namespaces

["Gould, James" <[e-mail]>]

David,

Thank you for your review feedback.  All of the nit updates have been made in draft-ietf-regext-unhandled-namespaces-06.  The only change from what you proposed was to use “implementing” instead of “doing” in “the server should consider implementing the following”.  The corresponding wording change will be made in “the client should consider implementing the following”.  I looked at the indentation of all of the examples and I found a couple other issues that were addressed in draft-ietf-regext-unhandled-namespaces-06.

Thanks,

--

JG

[cid:image001.png@01D6CC9D.559C0B70]

James Gould
Fellow Engineer
[e-mail]<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[e-mail]>

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com<http://verisigninc.com/>

From: regext <[e-mail]> on behalf of "Smith, David - Dulles" <dsmith=[e-mail]>
Date: Thursday, December 3, 2020 at 2:04 PM
To: "[e-mail]" <[e-mail]>
Subject: [EXTERNAL] [regext] Shepherd's nits on draft-ietf-regext-unhandled-namespaces

Hi –

As the document shepherd for draft-ietf-regext-unhandled-namespaces, I reviewed the text of the draft and had the following feedback for consideration. It’s grouped by document section or page number.

Abstract
"server tof determine" -> "tof" typo

2. Unhandled Namespaces

Original:
"The unhandled namespaces problem exists when the server has information, that it needs to return to the client, that is not supported by the client"
Proposal:
"The unhandled namespaces problem exists when the server has information that it needs to return to the client but the namespace of the information is not supported by the client"

3.  Use of EPP <extValue> for Unhandled Namespace Data

Original:
"caused a server error condition, and the <reason> element"
Proposal:
"caused a server error condition and the <reason> element"

Original:
"When a server has data to return to the client, that the client"
Proposal:
"When a server has data to return to the client that the client"

[Page 8]
The example includes a server response where the <secDNS> child elements are not indented but should be.

4.  Signaling Client and Server Support

Original:
"in the server's Greeting extension services, can expect"
Proposal:
"in the server's Greeting extension services can expect"

Original:
"in the client's <login> Command extension services, can expect"
Proposal:
"in the client's <login> Command extension services can expect"

5.  Usage with General EPP Responses

Original:
"MAY include it under in the <extValue>"
Proposal:
"MAY include it under the <extValue>"

7.1.  Client Implementation Considerations

Original:
"Ensure that the login services is accurate with what is supported by the client."
Proposal:
"Ensure that the client presents the complete set of what it supports when presenting its login services"

Original:
"The unhandled namespace can be implemented"
Proposal:
"The unhandled namespace should be implemented"

7.2.  Server Implementation Considerations

Original:
"the server should consider the following"
Proposal:
"the server should consider doing the following"