Re: [ietf-provreg] provreg's privacy issue

["Edmon Chung" <edmon@neteka.com>]

Hi Eric,

Good to hear that you have read my stuff. :-)

----- Original Message -----
From: "Eric Brunner-Williams in Portland Maine" <brunner@nic-naa.net>
To
> Some text, on this list, before going off into the delirium of
boiler-plate,
> would have been a blessing, neh?

This reflects some of the things we have done for a particular client.  I
saw some discussion in the group earlier about possibly having an extension
and a public/private toggle type thinking and thought this could be a
starting point.

> I see ...
> o a glob going from registry to registrar (don't tell the iesg),
> o a glob on <info> response, approximately 1k in size,

It is a bit bulky right now.  but really it is whether this concept is good
that is the discussion... we could make it a bit more efficient, but will
loose some flexibility.  We could make it much more efficient if we could
incorporated it directly into domain mapping...

> o a glob on <create> response, ditto,
> o a bi-di glob on <update>!!!

bi-di glob??... what do you mean?

> I see ...
> o two hooks parked at the IANA to hang some coats on, fine.

Ok.  Will take these away in the submission.  I was just doing a plain copy
and "search and replace". :-)

> Not only does this NOT do what our Masters in Moscow, the IESG, require,
> (the glob goes in the wrong direction), the scope of the extension, as
> it is from registry to registrar, cannot apply to any instance of WHOIS
> operated by the registry.

I do not understand why it does not apply to the WHOIS... if the info is
deemed to be "public" it is published, if it is "private" it is not
published at the WHOIS.

> registrar_N (Neteka) initiates a session with registry_V,
>
> registry_V ships back a <dcp> that says 95/46/EC applies
> and all data is not repurposed, there are no recipients
> other than the registry, that it retains the data only
> for the period of registration, plus some operational window
> for the purpose of renewal, and ... everything is _private_
> (except publication via 1034/35).
>
> What data collection / privacy problem remains (that your proposal
> cleverly solves)?

While I am not familiar with 95/46/EC, I think at the least, from the
<create> response I will know which contact info I will need to disclose and
which ones will be hidden and which ones I can later optionally opt-in or
out.  I dont think it "cleverly" solves anything, it just allows the
registry to annouce its policies as well as the client to specify its
preferences.

> registrar_N (Neteka) initiates a session with registry_V,
>
> registry_V ships back a <dcp> that says says anything you want,
> even no <dcp> at all,
>
> registrar_N does a create for mumble,
> registry_V acks appropriately
>
> registrar_N ships an update on mumble that attempts to set a bit,
> e.g., don't publish phone #, provisioned in the prior op,
>
> registry_V nacks inappropriately, and in bad taste.

What do you mean?  Do you mean that the registry advertises that the client
may choose to make phone# private yet not allow it to change the status to
private?  If so, then the registry system is broken...

> Now what happens?

If the registry nacks the status=private operation later because of change
of policy, then there should be probably be out-of-band communication to
announce to all users, also, the client can always do a domain info to check
the status and current registry policy for each info item.

> Why "discover" access policy _after_ a committing a write?

Please clarify what you mean?

Edmon