Good Afternoon, +1.
We agree that that we should move forward with the current draft-ietf-regext-change-poll draft and move this discussion along another path. Thanks Roger From: regext [mailto:regext-boun...@ietf.org] On Behalf Of Gould, James Sent: Friday, May 04, 2018 9:16 AM To: James Galvin <gal...@elistx.com> Cc: Patrick Mevzek <p...@dotandco.com>; regext@ietf.org Subject: Re: [regext] Poll messages with unhandled namespaces (was Re: I-D Action: draft-ietf-regext-change-poll-07.txt) Jim, My recommendation is to move forward with draft-ietf-regext-change-poll and to leave the EPP server sending unsupported responses (mapping extension and / or command response extensions) to a client based on the login services up to a separate draft. This comes down to the interpretation of how the server should handle the login services of the client in creating responses. EPP extensions like the DNSSEC extension (RFC 5910) leverages the login services in the migration from RFC 4310 to RFC 5910, since the info response may include the DNSSEC extension if there is DNSSEC data. The inclusion of the DNSSEC extension and the version of the DNSSEC extension is based on the login services. Similar functionality exists within draft-ietf-regext-epp-fees in determining if and which version of the extension to return to the client. Poll messages are unique since they are inserted ahead of time by the server without knowledge of what the client does support, and therefore runs the risk of coming across a message that the client does not support based on the login services. Clients may or may not be able to handle the parsing and unmarshalling of unsupported extensions sent by the server. For poll messaging this is of particular interest, since a client may have an issue acknowledging the unsupported poll messages to get to the rest of the messages in the queue. This would represent a poison message in the poll queue. Based on the thread, there are separate thoughts related to whether it is fine for the server to send a response that contains an extension that was not included in the client’s login services. I believe that the greeting services and the login services are used to negotiate the set of extensions that client are server can use. What should the EPP server do with unsupported extensions in any EPP response and with poll message EPP responses in particular? This is a broader topic than draft-ietf-regext-change-poll, so I recommend that we don’t attempt to solve the problem specifically for draft-ietf-regext-change-poll but more generically across all of the extensions in a separate draft. — JG [cid:image001.png@01D255E2.EB933A30] James Gould Distinguished Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com<http://verisigninc.com/> From: James Galvin <gal...@elistx.com<mailto:gal...@elistx.com>> Date: Friday, May 4, 2018 at 9:31 AM To: James Gould <jgo...@verisign.com<mailto:jgo...@verisign.com>> Cc: Patrick Mevzek <p...@dotandco.com<mailto:p...@dotandco.com>>, "regext@ietf.org<mailto:regext@ietf.org>" <regext@ietf.org<mailto:regext@ietf.org>> Subject: [EXTERNAL] Re: [regext] Poll messages with unhandled namespaces (was Re: I-D Action: draft-ietf-regext-change-poll-07.txt) The chairs would appreciate a suggestion from those in this discussion as to what you would like to do next? The change-poll document has been in WGLC that has now expired. However, you have identified a technical issue but you have not been clear as to whether you want a change in the existing document or you want a new work item for the working group? What would you propose? What do others think? Antoin and Jim On 23 Apr 2018, at 9:27, Gould, James wrote: Patrick, This may be an excellent topic for a working session at the next IETF. It would be great to hear opinions from others on this topic, since there is obviously a gap in the interpretation of the greeting and login services as it relates to responses (command responses and poll response) provided by the server. Your description still leaves out a case, that I cannot prove to be the dominant one but that is certainly not a negligible one: the client receives the message, DOES NOT validate it per XML schema, DOES NOT parse it, and just stores it (as is or with a simple transformation to any other serialization format, an operation that does not need to know about the schema nor the content at all) for out of band later examination, and ACKs it in EPP to be able to fetch the next one. How can the client ack the message if it doesn’t at least parse it for the message id? An EPP client should frame the responses per RFC 5734 and will most likely parse the response to determine the result of the command and in the case of a poll message parse the message id to send the subsequent poll ack. The client could use regular expressions to extract the information or could do a validating DOM parse and object unmarshalling to have something easier to work with. There is no way for the server to know the capabilities of the client other than using the login services. Both sets of clients can be fully supported if the server honors the login services sent by the client. If the client wants to retrieve everything from the server for later processing, then the client can simply mirror the greeting services into the login services. Clients that do unmarshall responses, will most likely use marshalling factories that will be used to dynamically create the login services. This way the server will not send a response that the client does not support and will not break the client. As for "A client would need to proactively deal with the unexpected if the server does not honor the login services of the client.", I think this is already the case for many registries, and since a long time, so clients had to deal with that already. It is far from a new hypothetical problem. Just because servers have been sending unsolicited extensions to clients does not make it correct or appropriate from a protocol perspective. I believe we have examples of EPP extensions (RFC 5910 and draft-ietf-regext-epp-fees) that includes language related to what the server should or should not due based on the client login services, so this should be understood. I believe where it is not well understood is the handling of poll messages, which would be the point in creating a new draft. If the registrar logs in without the secDNS extension, to use a "core" example, and if it does a domain:info on a domain name which has secDNS info (because it is one of his own domain for which he put DNSSEC material with it before but right now in this particular session it did not use the secDNS extension at login, or maybe less contrived before a transfer he does a domain:info with the associated authInfo on a domain name it does not sponsor) then what should the registry do? Send the secDNS part of the domain:info or not? I believe not sending it creates more harm than benefits, even if the registrar did not specify it at login, but clearly this is the core point of our disagreement. The registry should not return the secDNS extension in the domain info response for a client that does support secDNS-1.0 (RFC 4310) or secDNS-1.1 (RFC 5910) according to section 2 of RFC 5910 (https://tools.ietf.org/html/rfc5910#page-4). There is similar language in the Registry Fee Extension related to inclusion of the fee extension in the command response (e.g., “does include elements in the response, when the extension has been selected during a <login> command”). The login services explicitly provide the object and command / response extensions supported by the client along with their versions, so why would the server not honor those services to determine if and what version of an extension to return to a client? The exchange of the server services in the greeting and the client services in the login allow the client and server to negotiate what extensions are supported on both sides. Inclusion of an extension outside of the negotiated services should result with an error on the server side and the server should not return an unsupported extension back in a response. The server does not know the capabilities of the client, where sending an unsolicitated extension may result in a client-side failure in the case for a validating client or a client that unmarshalls the response. — JG James Gould Distinguished Engineer jgo...@verisign.com<mailto:jgo...@verisign.com> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 4/22/18, 3:27 PM, "regext on behalf of Patrick Mevzek" <regext-boun...@ietf.org on behalf of p...@dotandco.com<mailto:regext-boun...@ietf.org%20on%20behalf%20of%2...@dotandco.com>> wrote: On Fri, Apr 20, 2018, at 16:06, Gould, James wrote: > Thank you for the detailed description of your reasoning. I will leave > it that we disagree on the purpose of the login services, the need for > the server to honor the login services for poll messaging, and the > impacts in returning unsupported responses or response extensions to > clients. Ok. > On the impact, there are two elements to consider including > first the XML parser in validating a response against the XML schemas, > and second is the unmarshalling of the XML to a representative object. > A client could disable the XML parser validation and move along to the > unmarshalling step. In the unmarshalling step the client would need to > deal with receipt of unsupported content. The client could throw an > exception because the XML (e.g., DOM tree) could not be unmarshalled, > ignore the unsupported content, or come up with some other > representation of the unsupported content (e.g., convert to list of XML > blobs or DOM objects). A client would need to proactively deal with the > unexpected if the server does not honor the login services of the > client. Your description still leaves out a case, that I can not prove to be the dominant one but that is certainly not a negligible one: the client receives the message, DOES NOT validate it per XML schema, DOES NOT parse it, and just stores it (as is or with a simple transformation to any other serialization format, an operation that does not need to know about the schema nor the content at all) for out of band later examination, and ACKs it in EPP to be able to fetch the next one. In this case, there are absolutely none of the problem you expose: the registry has no extra work to do, the registrar has no extra work to do to understand messages in unknown namespaces, registrar is not blocked at all for any new namespace introduced, the registrar has no problem if the registry message does not validate per its own XML schema, the registrar does not have to be proactive it can deal with new cases and problems later, etc. I really fail to see the drawbacks but of course anyone is free to do differently and stick to validate and parse everything in band in real time. As for "A client would need to proactively deal with the unexpected if the server does not honor the login services of the client.", I think this is already the case for many registries, and since a long time, so clients had to deal with that already. It is far from a new hypothetical problem. > Since this is not a problem unique to draft-ietf-regext-change-poll, I > agree that it's best suited to be addressed in a separate Internet Draft > that addresses service-aware EPP poll messaging. I agree this should be a separate draft, to become eventually an Informational Standard or a Best Practice depending on its content. > Is there interest in such a draft by the working group? I am interested by the subject but disagree on the offered solution. Also, it may be useful to be able (as difficult as it may be) to understand a little more on the current situation, and to see how registries currently handle this problem. Note that this happens very early and not only from poll messages. If the registrar logs in without the secDNS extension, to use a "core" example, and if it does a domain:info on a domain name which has secDNS info (because it is one of his own domain for which he put DNSSEC material with it before but right now in this particular session it did not use the secDNS extension at login, or maybe less contrived before a transfer he does a domain:info with the associated authInfo on a domain name it does not sponsor) then what should the registry do? Send the secDNS part of the domain:info or not? I believe not sending it creates more harm than benefits, even if the registrar did not specify it at login, but clearly this is the core point of our disagreement. -- Patrick Mevzek p...@dotandco.com<mailto:p...@dotandco.com> _______________________________________________ regext mailing list regext@ietf.org<mailto:regext@ietf.org> https://www.ietf.org/mailman/listinfo/regext _______________________________________________ regext mailing list regext@ietf.org<mailto:regext@ietf.org> https://www.ietf.org/mailman/listinfo/regext
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
