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

From: "Gould, James" <[email-masked]>
Date: Mon, 2 Nov 2020 15:42:28 +0000

Patrick,

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?  I view that option as being highly impactful to the clients and it would morph a certain set of services as required by the client at login, which does not currently exist in EPP.  The approach taken in draft-ietf-regext-unhandled-namespaces will not impact clients at login, will not cause a poison message in the poll queue, provides an indication that an extension is not supported, and provides the extension to the client in a protocol compliant manner for later processing if desired.  

There has been no indication from the working group of a technical risk with implementing draft-ietf-regext-unhandled-namespaces.  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.

-- 
 
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 11/2/20, 10:16 AM, "regext on behalf of Patrick Mevzek" <[email-masked] on behalf of [email-masked]> wrote:

    On Tue, Oct 27, 2020, at 10:55, Thomas Corte wrote:
    > 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.

    That would certainly have my preference and it has one big bonus attached to it:
    no need of any change in the protocol, no need of any new extension/namespace,
    no need of any new specification.

    Sometimes the best solutions are not the technical ones.

    And it is not so much a stretch: many, but not all, registries mandate a
    "technical accreditation" at the beginning of the relationship with a given registrar.
    Adding a requirement there to support some namespaces is not a big change
    (a registrar is free of course to signal it during login and then just ignore
    those messages if he wants to ignore them, but then the responsibility clearly
    falls on his end and he is in control of his fate because he signaled the namespaces
    at login, without the registry forcing delivery to it of messages with "dubious"
    validity per RFC 5730).

    -- 
      Patrick Mevzek
      [email-masked]

    _______________________________________________
    regext mailing list
    [email-masked]
    https://secure-web.cisco.com/1E73rcs2l3iOpYDTtf4HlaAiULSq3R3UdqpRjAi55QTW-RXUeEqWrgJtJdDriw22K3nr_pIqXo325kguNJzfXgsWVhWpk0DOwWVtdVTf30Hn82dNXT4Z2n97-z9SnE-ijPC04qfQvvCuEAh1sYF37hFY24wfhhiHkw-4M52Qtd4y_nwedk3GWSHBTay1c-esqKc8GULE6Gbg-FftXmkyWGwsB_2u9YIo962MahDtgLBC-cfmAE1pB3G4x_UfFpQW2Ma4oLvOL4HgbKxIQ5xD4Q915Y9uxCivhZWiAE36XUuw/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext

---

From: "Patrick Mevzek" <[email-masked]>
Date: Mon, 02 Nov 2020 11:09:01 -0500

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