headers
Edward Lewis | 2 Jan 2003 21:50

Re: Updated (and hopefully the last) EPP Privacy Proposal

At 13:31 -0500 12/30/02, Joe Abley wrote:
>It might be worth mentioning that neither of these proposals touch the
>base EPP spec. I don't see how privacy concerns should stop the base EPP
>spec from proceeding, when it seems clear that their scope is limited to
>the object binding specifications which deal with data.

The crudest answer to this is that the IESG won't permit the 
documents to progress without addressing privacy concerns - whether 
or not the proposed solutions touch the base spec.  That is why we 
must address the problem.

--

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer
Permalink | Reply | 3 comments |
headers
Edward Lewis | 7 Jan 2003 20:40

privacy

Over the past few weeks the primary concern of the WG has been 
preparing an answer to the IESG comments.  The one sticking point has 
been the comment to provide privacy information at a more granular 
level that we now provide.

There was a meeting of the IESG members involved, your chairs, and 
Scott to review the state of the issue last month.  The outcome of 
that phone call was sent by Scott to the list.  I've seen responses 
from just two folks publicly and one privately.  I've been hoping for 
more - and more positive responses.

First I want to make it clear that Scott isn't pushing this issue 
back on to the table because we wants to.  This is an issue on which 
we are getting feedback from the IESG, and they hold sway over our 
documents, as in they have the final word.  They are reasonable 
folks, but they do hold the final word.

I promised Scott that I'd wait until today to let folks that have 
been out of the office over the past two weeks (plus a day to 
download all the pending mail) before prompting the group another 
time to consider this issue.

The crux of the issue is, there are situations in which a registrar 
may wish to alter the default privacy considerations for data when 
interacting with a registry.  Not all registrar-registry environments 
will need this flexibility, but there is a claim that some exist.  (I 
have no personal, first-hand knowledge of any such environments.)

How can we accomodate such environments?  That is the basic question.
(Continue reading)

Permalink | Reply | 5 comments |
headers
Rick Wesson | 7 Jan 2003 22:43

Re: privacy


Ed,

I have some thoughts on this. I prefered the capability in scott's second
to the last proposal [1] -- I also have an issue with the IESG deciding
what in the most appropiate methodology.

finally I would appreciate it if the IESG would post these discussion to
the public list as private discussions are just that, private. Since we
are discussing the privacy of end-users information (that will eventually
be published in whois) it seems silly that we are not involved in the
discussion and decision process on this topic.

Lets put the proposal [1] back on the table and if the IESG has an issue
with it lets here from the IESG in this wg, not through our
DOCUMENT-EDITOR or the CHAIR but involve those members of the IESG that
have a problem with it.

-rick

[1] http://www.cafax.se/ietf-provreg/maillist/2002-12/msg00093.html

On Tue, 7 Jan 2003, Edward Lewis wrote:

> Over the past few weeks the primary concern of the WG has been
> preparing an answer to the IESG comments.  The one sticking point has
> been the comment to provide privacy information at a more granular
> level that we now provide.
>
> There was a meeting of the IESG members involved, your chairs, and
(Continue reading)

Permalink | Reply | 4 comments |
headers
Edward Lewis | 7 Jan 2003 23:04

Re: privacy

Note that I cut off the IESG from the reply - this isn't something to 
clutter them up with.

In as mush as I appreciate where Rick's coming from, I'd just like to 
solve the problem at hand, the privacy issue.  Issues concerning the 
IESG interface (I admit that there are some in general) are being 
discussed elsewhere, i.e.:
    (problem-statement-request <at> alvestrand.no for subscriptions to that).

It's not that I don't want to hear about IESG interface problem - 
even though I really don't - it's that I don't want to hear about 
that issue here.  If you get my drift.

Okay, but I did say that we are stuck because the IESG has said we 
have to address their concerns.  I meant this to be the reason why 
Scott has had the unenviable task of raising once again the privacy 
issue.  I did not mean this to be a complaint about the IESG 
stonewalling us.  If the WG has sufficient reason for us to not 
address an IESG comment, we need to build a case for that.  It's not 
like the IESG can't change their mind about an issue.

As far as the privacy issue discussion, everything that was discussed 
between "us" has been posted to the provreg list.  BTW, the entire 
call was on clarifying the comments on privacy (which are on the mail 
list archive site).  No document modifying "decisions" or even 
suggestions were made.

Let me ask this of the WG group:

Is there a reason not to add more granularity to the privacy specification?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Patrik Fältström | 7 Jan 2003 23:28
Picon
Favicon

Re: privacy

On tisdag, jan 7, 2003, at 22:43 Europe/Stockholm, Rick Wesson wrote:

> I have some thoughts on this. I prefered the capability in scott's 
> second
> to the last proposal [1] -- I also have an issue with the IESG deciding
> what in the most appropiate methodology.

What IESG want is _some_ mandatory to implement mechanism which makes 
it possible for the registrar to say to the registry "Do not disclose 
this attribute to a third party". If the wg want to have the mandatory 
to implement mechanism more powerful than that, fine. What is not ok is 
the protocol not having any mandatory to implement privacy mechanism in 
it, only extensions.

> finally I would appreciate it if the IESG would post these discussion 
> to
> the public list as private discussions are just that, private.

The issues IESG has are posted on the I-D tracker, and it is up to the 
editor and wg chair (and that way the wg) how to resolve the issues. 
What we as IESG members have got are suggestions on solutions, and we 
have (as far as I remember) said yes to all proposals.

What we have heard back from wg chairs etc is that they have got 
private messages back from wg members which have issues with the 
proposals, issues with privacy being mandatory _at_all_. They have 
checked with IESG whether things really need to be mandatory, and the 
answer is yes.

What is the difference between what you here point to, and what Scott
(Continue reading)

Permalink | Reply | 2 comments |
headers
McGarry, Tom | 8 Jan 2003 00:12
Favicon

RE: privacy

I don't think you've explained why the IESG wants this to be mandatory?  (If
you have, I apologize, can you repeat it or point us to it?)

-----Original Message-----
From: Patrik Fältström [mailto:paf <at> cisco.com]
Sent: Tuesday, January 07, 2003 5:29 PM
To: Rick Wesson
Cc: Edward Lewis; 'ietf-provreg <at> cafax.se'; iesg <at> ietf.org; rick <at> ar.com
Subject: Re: privacy

On tisdag, jan 7, 2003, at 22:43 Europe/Stockholm, Rick Wesson wrote:

> I have some thoughts on this. I prefered the capability in scott's 
> second
> to the last proposal [1] -- I also have an issue with the IESG deciding
> what in the most appropiate methodology.

What IESG want is _some_ mandatory to implement mechanism which makes 
it possible for the registrar to say to the registry "Do not disclose 
this attribute to a third party". If the wg want to have the mandatory 
to implement mechanism more powerful than that, fine. What is not ok is 
the protocol not having any mandatory to implement privacy mechanism in 
it, only extensions.

> finally I would appreciate it if the IESG would post these discussion 
> to
> the public list as private discussions are just that, private.

The issues IESG has are posted on the I-D tracker, and it is up to the 
editor and wg chair (and that way the wg) how to resolve the issues.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Hollenbeck, Scott | 8 Jan 2003 13:17
Picon
Favicon

RE: privacy

> The crux of the issue is, there are situations in which a registrar 
> may wish to alter the default privacy considerations for data when 
> interacting with a registry.  Not all registrar-registry environments 
> will need this flexibility, but there is a claim that some exist.  (I 
> have no personal, first-hand knowledge of any such environments.)
> 
> How can we accomodate such environments?  That is the basic question.

FWIW the attribute-based proposal is the one most closely aligned with
"standard" XML practice, if such a thing exists.  XML attributes are
typically used to describe the data contained within an element, and that's
what's being proposed.

The other proposal I floated (the <doNotDisclose> proposal) could also work,
but it means carrying the same element data twice: once in the "normal"
place and a second time to mark it.  I can understand why some of the folks
who've been doing implementations might find it easier to incorporate into
current code, but I don't think it's the best architectural solution.

Just my two cents...

-Scott-
Permalink | Reply | 7 comments |
headers
Joe Abley | 8 Jan 2003 17:15

Re: privacy


On Wednesday, Jan 8, 2003, at 07:17 Canada/Eastern, Hollenbeck, Scott 
wrote:

>> The crux of the issue is, there are situations in which a registrar
>> may wish to alter the default privacy considerations for data when
>> interacting with a registry.  Not all registrar-registry environments
>> will need this flexibility, but there is a claim that some exist.  (I
>> have no personal, first-hand knowledge of any such environments.)
>>
>> How can we accomodate such environments?  That is the basic question.
>
> FWIW the attribute-based proposal is the one most closely aligned with
> "standard" XML practice, if such a thing exists.  XML attributes are
> typically used to describe the data contained within an element, and 
> that's
> what's being proposed.

Would it be possible to hear the set of requirements to which the 
attribute solution forms an acceptable solution?

I suspect that the requirements need work (or at least they need input 
based on real-life registry policy, as opposed to policy assumed by the 
IESG).

As Rick mentioned, if the IESG could raise their concerns on this list 
it would be a lot easier to understand where they are coming from.

Joe
(Continue reading)

Permalink | Reply | 6 comments |
headers
Rick Wesson | 8 Jan 2003 17:29

Re: privacy


Randy,

> > I have some thoughts on this. I prefered the capability in scott's second
> > to the last proposal [1] -- I also have an issue with the IESG deciding
> > what in the most appropiate methodology.
>
> the iesg members specifically said we did not want to decide the method,
> though some decades of programming practice does suggest one.  what we
> do care is that there is a mechanism which may be invoked by policy.

would you please discuss your rationale in the light that all gTLD
registrations will also be published in the whois negating any utility of
your requirement.

furthermore, since gTLD registries and registrars (the primary users of
this work product) are required by contract to publicly publish this
information, the paries using this privacy enhanced protocol would be
exposed to a serious liability concern as registrants expect information to
be private but contracts require it be published.

IMHO, privacy needs to be addressed in a superset of the protocols (epp,
crisp, whois) and a specific group tasked with that job; requesting
prov-reg to preform this task appears to be short sighted knee-jerk
reaction.

I'd appreciate it if you either enlighten us with more detail or
politely back off.

-rick
(Continue reading)

Permalink | Reply | 16 comments |
headers
Stephane Bortzmeyer | 8 Jan 2003 17:50
Picon

Re: privacy

On Wed, Jan 08, 2003 at 08:29:29AM -0800,
 Rick Wesson <wessorh <at> ar.com> wrote 
 a message of 32 lines which said:

> IMHO, privacy needs to be addressed in a superset of the protocols (epp,
> crisp, whois) and a specific group tasked with that job; 

This is very reasonable (sorry for the fine members of the Provreg
group but last-minute attempts to solve a problem as large as the
privacy policies in a few lines of patch to the I-D are quite
laughable).

But such a group already exists: W3C's P3P group. P3P can be used for
more than Web sites and they are willing to do what it needs to extend
their framework to registry privacy policies.
Permalink | Reply | 1 comment |

Gmane