Re: Fwd: New Version Notification for draft-gieben-epp-keyrelay-00.txt

Interesting draft. I hope that registrars warm to the idea and implement
it. A few high level questions/comments:

Implementing this is of arguable benefit to a registrar on the losing end.
Do you have a plan to encourage registrars to use it such that it will see
success? Do you have the buy in from existing registrars?


Keyrelay messages provide the losing registrar with early notification of
an imminent transfer. Do you foresee any potential issues with this, for
example the losing registrar attempting to (intentionally or accidentally)
block or delay the transfer. I'm thinking that a registrar could be
justified in updating the domain authinfo a few days after giving it out
for security reasons, thus forcing the registrant to obtain a new authinfo
code for the transfer itself. This delay could cause the domain to pass a
critical date (for example an expiration date or other relevant date
depending on registry lifecycle and policy).


I would suggest that an error should be returned for uploading a key for a
domain name sponsored by a registrar who has not implemented this
extension. This may be considered an "optimisation" at the registry level,
however I question if early failure would better inform the gaining
registrar? If so a specific code/message may be described to promote
interoperability.

Would you consider including reasons under which a registry should or
should not reject the command? For example I would assume there is no
reason for this to succeed should no key material be associated with the
domain on receipt of the <keyrelay> command. Or would you suggest that the
registry not attempt to otherwise interfere with the processing of this
command?

I notice there is no feedback loop from the losing registrar to the
gaining registrar. I assume that the gaining registrar would have to poll
the child zone (with its own timeout) to begin relevant cache-busting
timers? Note that the losing registrar may not provide DNS services for
the given domain name. Or do you consider the transfer pending period of
ample time for caches to expire.

I would assume that a registry may delete an unread keyrelay message from
the queue should a transfer be completed successfully?

Some registrars may prefer to process the message queue in batch,
potentially increasing the time between submission to the server and
retrieval by the losing registrar. Do you foresee any need or reason for a
priority-based, or named message queue to better facilitate keyrelay?

Regards,

James



On 24/01/13 7:21 PM, "Antoin Verschuren" <[email protected]> wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Hi all,
>
>This draft may be of interest to this list.
>At SIDN, we have documented how we intend to implement secure
>transfers of DNSSEC domains and this draft is to describe the EPP
>command we're going to use for that so it may be standardized.
>Comments are welcome to the authors or on this list.
>
>A new version of I-D, draft-gieben-epp-keyrelay-00.txt
>has been successfully submitted by R. (Miek) Gieben and posted to the
>IETF repository.
>
>Filename:	 draft-gieben-epp-keyrelay
>Revision:	 00
>Title:		 Key Relay Mapping for the Extensible Provisioning Protocol
>Creation date:	 2013-01-20
>WG ID:		 Individual Submission
>Number of pages: 11
>URL:
>http://www.ietf.org/internet-drafts/draft-gieben-epp-keyrelay-00.txt
>Status:          http://datatracker.ietf.org/doc/draft-gieben-epp-keyrelay
>Htmlized:        http://tools.ietf.org/html/draft-gieben-epp-keyrelay-00
>
>
>Abstract:
>   This document describes an Extensible Provisioning Protocol (EPP)
>   extension mapping for the purpose of relaying DNSSEC key material
>   from a one registrar to another.  The mapping introduces <keyrelay>
>   as a new command in EPP.
>
>   This command will help facilitating a transfer of a domain while
>   keeping DNSSEC's chain of trust intact.
>
>
>
>
>
>The IETF Secretariat
>
>
>- -- 
>Antoin Verschuren
>
>Technical Policy Advisor SIDN
>Meander 501, PO Box 5022, 6802 EA Arnhem, The Netherlands
>
>P: +31 26 3525500  M: +31 6 23368970
>Mailto: [email protected]
>XMPP: [email protected]
>HTTP://www.sidn.nl/
>
>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.4.11 (GNU/Linux)
>
>iQEcBAEBAgAGBQJRAO8OAAoJEDqHrM883AgnGn8IAI2qQdBdXSYZULn3QlmwUSDS
>nL7QAyaDwTdd6hoc9nU8mMdBYQ7nGFewrhKrrrs5HNY/zxVPjsDgzyJ9duJ5Y9lL
>6TBdPU6zL+1d6gYqyxXWWzo8YnbsBSW3Vf0Nq1YCtdhPkbPOVQwHQKnHdkRr6cjh
>cMCPXTMfXGjLJ08fa6uKSX39S+s7H9iMHO9YwIk4MbNCeyWkwgMvSkSfqQdyQcrt
>Jx0zczOD/RAo55G8nQgSVMHh31h5e71t/qR4QKSsG5EOyDs4dQM3kOmqjBVX90wu
>WyRLtcxr0CYwyFSgltWYx7TEam/1vFLnoLSavUUT9SsbK/3IS+xb7WOaBs66m04=
>=XH3D
>-----END PGP SIGNATURE-----
>_______________________________________________
>provreg mailing list
>[email protected]
>https://www.ietf.org/mailman/listinfo/provreg

_______________________________________________
provreg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/provreg