Qin, My responses are included below. -- JG James Gould Fellow Engineer jgould@xxxxxxxxxxxx <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgould@xxxxxxxxxxxx> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 2/14/21, 10:03 PM, "Qin Wu" <bill.wu@xxxxxxxxxx> 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:jgould@xxxxxxxxxxxx] 发送时间: 2021年2月8日 22:42 收件人: Qin Wu <bill.wu@xxxxxxxxxx>; ops-dir@xxxxxxxx 抄送: draft-ietf-regext-unhandled-namespaces.all@xxxxxxxx; last-call@xxxxxxxx; regext@xxxxxxxx 主题: 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 jgould@xxxxxxxxxxxx <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgould@xxxxxxxxxxxx> 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" <noreply@xxxxxxxx> 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 t he 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. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
