Subject: [provreg] Fwd: New Version Notification for draft-gieben-epp-keyrelay-03.txt

From: Antoin Verschuren <[email-masked]>
Date: Thu, 18 Jul 2013 10:38:59 +0200

Hi all,

Last week we submitted a version 03 of the EPP Keyrelay draft.

http://www.ietf.org/internet-drafts/draft-gieben-epp-keyrelay-03.txt

We would like to inform you that there is now running code and
operational experience for this proposal.

Yesterday, the .nl registry has implemented EPP keyrelay in it's
registry system following the 03 version of the draft, and 2
independent registrars have implemented and used this method
successfully immediately after the release of the new registry software.

Unfortunately reports on their experience is still all in Dutch, but
there will be a more extensive report and white-paper out shortly.
I can tell you though that the experience was very positive. The only
remark the registrars had was that they wish they didn't have to wait
for DNS TTL's to time out, but unfortunately propagation is an
inherent property of DNS.

I would like to solicit for your remarks and support for this draft.
A simple "I like it now" or "go ahead" for the documentation of our
running code would give us a good indication if the document is mature
enough to ask the AD for adoption.

(For those interested to read Dutch:
http://www.sidnlabs.nl/uploads/tx_sidnpublications/wp_2013_EPP-keyrelay_v1.pdf
http://www.ispam.nl/archives/33851/eerste-geautomatiseerde-dnssec-domeinnaam-verhuizing-ter-wereld/#more-33851
http://nieuws.mijndomein.nl/2013/07/17/mijndomein-schrijft-geschiedenis-secure-dnssec-verhuizing/
)

- -------- Origineel bericht --------
Onderwerp: New Version Notification for draft-gieben-epp-keyrelay-03.txt
Datum: Thu, 11 Jul 2013 04:47:02 -0700
Van: <[email-masked]>
Aan: M. Groeneweg <[email-masked]>, R. (Miek) Gieben
<[email-masked]>, Antoin Verschuren <[email-masked]>, Rik
Ribbers <[email-masked]>

A new version of I-D, draft-gieben-epp-keyrelay-03.txt
has been successfully submitted by R. (Miek) Gieben and posted to the
IETF repository.

Filename:	 draft-gieben-epp-keyrelay
Revision:	 03
Title:		 Key Relay Mapping for the Extensible Provisioning Protocol
Creation date:	 2013-07-11
Group:		 Individual Submission
Number of pages: 13
URL:
http://www.ietf.org/internet-drafts/draft-gieben-epp-keyrelay-03.txt
Status:          http://datatracker.ietf.org/doc/draft-gieben-epp-keyrelay
Htmlized:        http://tools.ietf.org/html/draft-gieben-epp-keyrelay-03
Diff:
http://www.ietf.org/rfcdiff?url2=draft-gieben-epp-keyrelay-03

Abstract:
   This document describes an Extensible Provisioning Protocol (EPP)
   extension mapping for the purpose of relaying DNSSEC key material
   from one DNS operator to another, by using the administrative
   registration channel through the registrant, registrar and registry.
   The mapping introduces "<keyrelay>" as a new command in EPP.

   This command will help facilitate changing the DNS operator of a
   domain while keeping the DNSSEC 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-masked]
XMPP: [email-masked]
HTTP://www.sidn.nl/

---

From: Jay Daley <[email-masked]>
Date: Tue, 30 Jul 2013 22:35:25 +1200

> enough to ask the AD for adoption.

Apologies for coming late to this.  

While I generally support the draft there is one key element that I would recommend changing, which is to rename the command to "relay" and make the key data that is relayed the only allowed data for this command at the moment.  I do not think the details of the draft would need to change to accommodate this.

My reasoning for this is that other EPP commands are generic verbs that work with multiple different data sets in different types of registry.  For example the EPP "create" command is reused for creating domains, hosts and contacts.

"keyrelay" by contrast is a combination of the verb and the data that is to be applied.  While there are no uses currently identified it is obvious to me that other data could sensibly be relayed and a generic "relay" verb would allow that new development.  

The wording in the draft is very good at identifying just what a new "relay" command is all about:

	This new category of EPP commands can best be described as	
	"communication command" as it only facilitates communication of data	
	between two EPP clients without changing any objects at the registry.

Rather than a category, a single command is sufficient.

cheers
Jay

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> 
> iQEcBAEBAgAGBQJR56mYAAoJEDqHrM883AgnflMH/3cGU2AxhNGb4w2QZGG40Fal
> V5c2ZDoBMCLQ6jAps5x9AG/o73NV5wmXCB+bRX/2v0CAi8qOMvQouvuTDz5A/tK6
> aX0WSNzwh4SjGqXCuGtCBxHL/Tg2F8Afucm1NGo2Ov9JW1VRNI2NEgBhrYm8+Num
> XvacvA1H81RlMoj116NOMmiHZlayLOiA3DrU6gASbgnOMoYEl5S/0Xkvupu7fRlb
> yINJ5aqWzpkboor6Tmyzg0s3fMmlIhLYEMbOzjGNJhbPhAgqKDz/sqvr6UagGrIt
> lI5YBxTNlQL7CyyvG+YTX8yaszKW5WHAhIbgbPY0lh9tV91Yw6D4lveA7VQ+1uo=
> =ZqJR
> -----END PGP SIGNATURE-----
> _______________________________________________
> provreg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/provreg

-- 
Jay Daley
Chief Executive
.nz Registry Services (New Zealand Domain Name Registry Limited)
desk: +64 4 931 6977
mobile: +64 21 678840
linkedin: www.linkedin.com/in/jaydaley