Subject: [Last-Call] Opsdir last call review of draft-ietf-regext-unhandled-namespaces-07

From: Qin Wu via Datatracker <[email-masked]>
Date: Sat, 06 Feb 2021 03:58:46 -0800

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

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?

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?

---

From: "Gould, James" <[email-masked]>
Date: Mon, 8 Feb 2021 14:42:25 +0000

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
[email-masked] <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email-masked]>

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" <[email-masked]> wrote:

    Reviewer: Qin Wu

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.

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.  

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.

---

From: Qin Wu <[email-masked]>
Date: Mon, 15 Feb 2021 03:03:37 +0000

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

Qin,

Thanks,

-- 
 
JG

James Gould
Fellow Engineer

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

    Reviewer: Qin Wu

    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.

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

[Qin]: Okay, I understand now.

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

---

From: "Gould, James" <[email-masked]>
Date: Tue, 16 Feb 2021 13:56:41 +0000

Qin,

My responses are included below.

-- 
 
JG

James Gould
Fellow Engineer

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

On 2/14/21, 10:03 PM, "Qin Wu" <[email-masked]> 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:[email-masked]] 
    发送时间: 2021年2月8日 22:42
    收件人: Qin Wu <[email-masked]>; [email-masked]
    抄送: [email-masked]; [email-masked]; [email-masked]
    主题: Re: Opsdir last call review of draft-ietf-regext-unhandled-namespaces-07

    Qin,

    Thanks,

    -- 

    JG

    James Gould
    Fellow Engineer

    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>

        Reviewer: Qin Wu

        Major issue: Not found 
        Minor issues:

    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.

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.

    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.        

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.