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
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
