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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Op 24-01-13 21:51, Gould, James schreef:
>> 
> The draft looks to be a good starting point.  Below is some
> feedback which overlaps a little with Klaus's feedback:
> 

Hi James, thank you for your feedback.

> 1. I too believe that the authinfo should be a required element.
> This is useful for the losing registrar to verify prior to taking
> action.

Ok, that's 2 to 1 then. We can live with a required authinfo element,
we use transfer tokens as well.
I guess registries that don't use tokens can just fill in bogus tokens.

So can sombody explain why authinfo is not mandatory in the transfer
command and should be mandatory here ?
Or do you say it should be mandatory in the transfer command as well
but it's too much work to update the RFC ?

(In my belief, we just design the protocol, not the registry policy.
Registrars that require tokens can still refuse to follow up on a
keyrelay that is not authenticated.)

> 2. I find it interesting that this is the first example of an EPP
> protocol extension.  You might want to consider making this into a
> mapping where the object is keyrelay.

We were advised not to do so.
First of all, the registry does not need to do anything with the data
but relay to the current registrar of record.
It does not change any registry data. The EPP channel is only used to
facilitate DNS operators that have no other secure communication
channel, but those that do can happily use that other channel, so not
all keys that are transfered by DNS operators might pass the registry.
So the registry does not need to maintain state or track any of these
relay commands.
Though it would still be nice if we could track all the keys that were
relayed through the registry, it would make implementation more
complex, and we heard from some registries that they would only
implement the strictly necessary. A keyrelay without tracking would
not affect their current design, and could be built without touching
the database.
So the question we have is should we design with all the nice to have
features and no implementations, or have implementations first. We
chose the last, KISS, expand if necessary.

> 3. You might want to allow the gaining registrar to pass the key
> along with the associated set of DS records if the registry
> supports the DS Data Interface of RFC 5910.  In this case the
> losing registrar doesn't need to generate the DS and update the
> domain in the registry.  I wouldn't not recommend having the
> registry do any automatic DS updates, so the losing registrar would
> need to support setting the appropriate DS.

First, as the largest DNSSEC registry around, we don't use the DS data
interface at all, but use the Key data interface. The main reason is
that we already envisioned secure DNSSEC transfers where DNSKEY data
needed to be moved around, and we didn't want our registrars to use DS
data for some commands, and DNSKEY data for other commands. Just use
DNSKEY all the time, we will handle DS at the parrent.

But that aside, we did consider on big keyrelay/DS
rollover/transfer/NS change command but it had too many disadvantages.
There are many timers and states involved in DNSSEC, and especially in
DNS operator changes.
When all data comes in at once at the registry, it means the registry
must set and guard all the timers that are involved, and do all the
checks of steps that need to be performed in order. It mandates the
registrars and DNS operators to follow that complex schema, and things
really break if they don't.
By cutting things up in standard small steps, the registrar is in
control, and can initiate every step based on his own judgment and
standard timers he uses.
By breaking it up in steps, it also means commands can be reused. They
are standard steps. A transfer is for example only a change of
registrar of record, and that remains so. An NS change is also no
different with or without DNSSEC.
But the major drawback is determining the registrar of record, and
which registrar can request changes at the registry. By introducing
this keyrelay command that does not change any data at the registry,
the losing registrar stays in control of the domain at the registry
until a clean transfer command has been issued. Changes to the domain
before the transfer are done by the losing registrar, and changes
after the transfer are done by the gaining registrar.


- -- 
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)

iQEcBAEBAgAGBQJRAnIWAAoJEDqHrM883AgncDIH/iB+tg5ls93RXOtWtkPza8oA
Kt2IBmXuHpOeFb5sWHkANF00Fg8Qf+h/KQHaW2MJ1B0qH6qe9W3yshCAgsDJolhm
KsF03Qkt867svevZR15LH2LvYIOGJANF49RffWnPHi5fhw4yjjYAN+VBFN24Gmkb
hiTaCle64sEiVjQKGjYEuLrWpZkQBTtoQsESyouQM8ITPB0moaTcu4UNPvY+1dC3
dg3QGYMgEFsxg2n11TJwpAOxbESKoMEPuxwEnd4gbQp5ptIdz1vHX2FexF5BoDmH
TWuszzXGMwgNzO3cLnoAYxvYv/vR5EprGCwMpEyJcDCasdN1dq4a2t+GeZ/ZTJs=
=x/jK
-----END PGP SIGNATURE-----
_______________________________________________
provreg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/provreg