Re: Merging RRP and Whois

[Eric Brunner-Williams in Portland Maine <brunner@nic-naa.net>]

James,

you appear to be observing is that "resellers" aren't contained in
the "registrant-registrar-registry"-tuple, and concluding that the
provisioning protocol, whatever one calls it, must provide access to
3rd-parties, regardless of the modality of the operation (anonymous
read vs write, etc.)

What exactly do you suggest?
	- transparent to registry, registrar delegates registrar
	  access to reseller?
	- opaque to registry, ditto?
	- transparent to registrar, registry extends registrar
	  access to reseller?
	- opaque to registrar, ditto?
	- anonymous access promoted to non-anonymous access at (pick
	  any of r, r, r, r) discretion?
	- registrant acquisition of registrar access upon demand
	- other? (specify, please)

In the above, where the 4th "r" is "reseller", the authentication
problem is not sufficiently degraded to bother with, however if the
4th "r" is "jay-random-other" then, ignoring the utility, necessity
and sufficiency issues which seem to get the values of "some", "don't
know" and "don't know", respectively, the authentication mechanism
needs to scale to ... your figure was one billion endpoints.

Why exactly does the provisioning protocol need to have better scaling
properties than several historic, and current network routing protocols?

Is the protocol stateful, in your mind, and if so, where is the state
held?

What exactly does a registry look like which authenticates, services and
journals provisioning operations originating from a billion endpoints in
some service interval?

This is a lot of headache for something of little utility, which was
my original comment to Patrik. I'm sure you've proved the converse,
I just don't see how.

> On allowing 3rd party to access the RRP servers,
> a) DNSSEC. Keys needs to be exchanged directly with the Registry.
> b) Charter TLDs may requires direct communication with registrant.

Maybe if you offered a "NATS are Evil(tm)" line of proof for the
non-necessity, or worse, of registrars. Seriously, what prevents a
dns registry and registrant from direct key exchange? Where is the
trust model predicated upon the provisioning protocol for e2e transport?
For e2e anything?

Charter TLDs may require direct registry-registrant communication, how
does this become a requirement on the provisioning protocol? Where
is the communication predicated upon the provisioning protocol for
e2e transport? For e2e anything?

> I could also cite examples outside DNS space but I will pass for now.

Thanks for the restraint.

Your comment on iteration in standards processes was interesting. It
was also in the same bit of mail that mentioned some unknown factors
in defense of a "don't know" answer to a specific question. Fortunately,
this is just scope discussion.

Cheers,
Eric