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

[Patrick Mevzek <[e-mail]>]

On Mon, Nov 2, 2020, at 10:42, Gould, James wrote:
> Do you mean it's better to fail the login if the client doesn't support 
> all of the possible EPP extensions supported by the poll queue?

Between this and the specification as currently presented, I prefer the login failure,
yes.

No option is perfect, each is a compromise.

> I view that option as being highly impactful to the clients

If a sudden change by a registry, without formal agreement by the registrar at login,
start to make it not follow RFC 5730 anymore, I think this is also very impactful to
the clients.

> and provides the 
> extension to the client in a protocol compliant manner for later 
> processing if desired.  

I disagree with the "protocol compliant manner". You redefine RFC 5730 at least twice.

> There has been no indication from the working group of a technical risk 
> with implementing draft-ietf-regext-unhandled-namespaces. 

This is incorrect. I indicated 2 points where the draft redefines what is in
RFC 5730.
This is a technical risk.

As any risk, no matter how big it can be, one has of course to judge the probability
of it happening, and the consequences if it happens. Based on that, the risk
can be considered "not worth to address". It doesn't mean it doesn't exist
or can't come back later under different circumstances, just that based on
current circumstances the probability or the consequences are considered
low/small enough that one decides to just go over that risk.

It may not happen, or not happen yet, from one registry reporting on the list
(thanks Mario for the data), but the fact that it was not seen does not mean
the risk does not exist.

I guess we will see later, when/if the extension gets deployed by other registries.

>I agreed to add text to explicitly state that draft-ietf-regext-unhandled-namespaces extends the use of the <extValue> element within section 3 "Use of EPP <extValue> for Unhandled Namespace Data", and to add an Implementation Considerations section to cover the recommendation of client and server monitoring to mitigate a client ignoring content returned by the server.

Thanks for that, could help... those reading this specification.
Now take into account anyone having written an EPP client in the past, based
on the specifications in the past, so RFC 5730 and siblings, and not aware AT ALL
of your new specification. You may see it should be announced in advance by registries,
but in practice that does not happen always (changePoll was introduced by some for example
without notifications), and even so, it can still happen some people won't be aware
of the change.
That is exactly the risk, because the change is not 100% aligned with what was
in past specifications.

As I said already I don't think there is pretty much anything else/again to discuss.
The consensus is clear considering the silent majority, so the process part has been
covered, let's go forward.

-- 
  Patrick Mevzek
  [e-mail]