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

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

Qin,

My responses are included below.

-- 
 
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/14/21, 10:03 PM, "Qin Wu" <[e-mail]> wrote:

    Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. 

    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://secure-web.cisco.com/19TSnduBY1Wx59Dbgu-4L-lLfR4DP-BSCDN2JzSzzgd7LJ7CwfZS8WNBlJfV1LnJ2zfz9ppArvyM2ZbvGYUy6C7s7l4KFbibH2ZrAIEtp7Ja59jeObV2DCOCLRMT2Eh8eLg6V6v_0Inh747hYsZ4CVYB0GeCJuLPhSC7Uk_h5q23npGJpL5CNG2ncnLYX9ZGzbppm-E7IKnEbN1zldrT6sBV9yMek3oJyglwZRvqcanA0i9eHYqpZKIdVMmj1mRym/http%3A%2F%2Fverisigninc.com%2F>

    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://secure-web.cisco.com/1SIHw-7FotJrwbBHXf3RV0YV-QaI5RQTW8RnWsxWnYy4S0KHvO2g9m0MbEa2b6jJ6ssJzUQWhxJWHOg0vieTXz-_Yju04yCXxN5rb7VpXiP-pw2nvjyy7J6naFF8qDeeNQuTr5SZ76U_f4nKPjrRCfeidamHqgEAy8x861LwvHw32BGjf-OU1qriPrqWQIs52dyM1aMz_a5Gr-b_IBjYT69mgkaPEL73ydjw63rEPVJhz-HV5QDhFU-8HhIxjnyn-/https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc8590), 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.

JG - In re-reviewing the introduction, one motivation that could be expanded is poison poll message.  There is already a reference to poll messages in the introduction, so how about adding the second sentence below after the existing first sentence.  This would be included in draft-ietf-regext-unhandled-namespaces-08 that would be posted after addressing all of the feedback.  

An unhandled namespace is a significant issue for the processing of [RFC5730] poll messages, since poll messages are inserted by the server prior to knowing the supported client services, and the client needs to be capable of processing all poll messages.  
Returning an unhandled namespace poll message is not compliant with the negotiated services defined in [RFC5730] and returning an error makes the unhandled namespace poll message a poison message by halting the processing of the poll queue.

        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://secure-web.cisco.com/1V8PNcRAkxe9s2CjPCSqXPzxtPEbMsuxzzv8dOoYwPqeNI0EJIJnK8bHmmsUm6x7O5-bAFGMIJbENW0O1frUU5XSmVQpFnRrq1Wfz6XRco_lhHmauB3iRe911EFG1R0P-qwexNP5MiJCoukjisryLKbZFSXU9eiD39YZziCizBVR-UqBQCmF7XMJfMOoIHEmhp_XDPus1g46yYE9lDpoUVieNE_OjjRIqH8tNp6MeQJ6mFyqeO32iK59cYhd2Y7XS/https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc5731%23section-3.1.3 ) and how it's converted in the example of section 3.1 (https://secure-web.cisco.com/1LfjiyJsyZr_d2LgJ5ZV9bICDS7ouIsBchsRaeWkr5VstuWi4Cx4D08i8KHYsuFM7mMePg579CXJZM2fVTvSUzhhjrDmWnCu9IlmRbLuPZbeMOhJax6Ipf4FeYsg_eQWxhKh8Bmus9OmSSdqeQthoN9Y8BMbDn1beJpYxTOJNz0K_yEYZSyQsY3lgYBwT7I1X3B6rq6UrKhSzOQ5bfzia33O6-DQurpj1Uwqe4ntGWvJlkgdASFpKkaIJECEnUTfV/https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-regext-unhandled-namespaces-07%23section-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?

JG - The [NAMESPACE-XML] is defined as " XML content associated with a login service namespace URI.  An example is the <domain:infData> element content in [RFC5731]." In section 1.1.  It a variable to refer to the block of XML that is moved by the server when creating the response based on the login services provided by the client.