Hopefully both Martin and Patrick will participate in the REGEXT working session on the Unhandled Namespaces.
I agree that the DNSSEC extension falls into the unhandled namespace discussion; although the scenario is less severe than poll messages since a poll message can block the poll queue. I believe that the login services defines what the server can return to the client, so if the client does not support the DNSSEC extension it is completely reasonable for the server not to return it. If a client wants to see the DNSSEC information returned they should include the URI in their login services. A client that can accept any extension back from the server can simply mirror the greeting services in the login services. Returning the extension irrespective of the client services is not in line with the protocol. Use of the <extValue> approach provides a middle ground of returning the information without breaking the services defined in the login services since it will not be parsed, validated, and marshalled by a validating client. — JG James Gould Distinguished Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 7/16/18, 12:44 PM, "regext on behalf of Martin Casanova" <regext-boun...@ietf.org on behalf of martin.casan...@switch.ch> wrote: @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 [regext-boun...@ietf.org]" im Auftrag von "Patrick Mevzek [p...@dotandco.com] Gesendet: Montag, 16. Juli 2018 18:02 An: regext@ietf.org 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 regext@ietf.org https://www.ietf.org/mailman/listinfo/regext _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
