Re: [regext] Opsdir last call review of draft-ietf-regext-unhandled-namespaces-07

[Qin Wu <[e-mail]>]

Hi, James:
-----邮件原件-----
发件人: Gould, James [mailto:[e-mail]] 
发送时间: 2021年2月8日 22:42
收件人: Qin Wu <[e-mail]>; [e-mail]
抄送: [e-mail]; [e-mail]; [e-mail]
主题: Re: Opsdir last call review of draft-ietf-regext-unhandled-namespaces-07

Qin,

Thank you for your review and feedback.  I provide responses to your feedback below.  Let me know if you have any additional questions or feedback.

Thanks,

-- 
 
JG



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

On 2/6/21, 6:58 AM, "Qin Wu via Datatracker" <[e-mail]> wrote:

    Reviewer: Qin Wu
    Review result: Has Issues

    I have reviewed this document as part of the Operational directorate's ongoing
    effort to review all IETF documents being processed by the IESG.  These
    comments were written with the intent of improving the operational aspects of
    the IETF drafts. Comments that are not addressed in last call may be included
    in AD reviews during the IESG review.  Document editors and WG chairs should
    treat these comments just like any other last call comments.

    This document defines Extensible Provison Protocol (EPP) extension for
    unhandled namespace information conveyed to the client. It allows the server
    return unhandled namespace information that the client can process later. 
    I think this document is well documented, however I do have a few questions for
    clarification. 
 
    Major issue: Not found 
    Minor issues:

 1.Section 1: I am not sure how unhandled namespace information exchanging between the client and the
    service is compliant with the negotiated services defined in [RFC5730]. Why
    error response is not best choice to return this unhandled namespace
    information for later handling.

JG - Very good question. The first part of your question is associated with how the unhandled namespace information is returned back, which make it compliant with the negotiated services defined in RFC 5730.  The unhandled namespace information is returned in element (e.g., <extValue> <value> element) that is not processed by the XML parser so it won't cause a client-side XML parser error and is not located in a portion of the response (e.g., under <resData> for an object-level extension or under <extension> for a command-response extension) that would be a compliance issue with the RFC 5730 negotiated services.  For the second part of your question, why not return an error response, we need to look at the use case that raised this issue in the first place.  EPP includes a poll queue in RFC 5730 that enables the server to insert notifications (poll messages) for asynchronous consumption by the client using an ordered queue.  The poll queue is dequeued by the client one message at a time by receiving the message and acknowledging the receipt of the message with the server.  While working on the Change Poll Extension (https://tools.ietf.org/html/rfc8590), the question came up what occurs if the new poll message is in the queue, but the client does not support it?  If the lack of client support resulted in an error, the change poll message would represent a poison message that would halt the consumption of the poll queue messages.  Returning the message without consideration of the client services is a compliance issue and returning an error would result in a poison message, which was the driver to come up with a solution.  The EPP protocol already provided a mechanism to return XML information that is not processed by the XML parser, which enabled returning the poll message with the XML information and a signal that a service is not supported by the client that solved the compliance and the poison message issue.  This approach could also be used to optionally return the information and the unsupported service signal in general EPP responses.  The working group did discuss other options, such as changing the order of the messages in the queue, but the unhandled namespace approach was the simplest and most effective approach discussed to solve the problem.

[Qin]: Good clarification, would it be great to add some explanation text in the introduction section, motivation part.

    2. Section 3.1/Section 3.2
    For Unhandled Object-Level Extension in section 3.1 and Unhandled
    Command-Response Extension in section 3.2, I see Template unhandled namespace
    response example for an unsupported command-response extension is same as
    Template unhandled namespace response example for an unsupported object-level
    extension, which make me confused, I am wondering how do we distinguish
    Unhandled Object-Level Extension from Unhandled Command-Response Extension in
    the XML snippet example. Can you clarify this?

JG - The most important signal is that the client lacks support for a particular service defined by the namespace URI, whether it be for a unsupported object-level extension or an unsupported command-response extension.  A client can leverage the referenced NAMESPACE-URI to map up to the type of service defined in the EPP Greeting of the server.  All of the object-level extension namespace URIs are identified using an <objURI> element in the EPP Greeting and all of the command-response extension namespace URIs are identified using a <extURI> element in the EPP Greeting.  

[Qin]: Okay, I understand now.

    3. When we say converting from an object response to a general EPP response by
    the server, does it mean the [NAMESPACE-XML] variable should be replaced by the
    object-level extension XML. Where these [NAMESPACE-XML] variable are stored in
    the server? Do we need to maintain the mapping between [NAMESPACE-XML] variable
    and object-level extension XML? Can you clarify this?

JG - What's meant by that is an object-level EPP response includes a <resData> element containing the object-level extension XML referenced by [NAMESPACE-XML].  The object-level extension XML referenced by [NAMESPACE-XML] is moved under a <extValue> <value> element, which is not processed by the XML parser, and the <resData> element is removed from the response.  From the client perspective the response will not look like an object-level extension response, but simply as a general EPP response.  Take a look at how the transfer query response is formatted in RFC 5731 (https://tools.ietf.org/html/rfc5731#section-3.1.3 ) and how it's converted in the example of section 3.1 (https://tools.ietf.org/html/draft-ietf-regext-unhandled-namespaces-07#section-3.1).  The <domain:trnData> element is moved from under the <resData> element to under a <extValue> <value> element and the <resData> element is removed.        

[Qin]: I understand that, I feel you didn't answer my last question? Where the mapping between [NAMESPACE-XML] variable and object-level extension XML is maintained? In the server side or in the client side? Otherwise, it is not clear to me how [NAMSPACE-XML] included in the wrapper <resdata></resdata> is replaced with [NAMSPACE-XML] wrapped in <extvalue><value></value></extvalue>, who does that? Client or Server, probably it should be the server.
Or there is no [NAMESPACE-XML] variable existed in the real implementation, it is just alias name for something we want to carry in the response with unhandled namespace?