Re: Merging RRP and Whois

["James Seng/Personal" <jseng@pobox.org.sg>]

Eric,

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

No, I am talking about 3rd parties. They are not reseller, agents
whatever. I am talking about people who has interest in the object
registered (any level, from registry down to the registrant) to Internet
user at large who has no authentication access to objects.

Let me remind you that I do not see ProReg only for DNS uses only. I
have a design in mind which covers beyond the current what you see in
the current players DNS space.

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

These are all related to policies, depending on what kind you referring,
they have different answer. Some people who may use ProReg are thick,
some are thin. Some allows only their resellers to access, some allows
anonymous access. Some requires audit trail, some does not permit any
logging.

What I am suggesting is a requirement for the protocol which can handle
any policy, in whatever configuration for whatever policy set. This is
what I mean by 'not embedding any policy into protocol'.

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

And your problem is...scale? Welcome to IETF.

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

Because it will grow! If it cant grow, then it will get hack to grow in
future which what some say 'kludge'.

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

In design I am still drafting, yes. And it is held at both end. But I do
not see that enforce as an requirement.

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

A service whereby they can/may authenticate billion of users in some
distributed directory lookup mechansim. (Note, I am *not* suggesting it
must/should be DNS).

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

Great. So what why not? :-)

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

In the DNS space, there are a lot of Charter TLDs. Beyond the DNS space,
there are more. Not every registry in the world is "open", pay "$6 per
registration and you get one". I am currently at Amsterdam and a couple
of European Registries did mention the lack of support of
charter/policied TLDs in the current RRP spec.

Hence, I do see a requirement for some sort of answer to Charter TLD
need.

-James Seng