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

[Ulrich Wisser <[e-mail]>]

Hi,

are we really sure this is a problem worth solving?
At .se registrars (with very few exceptions) fall into two categories.
- do never poll
- poll and ignore anyway

I know that we have registrars who validate, but those usually support all
our extensions.

Could anybody produce numbers on registrars who do all three?
  1. poll
  2. validate
  3. do not support all extensions

/Ulrich





Martin Casanova <[e-mail]> schrieb am Mo., 16. Juli 2018
um 15:09 Uhr:

> Patrick
>
> To be clear the domain info response will be sent just without the DNSSec
> part. Therefore a not DNSSec interested registrar will just not see the
> DNSSec configuration but all the rest of the domain info resData. I don't
> see a problem with that.
>
> In our case a registrar currently needs to be accredited by us
> (DNSEC_ENABLED) in order to successfully login with DNSSec extension
> configured and he will only be able to transfer a DNSSec domain to him if
> the configured DNSSec at login.
>
> In case he is DNSSec enabled but still logs in without this extension he
> will get a failure with error message similar to  “Not allowed to transfer
> DNSSec Domain” when trying to transfer a DNSSec domain to him.
>
> So actually there is a way to know why it didn't work for him.
>
> As a matter of fact we will have to over think this rule now because with
> CDS DNSSec Data can be configured by the DNS-Operator of a domain as well
> (which does not need to be the registrar) . So a domain of a non DNSSec
> accredited registrar could end up with  DNSSec data. In case he is DNSSec
> accredited he might be interested to keep his DNSSec Data synchronized with
> the data at the registry originated by CDS. That is exactly our use case
> where we want to use the change poll extension.
>
> Martin
> ________________________________________
> Von: regext [[e-mail]]&quot; im Auftrag von &quot;Patrick
> Mevzek [[e-mail]]
> Gesendet: Montag, 16. Juli 2018 20:31
> 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 19:58, Gould, James wrote:
> > 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.
>
> James, please, again, take into account some real life examples that
> happen today:
>
> registries restrict the use of secDNS at login for only the registrars
> having passed
> a specific accreditation test (trying to login with it without prior
> registry vetting triggers an authentication error, so the registrar can
> only do its business if it removes this extension from list at login)
> thus, in your case (just removing the content), a registrar not wanting to
> do DNSSEC and not wanting to transfer
> to him a currently DNSSEC-enabled domain will have no way to know that.
>
> And saying to registrars: "then pass registry accreditation tests to be
> able to login with secDNS and see **others** domain names with secDNS data
> while you do not want to do any DNSSEC related stuff", is certainly not
> going to fly...
>
> As long as we take into account only some cases and not others we will
> never be
> able to deliver an extension used by multiple registries.
> Also, before anything happen I will be very interested by intention of
> support
> (which means deployment) from registries.
>
> Otherwise, like I said, this problem exists since EPP started so it is not
> new,
> and it seems the current status quo fits most of the player (due to the
> number of people
> having participated here), so we are maybe devoting resources to trying to
> design
> something perfect... that noone will then use :-(
>
> --
>   Patrick Mevzek
>
> _______________________________________________
> regext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/regext
>
> _______________________________________________
> regext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/regext
>
-- 
Ulrich Wisser
[e-mail]