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

[Patrick Mevzek <[e-mail]>]

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 
> draft-ietf-regext-unhandled-namespaces.  

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
  [e-mail]