Patrick, I provide me responses embedded below.
-- JG James Gould Fellow Engineer jgo...@verisign.com <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgo...@verisign.com> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 10/21/20, 12:22 PM, "regext on behalf of Patrick Mevzek" <regext-boun...@ietf.org on behalf of p...@dotandco.com> wrote: James, On Mon, Oct 19, 2020, at 08:31, Gould, James wrote: > Considering a default opt-in puts all currently existing EPP > clients at risk. > > JG - draft-ietf-regext-unhandled-namespaces addresses an > interoperability issue with the server returning extensions that the > client specified is not supported. The <extValue> element is already a > feature supported by RFC 5730, so this is not something "forced on > them". You are misreading me or misquoting me. What your draft forces on is the use of extValue as NOT described by RFC 5730 hence putting all current clients at risk, because you "silently" change some core expectations of RFCs 5730+. I know the problem you are trying to address (I even think I was one of the people raising it in the first place but note that in 20 years or more that EPP exists, it obviously did not move people so much even if it is a real problem), I am just trying to explain that this draft creates an interoperability problem by just changing the semantics of RFC 5730 without letting clients decide if they want it or not, they are forced by the server, hence this default opt-in migration of the current park of EPP clients will create problems. JG - I'm not clear of the risk of returning information in the <extValue> element to clients. There won't be a schema validation error like the case of returning a non-supported extension to a validating client. There won't be a marshaling error for the client, since unmarshaling the <extValue> in the <result> element should already be supported. The most likely issue is that the client will ignore the information, which does not pose an operational risk. I've implemented draft-ietf-regext-unhandled-namespaces on the server side and in a validating client within the Verisign EPP SDK, and I don't see any potential risk for the client. Martin implemented draft-ietf-regext-unhandled-namespaces in a Production server and hasn't come across any reported client-side issues. A server can choose to implement draft-ietf-regext-unhandled-namespaces and when doing so should notify the clients ahead of time, so this is not something that would be thrown onto clients without notice. > This is not a new feature from a protocol > perspective that will cause an interoperability issue. It is, because extValue is defined as containing *client* data that created an error, and you are stuffing it with *server* data. Plus the return code of 1000 + extValue case that I tried to explain, which doesn't seem to me really covered by existing RFCs, so you are just redefining things, hoping that all clients immediately will just implement your draft and hence everything is fine but unfortunately that is not what is going to happen... Maybe all of this is fine, redesigning EPP from scratch today, I could agree with all this. But I am just pointing out that specifications already exist and are NOT aligned with the way you try to use them in this draft. This is the interoperability problem, not the features themselves, the fact that you add them on top of things where they do not fit 100%. JG - RFC 5730 did not foresee the issue associated with returning poll messages to clients that don't support the extensions in the poll message. We discussed this at length at multiple REGEXT meetings, and the best solution to this problem is defined in draft-ietf-regext-unhandled-namespaces. A draft can be defined to cover the usage of an existing element in the RFC for a specific feature, which in this case is to enable servers to comply with the EPP RFC for poll messages and when there is the need to return additional information to the client (e.g., DNSSEC information). > There is no normative language in RFC 5730 that would > prohibit the use of <extValue> for the use case covered in > draft-ietf-regext-unhandled-namespaces. I believe there is and I quoted you so. Note the mention of "client-provided element", but you seem to just ignore that point. A specification can not list everything prohibited. It lists what is allowed (and it says clearly "client-provided element") and then as a safe view you can expect the rest not to be allowed. JG - Yes for an error it makes sense to include the "client-provided element". The case defined in draft-ietf-regext-unhandled-namespaces is not an error and the use of the <extValue> element for this use case is defined in draft-ietf-regext-unhandled-namespaces. The description of the element does not prohibit the use of the element to address a specific well-defined problem solved by draft-ietf-regext-unhandled-namespaces. > There may be clients out there that will consider value/extValue > only for error > return codes (>=2000) and will get confused when getting back 1000 > but with extValue > as this draft calls for. > > JG - RFC 5730 did not envision this case, which is the point with the > standardization of draft-ietf-regext-unhandled-namespaces. Which is the core of the problem and the interoperability risk. You redefine core parts of RFC 5730 without taking into accounts that clients may not be aware of your change (your draft) and hence will have problems if the server forces that new view on them, without any possible negotiation. At this point it seems we are just repeating our own arguments on both side, so I don't think either will move their position and we have to keep our disagreement, which is fine. I wanted to record my disagreement on this draft during WGLC, that is all. JG - We can agree to disagree on the value and risks associated with draft-ietf-regext-unhandled-namespaces. The Document Shepherd can include a reference to your disagreement in his writeup, but I don't believe there is consensus to make a change. -- Patrick Mevzek p...@dotandco.com _______________________________________________ regext mailing list regext@ietf.org https://secure-web.cisco.com/1i1Q3CVDa_FU-YVvvRDiCKMNpQVcpS3JDv2v0QA12tEaSTOW11TJfvN4z66pyAhoHIWLb6zl6Vlm8JNkYUkXNvDY1HnvCJbHdWGL1CPbOopKavSItHVfrzNNsaBcgCs5zZCgP2rEWdFf11Nzr1Q4_8Laq4hmSQuI78P9XhRWFnjTPpij5TvK_0w-3DHtF8LPayY3Waufo2V3SNsBVdgW7XZbnUmCMfpMyyqqLBw-IOOItHP53JjuXR5vVygp-x65CtdSjLGsJyq2dbXGu8oSJICdB_U86opQQMpDYK4ZRngk/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
