Subject: [regext] WG LAST CALL: draft-ietf-regext-unhandled-namespaces-03

From: "James Galvin" <[email-masked]>
Date: Fri, 02 Oct 2020 16:52:45 -0400

The following working group document is believed to be ready for 
submission to the IESG for publication as a standards track document:

https://datatracker.ietf.org/doc/draft-ietf-regext-unhandled-namespaces/

This WG last call will end at close of business, Friday, 16 October 
2020.

Please review this document and indicate your support (a simple “+1” 
is sufficient) or concerns with the publication of this document by 
replying to this message on the list.

The document shepherd for this document is David Smith.

Regards,

Antoin and Jim

---

From: Tobias Sattler <[email-masked]>
Date: Mon, 5 Oct 2020 13:15:49 +0200

+1

> On 2. Oct 2020, at 22:52, James Galvin <[email-masked]> wrote:
> 
> The following working group document is believed to be ready for submission to the IESG for publication as a standards track document:
> 
> This WG last call will end at close of business, Friday, 16 October 2020.
> 
> Please review this document and indicate your support (a simple “+1” is sufficient) or concerns with the publication of this document by replying to this message on the list.
> 
> _______________________________________________
> regext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/regext

---

From: Roger D Carney <[email-masked]>
Date: Mon, 5 Oct 2020 11:58:10 +0000

+1

________________________________
From: regext <[email-masked]> on behalf of Tobias Sattler <[email-masked]>
Sent: Monday, October 5, 2020 6:15 AM
To: James Galvin <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Re: [regext] WG LAST CALL: draft-ietf-regext-unhandled-namespaces-03

Notice: This email is from an external sender.

+1

---

From: Mario Loffredo <[email-masked]>
Date: Mon, 5 Oct 2020 15:04:34 +0200

+1

Mario

-- 
Dr. Mario Loffredo
Systems and Technological Development Unit
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
via G. Moruzzi 1, I-56124 PISA, Italy
Phone: +39.0503153497
Mobile: +39.3462122240
Web: http://www.iit.cnr.it/mario.loffredo

---

From: "Patrick Mevzek" <[email-masked]>
Date: Sun, 18 Oct 2020 21:07:09 -0500

> https://datatracker.ietf.org/doc/draft-ietf-regext-unhandled-namespaces/

This specification will create interoperability problems as drafted.

Even if the server announces this extension, all current clients not knowing
about it will have this new behavior forced on them,
which contradicts what RFC 5730 says (see below).
So the mechanism should be that the server does not enable this behavior
until having explicit acknowledgement by the client that it is ok to do so.

Considering a default opt-in puts all currently existing EPP clients at risk.

Especially since this specification redefines what is in RFC 5730,
which says:
Zero or more OPTIONAL <extValue> elements that can be used to
         provide additional error diagnostic information, including:

         *  A <value> element that identifies a client-provided element
            (including XML tag and value) that caused a server error
            condition.

Note the "client-provided element" and compare to this example
in the draft:
S:      <extValue>
S:        <value>
S:          <domain:trnData
S:            xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
S:            <domain:name>example.com</domain:name>
S:            <domain:trStatus>pending</domain:trStatus>
S:            <domain:reID>ClientX</domain:reID>
S:            <domain:reDate>2000-06-06T22:00:00.0Z</domain:reDate>
S:            <domain:acID>ClientY</domain:acID>
S:            <domain:acDate>2000-06-11T22:00:00.0Z</domain:acDate>
S:            <domain:exDate>2002-09-08T22:00:00.0Z</domain:exDate>
S:          </domain:trnData>
S:        </value>

<domain:trnData> was not client-provided, yet it is in extValue > value node.
(so an existing client sticking to RFC5730 may see this content and believe
it has made an error, and not understanding anything about the content
provided since it is not at all a content coming from it, the client).

It is also not really a "server error condition".

The value/extValue of RFC 5730 have been stretched out as of their use
in so many proprietary extensions, that I do not think it is a good
idea to have  standard even doing that.

Going deeper, it is not even clear if RFC 5730 allows really a return code of
success but still have value/extValue nodes. There may be nothing at it 
in the schema, but the text says:

Success and failure results
   MUST NOT be mixed.
[..]

Zero or more OPTIONAL <value> elements [..] that caused a server error condition.

Zero or more OPTIONAL <extValue> elements that can be used to
         provide additional error diagnostic information

Note how both nodes are specifically tied to "errors".

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.

Finally,
It should certainly not be "Best Current Practice".
It is neither proved to be "best" nor is it "current practice".

-- 
  Patrick Mevzek
  [email-masked]

---

From: "Gould, James" <[email-masked]>
Date: Mon, 19 Oct 2020 13:31:10 +0000

Patrick, 

Thank you for your thoughts and feedback.  I provide responses to your feedback embedded below.

-- 

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 10/18/20, 10:07 PM, "regext on behalf of Patrick Mevzek" <[email-masked] on behalf of [email-masked]> wrote:

    On Fri, Oct 2, 2020, at 15:52, James Galvin wrote:
    > https://secure-web.cisco.com/119Z6-9QCgolQ6IIOiTngyTDdKf1s3AaRBIxnoSkXH2U85ZP_AkwLkWZxbHfpOCtj0tOQgqGMA93ErjU_nX7UNe_uUkyJYV_6Do7PdfWfcCAJN7TaogAr1ErpuD8biWr-C7ZDwU0xROsE8h7FxzV3D01y4QmoAeeHGbG50UKbC7oFagBzR2dKXS3hv5-bVdXWwa2fkdW0SIVjPB3nL4n9CL6n1rTU5r0Z7PdqAUhJyS8zLeWg5leNiOHa686p1RLAFGuREUj-R-e-bziJjAlgVw/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-regext-unhandled-namespaces%2F

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".  Consider the poll queue scenario, where the server does not know what the client supports when inserting the message, but will only know when the client consumes the message later.  When asking for the poll message, should the server violate RFC 5730 by returning the message that contains an extension the client did not explicitly include in the login services?   draft-ietf-regext-unhandled-namespaces provides an option to return the poll message without violating RFC 5730 based on what's specified in the login services using an existing protocol feature.  This is not a new feature from a protocol perspective that will cause an interoperability issue.  

JG - Yes, the <extValue> is not being used for an client-side error condition in this use case and will not return client-side elements.  The <extValue> is being used to indicate what response extensions could not be returned in their standard location due to lack of support by the client.  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.   

JG - RFC 5730 did not envision this case, which is the point with the standardization of draft-ietf-regext-unhandled-namespaces.  This is not an error, so there is no mixing of success and failure results.  draft-ietf-regext-unhandled-namespaces explicitly specifies the use of the <extValue> to address the mismatch of supported client and server extensions.

    Finally,

JG - Thank you for your feedback on this.  It was agreed to change the draft from a BCP to Standards Track based on a prior thread on the list.  

    -- 
      Patrick Mevzek
      [email-masked]

    _______________________________________________
    regext mailing list
    [email-masked]
    https://secure-web.cisco.com/1G70d8BFIRruB1gzgN4-l0VXcLRCOu5-Kkw155RE1urlw78x6COxKBNOVoKRD5d7gZRHjRtEaKwurVioHW6vjLWdedF59tepS4nOgAwDY53YAaaJ99XFQV4erv91A0jcXzvxlQ8_5CTfdCTgDlmfp2ZLEWB4TV4vGQxMh8Mbv6cnyzxKG7quFet4HcdzIgEjBrmnthnBXm8qRmSmXVt1637enoWqaiXOiciCJuraD95qGyU2defRxBMOLuRmsNYUnkIoOE76uJqu0wh_i4FPqfSoc4nDyyfR9DJIgHHU7gYE/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext

---

From: "Patrick Mevzek" <[email-masked]>
Date: Wed, 21 Oct 2020 11:21:19 -0500

James,

On Mon, Oct 19, 2020, at 08:31, Gould, James wrote:
> 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.

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

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

-- 
  Patrick Mevzek
  [email-masked]

---

From: "Gould, James" <[email-masked]>
Date: Wed, 21 Oct 2020 20:56:52 +0000

Patrick,

I provide me responses embedded below.

-- 
 
JG

James Gould
Fellow Engineer

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

On 10/21/20, 12:22 PM, "regext on behalf of Patrick Mevzek" <[email-masked] on behalf of [email-masked]> wrote:

    James,

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.      

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

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.  

 

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

    _______________________________________________
    regext mailing list
    [email-masked]
    https://secure-web.cisco.com/1i1Q3CVDa_FU-YVvvRDiCKMNpQVcpS3JDv2v0QA12tEaSTOW11TJfvN4z66pyAhoHIWLb6zl6Vlm8JNkYUkXNvDY1HnvCJbHdWGL1CPbOopKavSItHVfrzNNsaBcgCs5zZCgP2rEWdFf11Nzr1Q4_8Laq4hmSQuI78P9XhRWFnjTPpij5TvK_0w-3DHtF8LPayY3Waufo2V3SNsBVdgW7XZbnUmCMfpMyyqqLBw-IOOItHP53JjuXR5vVygp-x65CtdSjLGsJyq2dbXGu8oSJICdB_U86opQQMpDYK4ZRngk/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext

---

From: "Patrick Mevzek" <[email-masked]>
Date: Wed, 21 Oct 2020 16:26:07 -0500

On Wed, Oct 21, 2020, at 15:56, Gould, James wrote:
> 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.

That is purely a judgment call.
The specifications say: this part is filled with content from client.
This is clear and non-ambiguous.

Hence a client parsing it is expecting to see there... data it already sent
since it is the client, per the specification. You can say it is a bad client
if it starts to misbehave because it sees other things there, but you can't 
also know or take into account all servers and clients out there, and their
specificities.

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

Again, you take as granted that everyone will update their clients at the moment
your specification becomes RFC (That won't happen as it doesn't happen for any RFC, no matter how good it is) or the fact that all clients work the
same as yours.

And for all clients not updated or doing things differently than yours, this draft may break them as soon as the EPP servers they connect to implement it.

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

Yes, in theory.
In practice, deployments do not happen like that, unfortunately.
  
I am just trying to give some data about past experiences.

>  A draft can be defined to 
> cover the usage of an existing element in the RFC for a specific 
> feature,

No, you are explicitly redefining usage as described in RFC 5730.

It looks minor in your eyes, not in mine, so our vision will remain separate.

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

... and not defined in RFC 5730 which is the problem for every client out there
that won't or can't or not yet upgrade to your specification.

> The description 
> of the element does not prohibit the use of the element to address a 
> specific well-defined problem solved by 

Yes, it does prohibit because it says "client provided" and you are putting
things in it that are not "client provided".
Your specification redefines core parts of the current EPP specification.

And to be honest, one moment you say "RFC 5730 couldn't predict the need
to handle undefined namespaces hence does not speak about them" (obviously)
so that you can justify overriding one of its specification
and here you say "RFC 5730 does not prohibit what this draft is trying to do
(as if RFC 5730 could have known that in advance)". I believe this is one
argument and its opposite so difficult to have both at the same time, but 
maybe I am just getting at my limits in English, which is very possible.
 
> 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.

I am not saying otherwise and I sure don't expect a change because
it is already presented as the best or unique solution on the problem, it 
has been discussed extensively and to me this specific solution creates its
own set of problems, hence my disagreement.

If I am the only one seeing that the text redefines RFC 5730 in 
different and incompatible ways, and the only one believing that not all clients will suddenly
be upgraded to use this specification (as if all EPP servers out there will
be updated...), then so be it, it does not really matter.

Again, I am not trying to convince anyone, I know it won't happen,
I just phrased my justifications on the problems I see.

-- 
  Patrick Mevzek
  [email-masked]

---

From: "Gould, James" <[email-masked]>
Date: Thu, 22 Oct 2020 13:47:22 +0000

Patrick,

I believe we're making the same points and again we can agree to disagree on the value and risk of draft-ietf-regext-unhandled-namespaces.  I do need to clarify one thing, there was no specific changes needed on the client-side to support draft-ietf-regext-unhandled-namespaces other than ensuring that the draft-ietf-regext-unhandled-namespaces XML namespace is included in the login services.  Inclusion of the draft-ietf-regext-unhandled-namespaces XML namespace in the login services is not required of the client, but does indicate to the server that the client does support monitoring the EPP poll messages and general EPP responses for unhandled namespaces.  The other change that I implemented was to include tests that exercised the use cases outlined in draft-ietf-regext-unhandled-namespaces by explicitly removing XML namespaces from the login services and handling the lack of client support in the server for poll messages and general EPP responses.  Clients should be capable of parsing and marshaling the <extValue> element regardless of whether or not draft-ietf-regext-unhandled-namespaces is supported.  

The key change for the client is to recognize that support for a service is missing and to update the client to support it.  The approach taken with draft-ietf-regext-unhandled-namespaces enables the information to be returned without the chance of breaking a validating client that doesn't support the service, ensures that a poison message doesn't stop the processing of the poll queue, and informs the client that they don't support a specified service.  The extensibility of EPP provides the capability to address issues that were not foreseen at the time that the EPP RFCs were created, which is the case for draft-ietf-regext-unhandled-namespaces.    

-- 
 
JG

James Gould
Fellow Engineer

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

On 10/21/20, 5:26 PM, "regext on behalf of Patrick Mevzek" <[email-masked] on behalf of [email-masked]> wrote:

    Yes, in theory.

    -- 
      Patrick Mevzek
      [email-masked]

    _______________________________________________
    regext mailing list
    [email-masked]
    https://secure-web.cisco.com/1nXNUwUj1bmg9lEhAyYqquMiD-JFlTPDd1gC1zvdbtqA7FJHFLDnJ9Vv6gwNpNYReHy5QvN3lrHiuiayzO0XBgtuE0rL1wi4kX5tbIpHcD1zNczy78wF56_0w8HZfIlejuaTnlqPlKwGvQ5q607CwKUk9jK6EPwWMLJgrERkT6FjBogFZ7bfILKcy9cFMWX9dEMD9EupfFE8tDFRPBtmyK3MGa9sXTb7XxwHBf6eA8zyd_uqqlivqrUnaqQ2yyONk633DlGQPcMADuCofcYnJ7NYq5v6LiSjUBLtj3E8jYOg/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext

---

From: "Patrick Mevzek" <[email-masked]>
Date: Sun, 25 Oct 2020 17:23:06 -0500

On Thu, Oct 22, 2020, at 08:47, Gould, James wrote:
> I do need to clarify one 
> thing, there was no specific changes needed on the client-side to 
> support draft-ietf-regext-unhandled-namespaces other than ensuring that 
> the draft-ietf-regext-unhandled-namespaces XML namespace is included in 
> the login services. 

There was no specific changes needed on the client-side... for YOUR client.
Great for you, but from that you can not draw a conclusion that your draft
creates no problem whatsoever.

Please take into account there are other clients out there, that may work
differently and do different assumptions.

Your draft changes the assumptions in RFC 5730. And hence may break existing
clients. By saying that there was no problem for one client is not a proof
that interoperability was not broken.

> Clients should be capable of parsing and marshaling the 
> <extValue> element regardless of whether or not 
> draft-ietf-regext-unhandled-namespaces is supported.  

This is unrelated. You are changing the text from RFC 5730 that says
explicitly this content is client provided. You are now redefining what
is in RFC 5730 by saying "any content is fine here".

> The 
> approach taken with draft-ietf-regext-unhandled-namespaces enables the 
> information to be returned without the chance of breaking a validating 
> client that doesn't support the service,

This is untrue, as you change the semantics of RFC 5730 at least twice
(content of extValue, and possibly having value/extValue with NON error codes)

Your draft *clearly* creates a _risk_ for any existing client starting to break
once a server enables this feature. Saying that one client works fine is
not a measure of interoperability risks when it is deployed.

-- 
  Patrick Mevzek
  [email-masked]

---

From: "Gould, James" <[email-masked]>
Date: Mon, 26 Oct 2020 12:42:41 +0000

Patrick,

We'll agree to disagree with the value and risk of draft-ietf-regext-unhandled-namespaces, since I can't think of a theoretical or real risk to existing clients with at least two independent implementations.  Your objection can be included in the document shepherd writeup, but as noted before there is no consensus to make a change.      

-- 
 
JG

James Gould
Fellow Engineer

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

On 10/25/20, 6:23 PM, "regext on behalf of Patrick Mevzek" <[email-masked] on behalf of [email-masked]> wrote:

    -- 
      Patrick Mevzek
      [email-masked]

    _______________________________________________
    regext mailing list
    [email-masked]
    https://secure-web.cisco.com/1JXSBPoG-78NoxpuH19NNm2nvZTdQOhccfcp1QWP5dIEoQ6ekz0xXZM5s-sjWAtHoyCWUf_2JEydMxz45_96qI1YCrzvVHqo_auUMjwRjm8-vzii5f9vyKuSHuvmM1k3cQ0yIXjkmvgHMVJvCVWmcpbbHGNx0ZiX0M2UoaJSC_KsQkylfiD2W2c6kKOzUDsOD0A0YpWshVU8cx2Vl5xPIwkFkeDUxrAEM1QqgxxgX8Kl-TSaiWE0mnRbAdMiJ2hnWnQNYliLaaS3GpmXxZ8naGmsuWA4vrGgPbftN8s8SJt0/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext

---

From: "James Galvin" <[email-masked]>
Date: Mon, 26 Oct 2020 10:01:56 -0400

The Chairs would like to extend this WG Last Call for an additional two 
weeks, to close on Friday, 30 October 2020.

Although there have been 3 indications of support, Patrick Mevzek and 
James Gould have been having an extended discussion on the mailing list 
about one issue.  The chairs believe it is important to get additional 
points of view, ideally from other EPP client developers but all 
opinions are welcome.

Current consensus is to seek publication.  However, we are a relatively 
small group and we would like all comments considered by multiple 
people.  Would others please indicate their point of view in the active 
thread between James and Patrick?

Thank you,

Antoin and Jim

On 2 Oct 2020, at 16:52, James Galvin wrote:

> Please review this document and indicate your support (a simple 
> “+1” is sufficient) or concerns with the publication of this 
> document by replying to this message on the list.
>

---

From: Thomas Corte <[email-masked]>
Date: Mon, 26 Oct 2020 17:39:41 +0100

Hello,

> thread between James and Patrick?

As both an EPP client (and server) developer, I think that both James and
Patrick make valid points, though I tend to agree more with Patrick's
point of view.

I'd fully agree with Patrick that the draft is somewhat abusing the
<extValue> mechanism, as it was clearly designed in RFC 5730 to
communicate "error diagnostic information", with the <value> containing a
"client-provided element (including XML tag and value)". In fact, from
this wording one could even derive that it's *not* proper server behavior
at all to include anything in the <value> element that didn't also appear
in the client's EPP command, which this draft is asking servers to do.

One the other hand, I'd agree that it's probably the only place where
non-parsed XML can be included in responses, which is the only way to
keep the server's responses from violating the contract by including
namespaces not listed as supported by the client.

In our own current client implementation, we're only consulting the
<extValue> content if the result code indicates an error. I'd assume that
many clients do it this way, which is why I doubt that the inclusions
defined by the draft will do any real harm or even cause confusion.

However, at best this means that clients will completely ignore the
unhandled data, i.e. simply ignore the (apparently empty) poll messages
and acknowledge them without processing. While this is nice in terms of
not blocking any other (understood) poll messages, it also poses the
problem that important poll messages may go unnoticed, potentially for
extended periods of time, which may (depending on the nature of the
messages) be a greater operational risk than blocking further polling.
If an unhandled namespace simply showed up (violating the contract), at
least my validating EPP client would croak, and I'd be forced to take
action (ideally by adding support for the namespace and resume polling then).

I know it's late in the game to come up with suggestions, but anyhow:
a compromise to solve this, at least for the polling issue, *could* be to
use <extValue> as described, but to return an *error response* (with a
special result code) instead of a success response to the <poll> command.
This could (somewhat) justify the use of <extValue>, while still alerting
the EPP client about something that it might be missing. Of course, this
would still mean that polling of further messages would come to a halt
until the issue is fixed on the client side.

Best regards,

Thomas

-- 
____________________________________________________________________
     |       |
     | knipp |            Knipp  Medien und Kommunikation GmbH
      -------                    Technologiepark
                                 Martin-Schmeißer-Weg 9
                                 44227 Dortmund
                                 Deutschland

     Dipl.-Informatiker          Tel:    +49 231 9703-0
     Thomas Corte                Fax:    +49 231 9703-200
     Stellvertretender Leiter    SIP:    [email-masked]
     Software-Entwicklung        E-Mail: [email-masked]

                                 Registereintrag:
                                 Amtsgericht Dortmund, HRB 13728

                                 Geschäftsführer:
                                 Dietmar Knipp, Elmar Knipp

---

From: "Gould, James" <[email-masked]>
Date: Tue, 27 Oct 2020 14:37:26 +0000

Thomas,

Unfortunately returning an error would not enable the client to consume the poll message, which would result in a poison poll message and a large client impact.  Use of draft-ietf-regext-unhandled-namespaces within an error response for a poll message would break the processing of poll messages and would still not provide information that was provided by the client, since the poll message is supplied by the server.  I don't believe blocking the poll queue with a poison message is a desired end state, since an unsupported message (e.g., change poll message) may not be of interest to the client but other supported messages like transfer poll messages are.  The client can decide on the poll message of interest by supporting the extensions that they're interested in without blocking the poll queue and without the server breaking compliance with the RFC by blindly returning the poll message independent of the client login services.  

As noted previously, when the <extValue> was defined in EPP RFC 5730, the description of the element never considered this use case.  draft-ietf-regext-unhandled-namespaces defines a new usage of the <extValue> element, which is a form of extension and thus the reason why there is a namespace in the server greeting to indicate that the server supports it.  As you indicate that there is no real technical impact to the client other than they may not be aware of the extra content in the poll message; although there is a predefined reason that the client can key off of defined within draft-ietf-regext-unhandled-namespaces.  

A compromise is to formally define the original intent of the <extValue> element, as defined in RFC 5730, and be explicit that draft-ietf-regext-unhandled-namespaces extends its usage to cover this use case within section 3 "Use of EPP <extValue> for Unhandled Namespace Data".  To address the concern for the client potentially ignoring the content returned by the server per draft-ietf-regext-unhandled-namespaces, text could be added to recommend that the server monitor for the usage of draft-ietf-regext-unhandled-namespaces in both General EPP Responses and Poll Message EPP Responses to inform the client out-of-band of their lack of support for a particular extension.  In addition, it could be recommended for the client to monitor for the usage of draft-ietf-regext-unhandled-namespaces to proactively identify extensions that they need to add support for.   An Implementation Considerations section could be added for this.  Thoughts to this compromise?

Thanks,

-- 
 
JG

James Gould
Fellow Engineer

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

On 10/26/20, 12:39 PM, "regext on behalf of Thomas Corte" <[email-masked] on behalf of [email-masked]> wrote:

    Hello,

    Best regards,

    Thomas

                                     Registereintrag:

                                     Geschäftsführer:

    _______________________________________________
    regext mailing list
    [email-masked]
    https://secure-web.cisco.com/1f0HYdHXFhIZdNtUuDPMth7JgdzR810M-AuwpsSOxavpswnXwC9uBX6r1GtF22pYXfEB0y1mxI9RZ3jf2OA9ozwodCluzWZ5AgWS6uqvsMLDFgkaDBf5I6HeYW5h3ZkkW_4u5oq_DMs0LNeq9Q0tPaXwrhDUjOcrm0mjqYSfxK52UH5o0vI6YorFS0ZmobmVj0CUyaJa0jbS3VsJ_s45PyGAQsrGfjxEgVXJ8temeReLsPKuDIwadLECZtkhIA4XxSxaNmggxeECgIz6jEmlvyKUOY4yDHqF3zQEgc5n4oq8/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext

---

From: Thomas Corte <[email-masked]>
Date: Tue, 27 Oct 2020 16:55:46 +0100

Hello,

> A compromise is to formally define the original intent of the <extValue> element, as defined in RFC 5730, and be explicit that draft-ietf-regext-unhandled-namespaces extends its usage to cover this…

Sounds reasonable to me. With the current EPP RFCs, there's really no
"100% clean" solution here, but the approach makes a good effort to
somehow convey that there's data available without disrupting client
implementations.

If a registry really wants registrars to understand and process their
custom poll messages, it can still resort to simply reject the <login>
command if it doesn't contain the namespace in question.

Best regards,

Thomas

                                 Registereintrag:

                                 Geschäftsführer:

---

From: Martin Casanova <[email-masked]>
Date: Fri, 30 Oct 2020 12:44:40 +0100

Hello

As an implementer of that draft and having it in productive use with
poll messages for quite a while now
I was able to run some analysis concerning its potential risks to break
clients on a real world example.

We are sending out poll messages including the ChangePoll Element
(rfc-8590) and render the poll message according to
draft-ietf-regext-unhandled-namespaces if the client did not include the
ChangePoll extension in its login services.

Out of 78 registars 21 were receiving such messages rendered according
to draft-ietf-regext-unhandled-namespaces
 since they did not include ChangePoll extensions in the login services.
(the others did include ChangePoll)

Out of these 21 registrars in questions we had zero feedback that any
client broke.

To be fair, we also did not get any positive feedback but I can say that
at least from our experience it is
totally save to implement the draft and breaking client where not an
issue at all.

Therefore here my up vote +1.

Thanks

Martin

https://www.nic.ch/export/shared/.content/files/EPP-Manual_en.pdf

-- 
SWITCH 
Martin Casanova, Domain Applications
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland 
phone +41 44 268 15 55, direct +41 44 268 16 25
[email-masked], www.switch.ch