Re: [regext] Poll messages with unhandled namespaces (was Re: I-D Action: draft-ietf-regext-change-poll-07.txt)

[Martin Casanova <[e-mail]>]

@Thoma Corte: Sorry if my formulation was not precise enough:

“The precondition of this approach is, that we actually can ask all registrars to prepare their clients to at least tolerate new poll messages and to update their business logic in order to process the newly given information properly if they wish to do so.” 

With this statement I wanted to support the  <extValue> approach. No (validating) client will have a  technical problem receiving such a message regardless of what was configured at login. But as I was speaking to a registrar he told me: “So far you only sent me outgoing transfer poll messages and thats all my client is prepared for. ” So in our case we need to announce to registrars that they should build tolerant clients to be prepared to also receive unexpected poll messages with content in <extValue> eg. also low balance notifications in the future.. And that not every poll message will be automatically an outgoing transfer notification anymore.

@Patrick
In deed, for domain info requests on DNSSec domains we so far left out the DNSSec part in the domain info response if the client was not DNSSec enabled at login. In the future this content could also be transmitted in the <extValue>. To me it falls also under the “unhandled namespace” problem.

Martin Casanova
________________________________________
Von: regext [[e-mail]]&quot; im Auftrag von &quot;Patrick Mevzek [[e-mail]]
Gesendet: Montag, 16. Juli 2018 18:02
An: [e-mail]
Betreff: Re: [regext] Poll messages with unhandled namespaces (was Re: I-D Action: draft-ietf-regext-change-poll-07.txt)

On Mon, Jul 16, 2018, at 17:41, Patrick Mevzek wrote:
> This is indeed more pragmatic. But all this mechanism to define which
> messages to accept
> will be outside the EPP protocol and this WG.

But please also remember that if we want to tackle this problem in a generic way (and also taking care of different servers and clients strategies regarding handling of namespaces and inline/offline parsing and use) it is not limited to a single extension (the thread started long ago with changePoll) nor in fact limited to poll messages.

Imagine registrar A wanting to request a transfer from registrar B. In some registries it means that regitrar A can do a domain:info on the domain, with the authInfo to get access to all details, and specifically the contacts.
But a domain can have a secDNS part in the domain:info reply.
What happens if the registrar A did not login with the secDNS extension (maybe this case does not exist in gTLDs where DNSSEC is mandatory but again we have other registries cases to take into account)?

Should the domain:info return an error? Return everything as is? Return everything but the secDNS part?

The last case is the worst to me: some registrars may like not to support DNSSEC at all (and hence will not log in at all, or you have other cases where registries mandate specific tests to be "DNSSEC" accredited so it may not even be possible to log in with secDNS extension even if the registrar would like to) but, and especially for this, being able to detect beforehand if some client is trying to transfer to them a domain using DNSSEC, that they would like to refuse transferring.


Of course the above is only one example with a domain:info and the secDNS extension but I am sure we can find others.

This illustrates I think the distinction I made in earlier messages and the different semantic I attach to extensions listed as login: for me they are those that the client announce it will use. Of course, it has no control over messages or objects he is not the origin or the sponsor, all cases where other namespaces may appear.


--
  Patrick Mevzek

_______________________________________________
regext mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/regext