Subject: RE: [ietf-provreg] the privacy problem statement

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 31 Mar 2003 08:27:51 -0500

> Given that we've had a week to discuss the 'problem' and nothing 
> seems to have risen up to change it (EBW's comments notwithstanding), 
> I think it's safe to assume that the problem is as stated.
> 
> IOW - Let's start looking at the solution.
> 
> 'Course, it's never to complain about the problem statement.  I just 
> want to throw open the doors on proposed answers...

I'd like to propose a solution first described on the mailing list in
December:

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

With a slight modification as proposed by Janusz:

http://www.cafax.se/ietf-provreg/maillist/2002-12/msg00102.html

The element structure could look like this:

<contact:disclose flag="0">
  <contact:email>
  <contact:voice>
</contact:disclose>

The above means that the email address and voice telephone numbers should
not be disclosed (I've modified Janusz' proposal slightly to use a boolean
value for the flag instead of a yes/no enumeration to simply the schema a
bit).  Server policy would determine the default value for disclosure if the
<contact:disclose> element is not provided.

If I remember correctly the feeling of the room in San Francisco was that
this could be limited to the contact mapping.

-Scott-

---

From: George Michaelson <[email-masked]>
Date: Tue, 1 Apr 2003 09:04:09 +1000

> <contact:disclose> element is not provided.

I think this does capture the feeling of the room thus far. 

The side issues are

	this can be set differently for different instances of contact data
	within one object.

	this can be set differrently for different objects in one stream of
	objects

> this could be limited to the contact mapping.

No. I'm less sure we agreed on that. The words I kept hearing were 'social
data' but It wasn't explicit that was limited to contact mapping.

It might be my misunderstanding of what 'social data' and 'contact mapping'
are in this context.

cheers
	-George
-- 
George Michaelson       |  APNIC
Email: [email-masked]    |  PO Box 2131 Milton QLD 4064
Phone: +61 7 3367 0490  |  Australia
  Fax: +61 7 3367 0482  |  http://www.apnic.net

Date: Mon, 31 Mar 2003 10:11:05 -0500
From: janusz sienkiewicz <[email-masked]>
Organization: LibertyRMS Co.
To: Ram Mohan <[email-masked]>
CC: [email-masked]
Subject: Re: side bar, was Re: [ietf-provreg] Our "Privacy Issue"
Sender: [email-masked]

Ram Mohan wrote:

> Ed,
> [snip]
> > I want to avoid the appearance that EPP is perfect.
> > No one is running it operationally yet
>
> Last time I checked, at least half a dozen registries are running EPP
> operationally.  .INFO (02); .ORG(07), .BIZ(04), .US(04?), .AU(05),
> .NL(?)plus a bunch more ccTLDs.

I don't know whether .PL is running EPP operationally but at least there is
(07) implementation presented at RIPE-44.

>
>
> > But it's also apparent that whatever flaws hiding in
> > it are hidden so well not many of us see them.
>
> Not sure the hypothesis is true; exposure of limitations has probably not
> happened - i know a few registry folks who have things they don't much care
> for in EPP, but haven't talked about it on the list.
>
> -ram

Janusz

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Edward Lewis'" <[email-masked]>, [email-masked]
Subject: RE: [ietf-provreg] the privacy problem statement
Date: Mon, 31 Mar 2003 08:27:51 -0500
Sender: [email-masked]

-Scott-

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Edward Lewis'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: [ietf-provreg] References for Today's Host Object Discussion
Date: Mon, 31 Mar 2003 08:17:27 -0500
Sender: [email-masked]

> Unless I am missing something, Scott, can you propose some text that 
> would accommodate nameservers-as-attributes?  Based on:
> 
> >- Allowing a choice between name server host objects and 
> name server domain
> >attributes.
> >    http://www.cafax.se/ietf-provreg/maillist/2001-12/msg00024.html

Sure.  Here's what I have in mind:

This is the structure currently used in the domain mapping to specify name
server host objects:

<element name="ns" type="eppcom:labelType"
 minOccurs="0" maxOccurs="unbounded"/>

This can be changed to be a choice of either host objects or host
attributes, like this:

<element name="ns" type="domain:nsType" minOccurs="0"/>
<!-- Name servers are optional. -->

<complexType name="nsType">
  <choice>
    <element name="hostObj" type="eppcom:labelType"
     maxOccurs="unbounded"/>
    <element name="hostAttr" type="domain:hostAttrType"
     maxOccurs="unbounded"/>
  </choice>
</complexType>
<!-- Name servers are either objects or attributes. -->

<complexType name="hostAttrType">
  <sequence>
    <element name="name" type="eppcom:labelType"/>
    <element name="addr" type="host:addrType"
     minOccurs="0" maxOccurs="unbounded"/>
  </sequence>
</complexType>
<!-- If attributes, addresses are optional and follow the
structure defined in the host mapping. -->

I'd then have to add text to explain how this works in the descriptions of
the <create> and <update> commands, but that text would be pretty
straightforward.  Note that this structure allows one to use either host
objects as name servers or host attributes as name servers, but it doesn't
allow mixing of the two on a domain object.  I remember there being some
opposition to the idea of mixing the modes back when this was originally
discussed on the list, so I've elected to not allow it here.

The benefit to this is that it allows client and server to specify name
servers without using host objects if they so desire.  A server operator
would be free to implement a policy that requires host objects if they're
supported, or to not support host objects at all.

I might have to replicate all of the host address elements in the domain
mapping to completely eliminate the dependency on the host mapping (note
that the elements above require an import of the host schema to obtain the
address data type).  Consider what you see above as a proposal that might
need to be modified once I start testing it a bit.

-Scott-

From: "Edmon Chung" <[email-masked]>
To: "Claus Dahl" <[email-masked]>, <[email-masked]>
Subject: Re: side bar, was Re: [ietf-provreg] Our "Privacy Issue"
Date: Mon, 31 Mar 2003 00:46:14 -0500
Sender: [email-masked]

It will be soon after the RFCs are published.
SG Registrars, including ascio will also get a new API (which should
function the same). :-)
Edmon

----- Original Message -----
From: "Claus Dahl" <[email-masked]>
To: <[email-masked]>
Sent: Friday, March 28, 2003 9:12 AM
Subject: RE: side bar, was Re: [ietf-provreg] Our "Privacy Issue"

> .SG is EPP by name only - it does not conform to the specs at all.
>
> Claus
>
> -----Original Message-----
> From: Edmon Chung [mailto:[email-masked]]
> Sent: 28. marts 2003 14:48
> To: Asbjorn Mikkelsen; Ram Mohan
> Cc: [email-masked]
> Subject: Re: side bar, was Re: [ietf-provreg] Our "Privacy Issue"
>
>
> > On Fri, 2003-03-28 at 03:10, Ram Mohan wrote:
> > > Last time I checked, at least half a dozen registries are running EPP
> > > operationally.  .INFO (02); .ORG(07), .BIZ(04), .US(04?), .AU(05),
> > > .NL(?)plus a bunch more ccTLDs.
> >
> > ...and .NAME(05)...
> >
> ..and .SG(04) and soon to be .BZ(04 or 07)
>
> Edmon
>
>

From: Claus Dahl <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: side bar, was Re: [ietf-provreg] Our "Privacy Issue"
Date: Fri, 28 Mar 2003 15:12:34 +0100
Sender: [email-masked]

.SG is EPP by name only - it does not conform to the specs at all.

Claus

-----Original Message-----
From: Edmon Chung [mailto:[email-masked]]
Sent: 28. marts 2003 14:48
To: Asbjorn Mikkelsen; Ram Mohan
Cc: [email-masked]
Subject: Re: side bar, was Re: [ietf-provreg] Our "Privacy Issue"

> On Fri, 2003-03-28 at 03:10, Ram Mohan wrote:
> > Last time I checked, at least half a dozen registries are running EPP
> > operationally.  .INFO (02); .ORG(07), .BIZ(04), .US(04?), .AU(05),
> > .NL(?)plus a bunch more ccTLDs.
> 
> ...and .NAME(05)...
> 
..and .SG(04) and soon to be .BZ(04 or 07)

Edmon

From: Antony Perkov <[email-masked]>
To: [email-masked]
Subject: RE: side bar, was Re: [ietf-provreg] Our "Privacy Issue"
Date: Fri, 28 Mar 2003 14:09:52 -0000
Sender: [email-masked]

> > > Last time I checked, at least half a dozen registries are 
> > > running EPP operationally.  
> > > .INFO (02); .ORG(07), .BIZ(04), .US(04?), .AU(05),
> > > .NL(?)plus a bunch more ccTLDs.
> > 
> > ...and .NAME(05)...
> > 
> ...and .SG(04) and soon to be .BZ(04 or 07)

and .COOP(06)

To: [email-masked]
Subject: [ietf-provreg] Fd: Re: BH: Introducing the Beyond HTTP (BH) Task Force
Date: Fri, 28 Mar 2003 16:36:54 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

Anyone want this? I prefer not to "laze" (or however that is spelt),
since I do such a bad job of contributing. I've re-arrainged the p3p
mail to put my-take-on-epp (tm) first, for this list's benefit.

------- Forwarded Message

> List-Id: <public-p3p-spec.w3.org>
> 
> On Friday 21 March 2003 05:48, Eric Brunner-Williams in Portland Maine 
> wrote:
> > Here are a couple of things where I've attempted to take policies that
> > are { similar to | derived from | stolen and wrecked | ... } P3P's and
> > make mechanisms other than some set of HTTP methods transport apply.
> 
> Thanks Eric ...
> 
>                       I've briefly looked into each of of the apps below 
> looking for salient requirements and/or features of a scenario that might 
> be relevant. Please correct me if you think I've missed something.

[this isn't the first item]

> > 	3. PROVREG WG, an IETF WG (current). The problem domain defined
> > 	   by Verisign's RRP protocol, using EBNF as the formal syntax,
> > 	   is slightly restated in EPP, using XML as the formal syntax.
> 
> I'm unfamiliar with this work but I've poked about on:
>   http://www.ietf.org/html.charters/provreg-charter.html
>   http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-09.txt
> and see they have a :
>   """   - A <dcp> (data collection policy) element that contains child
>     elements used to describe the server's privacy policy for data
>     collection and management."""
> with an {access, purpose, retention}, elements based on P3P. Since this is 
> active work, I think it makes sense to ask them why don't they use the 
> elements from P3P itself? And if there are reasons, we'd appreciate the 
> feedback. Do you have connections with this work, could you help start that 
> conversation?

[ this is where the first item begins]

> > 	1. CPExchange, a customer profile exchange application-layer
> > 	   protocol, with no transport binding. The DTD for this and
> > 	   the pre-bubble bumpf are still available at
> > 	   http://www.cpexchange.org/
> 
> This appears to be an extension of the P3P privacy vocabulary with a more 
> extensive XML data profile based on XML Schema data types. It appears they 
> have the significant portion with {Access, Purpose, Retention, Recipient}. 
> Because it's based on a 2000 snapshot of P3P I can't discern any particular 
> divergence in the privacy vocabulary because of this app's context. I can 
> conclude that they felt there was a need for more extensive and XML Schema 
> typed data structures that would perhaps be of interest to the P3P Schema 
> taskforce.
> 
> > 	2. HTTP WG, an IETF WG (concluded). During the last year of the
> > 	   WG, Dan Jaye contributed a draft that extended the Kristol,
> > 	   Montulli draft on the state management mechanism, RFC 2965.
> > 	   This draft has expired, but I have it (co-author). The IESG
> > 	   published a note written by Moore and Freed (RFC 2964), on
> > 	   the problem domain, observing that some uses of the mechanism
> > 	   were harmful, and depricated policied cookies.
> 
> I followed this work back in the day and my conclusion would be that there 
> was a requirement for terse expression. This appears to be satisfied with 
> compact policies and I would expect other apps with a similar requirement 
> to use them, or perhaps in the future a binary-XML representation of the 
> complete markup...? I've included this in
>   http://www.w3.org/P3P/2003/04-beyond-http#sec-Others
> 

[part #3 delted here, moved up]

> ------- End of Forwarded Message

Date: Fri, 28 Mar 2003 11:57:19 -0500
To: "[email-masked]'" <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: RE: [ietf-provreg] References for Today's Host Object Discussion
Sender: [email-masked]

Speaking in a co-chair capacity,

I think that it is fair to reopen the issue.  Jaap and I are aware of 
a significant number of silent speakers that really want to be 
host-object free.

Answering to the charge that these documents sailed through last call 
without comment on this topic (albeit a topic discussed on the list), 
EPP has been generating wider interest as it progresses.

There's always the trade-off of delay and feature adding, and mission 
creep versus focus.  There is no clear rule that applies to each 
situation, so the question:

    Should EPP define a host-object-less model now?

is one that can't be answered categorically (the "now" thing).  But I 
think that it seems worthwhile to do so now - while we are also 
preparing to answer the privacy issue.

Unless I am missing something, Scott, can you propose some text that 
would accommodate nameservers-as-attributes?  Based on:

>- Allowing a choice between name server host objects and name server domain
>attributes.
>    http://www.cafax.se/ietf-provreg/maillist/2001-12/msg00024.html

Joe offered to help..."I would be happy to contribute text if this 
sounds like a reasonable approach."

At 18:01 -0500 3/24/03, Hollenbeck, Scott wrote:
>I'm not one of the people responsible for determining consensus, but I can
>say that the domain document has completed both WG and IETF last calls with
>the currently specified feature set.  Our chairs can, of course, direct me
>to change something if WG consensus is to make a change.  I'd prefer to keep
>things as-is, though, because this is _not_ a new argument and we'll have a
>chance to address this again when considering what to do when going from
>proposed to draft.
>
>One of the things I intend to do once we're there is capture the outstanding
>issues in an I-D that can be used to seed the proposed-to-draft discussion.
>It would be helpful if people who have issues with any current features
>could send me a note (off-list is OK) describing what they don't like _and_
>a suggested solution.  We might then have the start of a pretty good problem
>statement for EPP 1.1 or 2.0.
>
>-Scott-

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

I've had it with world domination.  The maintenance fees are too high.

Date: Fri, 28 Mar 2003 11:59:11 -0500
To: [email-masked]
From: Edward Lewis <[email-masked]>
Subject: [ietf-provreg] the privacy problem statement
Cc: [email-masked]
Sender: [email-masked]

'Course, it's never to complain about the problem statement.  I just 
want to throw open the doors on proposed answers...
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

I've had it with world domination.  The maintenance fees are too high.

From: "Edmon Chung" <[email-masked]>
To: "janusz sienkiewicz" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: [ietf-provreg] privacy profile for domain mapping
Date: Fri, 28 Mar 2003 11:18:20 -0500
Sender: [email-masked]

That is quite true.  There could be potential conflicts.
We need statements that says the registry privacy policy will prevail, next
the contact privacy preference will prevail and then domain preference is
taken into consideration (which is what happens in our implementation for
SG).

i.e.
If the registry policy is that Addr MUST be displayed for the domain, then
even if the contact says dnd it can be disclosed (OR the policy can say that
the upate/creation must fail)

If the contact privacy preference say for email is dnd while the domain
profile says ok for disclosure (AND that the Registry policy allows an
opt-out of the info) then the email must NOT be disclosed (OR the policy can
say that the update/creation must fail)

OR a registry MUST choose to do privacy for domain mapping or contact
mapping only and that they are mutually exclusive.

In terms of dependence on contact mapping, that is not necessarily the case.
If the privacy elements in domain mapping does NOT exist in the contact
mapping, then the policy may say that the field is either ignored, or that
the transaction should fail.

Edmon

----- Original Message -----
From: "janusz sienkiewicz" <[email-masked]>
To: "Edmon Chung" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, March 28, 2003 10:51 AM
Subject: Re: [ietf-provreg] privacy profile for domain mapping

> I see a general problem with all the proposed variants. They break modular
> architecture of EPP protocol. With the current structure of the protocol
there
> is not much assumed in domain object mapping about contact object mapping
and
> other object mappings. All the proposed variants make domain object
mapping
> depended on contact object mapping.
>
> I see also practical problems with the proposals. It is possible to set
> address, email privacy element/attribute to true in <domain:privacy>
block.
> Meanwhile the owner of the contact object (which does not have to be the
same
> as domain object) may set privacy element/attribute to false for address
and
> email elements. That will lead to a situation when the domain owner
assumes his
> privacy is protected and at the same time it is not. Someone can use whois
to
> query the contact object to see address and email.
>
> Janusz Sienkiewicz
>
> Edmon Chung wrote:
>
> > At the SF meeting we discussed adding privacy profile for contact
mapping,
> > but I think it is important to also add it to domain mapping as well, in
> > fact, I think being able to handle a per domain profile model is even
more
> > important because the same contact may be the admin contact as well as
say
> > the tech contact and the disclosure requirements may also be different
> > within the same domain.
> >
> > Moreover, one contact may be associated with multiple domains, and each
> > domain may have different preference.  (e.g. a domain registered in EU
and a
> > domain registered in US with the same contact might have to/want to
> > disclose/hide different info)
> >
> > Anyway, here are four ways I have thought of to add the privacy elements
for
> > domain mapping:
> > (p=0: ok to disclose, p=1: privacy preserved)
> >
> > (1) adding an optional <domain:privacy> block:
> >
> > ...
> > <domain:privacy>
> >   <domain:registrant>
> >     <domain:contactname p="0"/>
> >     <domain:contactaddr p="1"/>
> >     <domain:contactvoice p="1"/>
> >   </domain:registrant>
> >   <domain:contact>
> >     <domain:contactid type="admin">sh8013</domain:contactid>
> >     <domain:contactPoInfo type="int">
> >       <domain:contactcc p="1"/>
> >     </domain:contactPoInfo>
> >   </domain:contact>
> >   <domain:contact>
> >     <domain:contactid type="tech">sh8013</domain:contactid>
> >     <domain:contactemail p="1"/>
> >     <domain:contactvoice p="1"/>
> >   </domain:contact>
> > </domain:privacy>
> > ...
> >
> > (2) changing <domain:contact> element to include privacy profile for
each
> > contact/registrant
> >
> > ...
> > <domain:registrant>
> >   <domain:registrantid>jd1234</domain:registrantid>
> >   <domain:contactname p="0"/>
> >   <domain:contactaddr p="1"/>
> >   <domain:contactvoice p="1"/>
> > </domain:registrant>
> > <domain:contact>
> >   <domain:contactid type="admin">sh8013</domain:contactid>
> >   <domain:contactPoInfo type="int">
> >     <domain:contactcc p="1"/>
> >   </domain:contactPoInfo>
> > </domain:contact>
> > <domain:contact>
> >   <domain:contactid type="tech">sh8013</domain:contactid>
> >   <domain:contactemail p="1"/>
> >   <domain:contactvoice p="1"/>
> > <domain:contact>
> > ...
> >
> > (3) including everything as attributes in the
<domain:contact/registrant>
> > element
> >
> > ...
> > <domain:registrant name="0" addr="1"
voice="1">jd1234</domain:registrant>
> > <domain:contact type="admin" poInfoIntcc="1">sh8013</domain:contact>
> > <domain:contact type="tech" voice="1" email="1">sh8013</domain:contact>
> > ...
> >
> > (4) combination of 2 & 3 (postalInfo has a further child element while
> > others are grouped as attributes)
> >
> > ...
> > <domain:registrant>
> >   <domain:registrantid>jd1234</domain:registrantid>
> >   <domain:privacy type="postalInfo" t="int">
> >     <domain:postalprivacy name="0" addr="1"/>
> >   </domain:privacy>
> >   <domain:privacy type="others" voice="1" email="0"/>
> > </domain:registrant>
> > <domain:contact>
> >   <domain:contactid type="admin">sh8013</domain:contactid>
> >   <domain:privacy type="postalInfo" t="int">
> >     <domain:postalprivacy cc="1"/>
> >   </domain:privacy>
> > </domain:contact>
> > <domain:contact>
> >   <domain:contactid type="tech">sh8013</domain:contactid>
> >   <domain:privacy type="others" voice="1" email="1"/>
> > <domain:contact>
> >
> > There could also be a (5)th apporach that is to combine 1 & 4 for a
smaller
> > <domain:privacy> block.
> > Thoughts?
> > Edmon

Date: Fri, 28 Mar 2003 10:51:30 -0500
From: janusz sienkiewicz <[email-masked]>
Organization: LibertyRMS Co.
To: Edmon Chung <[email-masked]>
CC: [email-masked]
Subject: Re: [ietf-provreg] privacy profile for domain mapping
Sender: [email-masked]

I see a general problem with all the proposed variants. They break modular
architecture of EPP protocol. With the current structure of the protocol there
is not much assumed in domain object mapping about contact object mapping and
other object mappings. All the proposed variants make domain object mapping
depended on contact object mapping.

I see also practical problems with the proposals. It is possible to set
address, email privacy element/attribute to true in <domain:privacy> block.
Meanwhile the owner of the contact object (which does not have to be the same
as domain object) may set privacy element/attribute to false for address and
email elements. That will lead to a situation when the domain owner assumes his
privacy is protected and at the same time it is not. Someone can use whois to
query the contact object to see address and email.

Janusz Sienkiewicz

Edmon Chung wrote:

> At the SF meeting we discussed adding privacy profile for contact mapping,
> but I think it is important to also add it to domain mapping as well, in
> fact, I think being able to handle a per domain profile model is even more
> important because the same contact may be the admin contact as well as say
> the tech contact and the disclosure requirements may also be different
> within the same domain.
>
> Moreover, one contact may be associated with multiple domains, and each
> domain may have different preference.  (e.g. a domain registered in EU and a
> domain registered in US with the same contact might have to/want to
> disclose/hide different info)
>
> Anyway, here are four ways I have thought of to add the privacy elements for
> domain mapping:
> (p=0: ok to disclose, p=1: privacy preserved)
>
> (1) adding an optional <domain:privacy> block:
>
> ...
> <domain:privacy>
>   <domain:registrant>
>     <domain:contactname p="0"/>
>     <domain:contactaddr p="1"/>
>     <domain:contactvoice p="1"/>
>   </domain:registrant>
>   <domain:contact>
>     <domain:contactid type="admin">sh8013</domain:contactid>
>     <domain:contactPoInfo type="int">
>       <domain:contactcc p="1"/>
>     </domain:contactPoInfo>
>   </domain:contact>
>   <domain:contact>
>     <domain:contactid type="tech">sh8013</domain:contactid>
>     <domain:contactemail p="1"/>
>     <domain:contactvoice p="1"/>
>   </domain:contact>
> </domain:privacy>
> ...
>
> (2) changing <domain:contact> element to include privacy profile for each
> contact/registrant
>
> ...
> <domain:registrant>
>   <domain:registrantid>jd1234</domain:registrantid>
>   <domain:contactname p="0"/>
>   <domain:contactaddr p="1"/>
>   <domain:contactvoice p="1"/>
> </domain:registrant>
> <domain:contact>
>   <domain:contactid type="admin">sh8013</domain:contactid>
>   <domain:contactPoInfo type="int">
>     <domain:contactcc p="1"/>
>   </domain:contactPoInfo>
> </domain:contact>
> <domain:contact>
>   <domain:contactid type="tech">sh8013</domain:contactid>
>   <domain:contactemail p="1"/>
>   <domain:contactvoice p="1"/>
> <domain:contact>
> ...
>
> (3) including everything as attributes in the <domain:contact/registrant>
> element
>
> ...
> <domain:registrant name="0" addr="1" voice="1">jd1234</domain:registrant>
> <domain:contact type="admin" poInfoIntcc="1">sh8013</domain:contact>
> <domain:contact type="tech" voice="1" email="1">sh8013</domain:contact>
> ...
>
> (4) combination of 2 & 3 (postalInfo has a further child element while
> others are grouped as attributes)
>
> ...
> <domain:registrant>
>   <domain:registrantid>jd1234</domain:registrantid>
>   <domain:privacy type="postalInfo" t="int">
>     <domain:postalprivacy name="0" addr="1"/>
>   </domain:privacy>
>   <domain:privacy type="others" voice="1" email="0"/>
> </domain:registrant>
> <domain:contact>
>   <domain:contactid type="admin">sh8013</domain:contactid>
>   <domain:privacy type="postalInfo" t="int">
>     <domain:postalprivacy cc="1"/>
>   </domain:privacy>
> </domain:contact>
> <domain:contact>
>   <domain:contactid type="tech">sh8013</domain:contactid>
>   <domain:privacy type="others" voice="1" email="1"/>
> <domain:contact>
>
> There could also be a (5)th apporach that is to combine 1 & 4 for a smaller
> <domain:privacy> block.
> Thoughts?
>
> Edmon

To: "Edmon Chung" <[email-masked]>
cc: "Asbjorn Mikkelsen" <[email-masked]>, "Ram Mohan" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: side bar, was Re: [ietf-provreg] Our "Privacy Issue" 
Date: Fri, 28 Mar 2003 09:46:07 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

> ...and .SG(04) and soon to be .BZ(04 or 07)

congrats edmon!!! i'd thought that .bz was a vgrs property. whether you've
moved on to the high-table at vgrs, or swung a spin-out deal, i'm impressed.

From: "Edmon Chung" <[email-masked]>
To: "Asbjorn Mikkelsen" <[email-masked]>, "Ram Mohan" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: side bar, was Re: [ietf-provreg] Our "Privacy Issue"
Date: Fri, 28 Mar 2003 08:48:17 -0500
Sender: [email-masked]

> On Fri, 2003-03-28 at 03:10, Ram Mohan wrote:
> > Last time I checked, at least half a dozen registries are running EPP
> > operationally.  .INFO (02); .ORG(07), .BIZ(04), .US(04?), .AU(05),
> > .NL(?)plus a bunch more ccTLDs.
> 
> ...and .NAME(05)...
> 
...and .SG(04) and soon to be .BZ(04 or 07)

Edmon

From: "Edmon Chung" <[email-masked]>
To: <[email-masked]>
Subject: [ietf-provreg] privacy profile for domain mapping
Date: Fri, 28 Mar 2003 08:44:51 -0500
Sender: [email-masked]

At the SF meeting we discussed adding privacy profile for contact mapping,
but I think it is important to also add it to domain mapping as well, in
fact, I think being able to handle a per domain profile model is even more
important because the same contact may be the admin contact as well as say
the tech contact and the disclosure requirements may also be different
within the same domain.

Moreover, one contact may be associated with multiple domains, and each
domain may have different preference.  (e.g. a domain registered in EU and a
domain registered in US with the same contact might have to/want to
disclose/hide different info)

Anyway, here are four ways I have thought of to add the privacy elements for
domain mapping:
(p=0: ok to disclose, p=1: privacy preserved)

(1) adding an optional <domain:privacy> block:

...
<domain:privacy>
  <domain:registrant>
    <domain:contactname p="0"/>
    <domain:contactaddr p="1"/>
    <domain:contactvoice p="1"/>
  </domain:registrant>
  <domain:contact>
    <domain:contactid type="admin">sh8013</domain:contactid>
    <domain:contactPoInfo type="int">
      <domain:contactcc p="1"/>
    </domain:contactPoInfo>
  </domain:contact>
  <domain:contact>
    <domain:contactid type="tech">sh8013</domain:contactid>
    <domain:contactemail p="1"/>
    <domain:contactvoice p="1"/>
  </domain:contact>
</domain:privacy>
...

(2) changing <domain:contact> element to include privacy profile for each
contact/registrant

...
<domain:registrant>
  <domain:registrantid>jd1234</domain:registrantid>
  <domain:contactname p="0"/>
  <domain:contactaddr p="1"/>
  <domain:contactvoice p="1"/>
</domain:registrant>
<domain:contact>
  <domain:contactid type="admin">sh8013</domain:contactid>
  <domain:contactPoInfo type="int">
    <domain:contactcc p="1"/>
  </domain:contactPoInfo>
</domain:contact>
<domain:contact>
  <domain:contactid type="tech">sh8013</domain:contactid>
  <domain:contactemail p="1"/>
  <domain:contactvoice p="1"/>
<domain:contact>
...

(3) including everything as attributes in the <domain:contact/registrant>
element

...
<domain:registrant name="0" addr="1" voice="1">jd1234</domain:registrant>
<domain:contact type="admin" poInfoIntcc="1">sh8013</domain:contact>
<domain:contact type="tech" voice="1" email="1">sh8013</domain:contact>
...

(4) combination of 2 & 3 (postalInfo has a further child element while
others are grouped as attributes)

...
<domain:registrant>
  <domain:registrantid>jd1234</domain:registrantid>
  <domain:privacy type="postalInfo" t="int">
    <domain:postalprivacy name="0" addr="1"/>
  </domain:privacy>
  <domain:privacy type="others" voice="1" email="0"/>
</domain:registrant>
<domain:contact>
  <domain:contactid type="admin">sh8013</domain:contactid>
  <domain:privacy type="postalInfo" t="int">
    <domain:postalprivacy cc="1"/>
  </domain:privacy>
</domain:contact>
<domain:contact>
  <domain:contactid type="tech">sh8013</domain:contactid>
  <domain:privacy type="others" voice="1" email="1"/>
<domain:contact>

There could also be a (5)th apporach that is to combine 1 & 4 for a smaller
<domain:privacy> block.
Thoughts?

Edmon

Subject: Re: side bar, was Re: [ietf-provreg] Our "Privacy Issue"
From: Asbjorn Mikkelsen <[email-masked]>
To: Ram Mohan <[email-masked]>
Cc: [email-masked]
Organization: 
Date: 28 Mar 2003 09:23:04 +0000
Sender: [email-masked]

On Fri, 2003-03-28 at 03:10, Ram Mohan wrote:
> Last time I checked, at least half a dozen registries are running EPP
> operationally.  .INFO (02); .ORG(07), .BIZ(04), .US(04?), .AU(05),
> .NL(?)plus a bunch more ccTLDs.

...and .NAME(05)...

Asbjorn

-- 
Asbjorn Steira <[email-masked]>
Senior Developer
The Global Name Registry, Limited
Tel: +44 (0) 207 025 2214

Information contained herein is Global Name Registry Proprietary Information and is made available to you because of your interest in our company.    This information is submitted in confidence and its disclosure to you is not intended to constitute public disclosure or authorization for disclosure to other parties.
*****************
What's your .name?
Get one at www.name
*****************

From: "Ram Mohan" <[email-masked]>
To: "Eric Brunner-Williams in Portland Maine" <[email-masked]>, "Edward Lewis" <[email-masked]>
Cc: "Edward Lewis" <[email-masked]>, "Eric Brunner-Williams in Portland Maine" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: side bar, was Re: [ietf-provreg] Our "Privacy Issue"
Date: Thu, 27 Mar 2003 22:10:17 -0500
Organization: Afilias
Sender: [email-masked]

Ed,
[snip]
> I want to avoid the appearance that EPP is perfect.
> No one is running it operationally yet

Last time I checked, at least half a dozen registries are running EPP
operationally.  .INFO (02); .ORG(07), .BIZ(04), .US(04?), .AU(05),
.NL(?)plus a bunch more ccTLDs.

> But it's also apparent that whatever flaws hiding in
> it are hidden so well not many of us see them.

Not sure the hypothesis is true; exposure of limitations has probably not
happened - i know a few registry folks who have things they don't much care
for in EPP, but haven't talked about it on the list.

-ram

To: Edward Lewis <[email-masked]>
cc: Eric Brunner-Williams in Portland Maine <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: [ietf-provreg] Our "Privacy Issue" 
Date: Wed, 26 Mar 2003 18:13:41 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

> In this case, "makes a decision on whether to send some data in a 
> message."

Which isn't the same thing as "makes a decision on whether to send any
data in a message."

Which is why I asked a Yes/No/Mumble question (partial write semantics),
since between "none" and "all" lies "mumble". Eventually I suppose that
"mumble" will take some greater detail.

At least enough to make "mumble enforcement" sensible.

Somewhere out there is a manditory to implement (but always optional to
deploy) requirement that one end point or the other shave at least one
bit (haircut optional for an additional two bits) off of some object.
Which bit(s) is tbd, but some sort of mask is a given.  

I'd like to go on record as wanting the Mask of Zorro, er, Zero.

> Part of the problem statement was that we wanted to piecemeal the 
> privacy metadata to a finer scope.  Do you think that that is a bad 
> idea?

I'm certain its a ... IESG idea ... to insist on the syntactic form of
metadata, and insist that it be temporally scopeless, and insist that
it is the terminal node in a directed acyclic graph (element attribute).

Randy's an ex-compiler weenie, he knows what he's proposing.

\begin{wicked_serious_mode}

	It depends on what one is attempting to design. If one is
	attempting to provision policy data (aka "metadata") in an
	SRS, and the SRS is not partitioned by metadata, and the
	data is uncorrolated w.r.t. metadata, then the metadata is
	sensibly encoded into the data.

	We did assume that there was correlation when we went for
	the session scoped <dcp>, thinking that changes in <dcp>
	would be infrequent, relative to the policied objects,
	that session encoding of the metadata was sensible, that
	the value-space of the <dcp> was a lot smaller than the
	value-space of the <contact> object, and this design choice
	did not preclude client sourcing of <dcp>, or negociation
	of <dcp>, or .... 

	Where the "finer is better" approach veers away from reality
	is in the assertion that no sensible aggregation of stuff is
	already well-defined in some relevant context. If 95/46/EC is
	a guide for anything that is remotely related to "privacy",
	we can expect to find in it an approval of "finer is better".

	I don't. What I do find is that deconstruction of the data is
	only part of the problem domain. Deconstruction of the purpose,
	recipients, temporal existance, originator write-through (aka
	"access"), and more define the problem domain, and that "fine
	structure" is less important than policing lumps, and relations
	between lumps, that when handled with the intent to construct
	or extract personally identifying information, can.

	I can live with "design" in the IETF social construct, with
	PS/DS/SS having a different frame of reference from "design"
	in the W2C social construct.

	I tried to "cross over" a gramatical framework, from the W3C
	to the IETF. It wasn't a success. No matter.

	I'm spending more time trying to prevent there being two or
	more core syntaxes than I will spend implementing those few
	I care about, so I'm way past my ROI, or my sell-by date.

\end{wicked_serious_mode}

> ... We have to gain operational experience ...

With a mechanism with no discernable effect. OK.

> I have heard rumors that in some business dealings swirling around 
> the work done here, there is a need for a "standard."  To some that's 
> an RFC, to others PR, to others DS, and so yet some others Full 
> Standard or even STD-n.  As a chair, I can't deal with what others 
> call a "standard" all I can deal with is what's in the process 
> documents.

I'm happy with Dork-i-mental, and operational experience. I have very
low tastes. Maybe none at all.

Cheers,
Eric

To: Edward Lewis <[email-masked]>
cc: Eric Brunner-Williams in Portland Maine <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: side bar, was Re: [ietf-provreg] Our "Privacy Issue" 
Date: Wed, 26 Mar 2003 16:22:17 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

Dear Co-Chair of the PROVREG WG (and all around nice guy Ed Lewis),

I have no angst.

I am quite content that no working group, in particular, the PROVREG WG,
has any interest in some drafts published as individual contributions.

Just to be degenerate, which comes easily to me, and get to some core issues
of ordering, reliability, and who is the author of requirements...

EBW sez <check bar> <check bar> <check bar> contains no fewer than zero,
and possibly as many as one, maybe even three, instances of the operation
"check" on the operand "bar", which might be ordered, and the temporal
bounds on delivery are ... "best effort", or weaker.

PAF sez <check bar> <check bar> <check bar> contains exactly three, ordered
instances of the operation "check" on the operand "bar", and the temporal
bounds on delivery are ... "web time", an odd bit of transactional real-time. 

EBW sez for some things, it matters, for some things, it don't.

PAF sez for all things, it matters equally.

That disposes of epp/smtp, epp/udp, epp/http, epp/uucp, and of course
epp/avian-transport (only a few days until that one, neh?).

This is all done, my concern with the present question fits fairly neatly
into two questions. I can wait till they're answered, or ... expire.

Eric

Date: Wed, 26 Mar 2003 14:26:30 -0500
To: Eric Brunner-Williams in Portland Maine <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: Re: [ietf-provreg] Our "Privacy Issue"
Cc: Edward Lewis <[email-masked]>, Eric Brunner-Williams in Portland Maine <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

At 17:11 -0500 3/25/03, Eric Brunner-Williams in Portland Maine wrote:
>>                                                       Apparently you
>>  are not happy with requiring the protocol let the client include
>>  privacy meta-data to achieve the goal of allowing enforcement to
>>  happen at the server.
>
>Actually, I don't even know what "enforcement" means.
>
>How is "enforcement" meaningfully defined in the protocol?

In this case, "makes a decision on whether to send some data in a 
message."  We see the need to make decisions at either the registry 
or registrar.

>>                                                       Apparently you
>>  are not happy with requiring the protocol let the client include
>>  privacy meta-data
>
>But it isn't that simple, is it? If it were, then just sourcing the <dcp>
>from the client, and sinking it at the server, would suffice. But that
>isn't it.

Part of the problem statement was that we wanted to piecemeal the 
privacy metadata to a finer scope.  Do you think that that is a bad 
idea?

>No that is interesting. A functional requirement with no semantics.
>A mechanism with no discernable effect. Now that is worth the price of
>admission.

Yes, that is part of the role of being a proposed standard.  We have 
to gain operational experience that may find that parts of the 
protocol are useless or a needed to be expanded - as well as the 
circumstances of the documents.

I have heard rumors that in some business dealings swirling around 
the work done here, there is a need for a "standard."  To some that's 
an RFC, to others PR, to others DS, and so yet some others Full 
Standard or even STD-n.  As a chair, I can't deal with what others 
call a "standard" all I can deal with is what's in the process 
documents.

>
>>  >Is the new semantic capable of test by any in-protocol means?
>>
>>  Well, we want to be able to set, check, change and define the meaning
>>  of absence.
>
>Sounds like an abstract, post-creat, access provisioning protocol, for
>shared, multi-reader repositories.
>
>Not the same as getting the data past creat, or mod, or ...

Fortunately, this time I got lost at the end of the message.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

I've had it with world domination.  The maintenance fees are too high.

Date: Wed, 26 Mar 2003 14:18:27 -0500
To: Eric Brunner-Williams in Portland Maine <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: side bar, was Re: [ietf-provreg] Our "Privacy Issue"
Cc: Edward Lewis <[email-masked]>, Eric Brunner-Williams in Portland Maine <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

Answering the side-bar message first:

At 16:32 -0500 3/25/03, Eric Brunner-Williams in Portland Maine wrote:
>Ed,
>
>Let's get this bit out of the way.

Speaking as a chair, Eric, I have to admit I am having trouble 
comprehending your angst here.  Honestly, every time I begin to try 
to reply to some point you are raising, I get lost in thought and 
realize I've no answer.

I don't want to discount a lone voice in the wilderness (as no one 
else is speaking out in the same way), but its that whatever is 
clueing you into your view is not apparent to me.  Hence, I'm 
powerless to help.

I want to avoid the appearance that EPP is perfect.  (No one is 
running it operationally yet, so even if EPP is the most righteous 
protocol ever designed by mankind, there's no empirical evidence that 
it is perfect.)  But it's also apparent that whatever flaws hiding in 
it are hidden so well not many of us see them.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

I've had it with world domination.  The maintenance fees are too high.

To: Edward Lewis <[email-masked]>
cc: Eric Brunner-Williams in Portland Maine <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: [ietf-provreg] Our "Privacy Issue" 
Date: Tue, 25 Mar 2003 17:38:31 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

Ed,

I'm going to shut up and wait until Scott next delta's of the draft set.

If there is no answer more ... whatever than what's been offered to
my questions to Randy, well, that's life.

Eric

To: Edward Lewis <[email-masked]>
cc: Eric Brunner-Williams in Portland Maine <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: [ietf-provreg] Our "Privacy Issue" 
Date: Tue, 25 Mar 2003 17:11:27 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

>                                                      Apparently you 
> are not happy with requiring the protocol let the client include 
> privacy meta-data to achieve the goal of allowing enforcement to 
> happen at the server.

Actually, I don't even know what "enforcement" means.

How is "enforcement" meaningfully defined in the protocol?

If EPP allowed unconditional write-access to a centralized store, with
only an auth-thingie to partition the store into N-registrar buckets,
and allowed each writer to write the read-access (general, a la :43,
or to any other registrar writer, or the blind registry store manager),
then I'd have a clue what "enforcement" might mean.

The registrar would hand a bitmask the size of a contact object to the
registry, and could attempt to modify it without the auth-thingie, or
read it back without the auth-thingie. Partial sight proved.

>                                                      Apparently you
> are not happy with requiring the protocol let the client include
> privacy meta-data

If only it were that simple. 

All I'm looking for is a way to distinguish one policied endpoint from
another. What I'm not looking for is a way to change the policy on one
policied endpoint, until it is indistinguishable from another.

>                                                      Apparently you
> are not happy with requiring the protocol let the client include
> privacy meta-data

But it isn't that simple, is it? If it were, then just sourcing the <dcp>
from the client, and sinking it at the server, would suffice. But that
isn't it.

Hey, we could go back to BNF, or whatever the people use who write the
UI stuff for insurance companies, and add a little check box. For some
reason, the extra bit(s) have to be just so.

> >Are there any success or failure semantics? Is the transaction atomic and
> >unitary, or is a partial write success?
> 
> It's all policy as far as we can tell.

No that is interesting. A functional requirement with no semantics.
A mechanism with no discernable effect. Now that is worth the price of
admission.

> >Is the new semantic capable of test by any in-protocol means?
> 
> Well, we want to be able to set, check, change and define the meaning 
> of absence.

Sounds like an abstract, post-creat, access provisioning protocol, for
shared, multi-reader repositories. 

Not the same as getting the data past creat, or mod, or ...

Eric

To: Edward Lewis <[email-masked]>
cc: Eric Brunner-Williams in Portland Maine <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: [ietf-provreg] Our "Privacy Issue" 
Date: Tue, 25 Mar 2003 16:32:39 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

Ed,

Let's get this bit out of the way.

> >I wasn't thrilled with the congestion issue either, or the ordering issue,
> >but those are damp spots under prior bridges.
> 
> I suppose you are referring in some way to the statement that we 
> aren't pursuing SMTP or other transports over TCP (or other 
> transports at all).

No. It isn't about what documents the WG pursues. Its about the way
that session semantics crept in, and in a more exclusive form than
any contributor to the WG reqested, either during the reqs period,
or during the incremental deltas from -02 to -06.

I wrote about this at length.

Why does a stream of <check coat> <check bar> <check hat> <check bar>
<check scotch> <check ice> <check bar> <check scotch> <check scotch>
<check scotch> <check scotch> <check floor> have to be strictly ordered?

I don't know. It is worth a drink.

Now this may not be what everyone, or even anyone, wants to do, but to
discover in the ratrace of speculative gTLD operational art, some new
_universal_ requirement that ordering must be preserved, even for some
EPP-for-penguins deployment, is odd.

Then there's the got-to-have-it-now problem, or why order preserving
semantics aren't strong enough, they must be connectionist too. Bye
bye email.

Under the guiding light of the IESG we've gone from a protocol to a
rather narrower operational market in the guise of a protocol.

Believe me, I'm much happier with my drafts poking along dorkily to
dorkimental. But these are edge cases. Transport thingies. Brunner's
bad ideas.

The issue before the WG today is the common syntax. Existance, or not.
With that I'll go back to your note.

Eric

Date: Tue, 25 Mar 2003 13:54:38 -0500
To: Eric Brunner-Williams in Portland Maine <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: Re: [ietf-provreg] Our "Privacy Issue"
Cc: Edward Lewis <[email-masked]>, Eric Brunner-Williams in Portland Maine <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

At 13:21 -0500 3/25/03, Eric Brunner-Williams in Portland Maine wrote:
>False. It is a requirement not in 3375. It is a new requirement, one that
>modifies some functionality.

Yup.  The issue isn't whether something is new or not.  The issue is 
whether it is a good idea.  Recall that in the IETF process, an RFC 
is just that, a request for comments.  I've stated in the past that 
there is never a deadline for getting it right - so long as we get it 
timely.

We can "debate" forever on the merits of late requirements and 
concerns late in the game - but if you care about that, 
problem-statement seems to be the place.  Let's focus on this problem 
statement and not worry about whether or not the process is a problem.

>OK, so neither of us writing or grading english compositions. EPP "works"
>as is (-02, -04, -06, ... for some value of "works"), and some new thing
>is desired by someone in -0N, for some value of N. Fair enough.

Basically, yeah.

>We don't know it is a good idea, we do know that it is the IESG's idea. So,

Okay, let's get over this.  Forget who suggested it.  Apparently you 
are not happy with requiring the protocol let the client include 
privacy meta-data to achieve the goal of allowing enforcement to 
happen at the server.

Others have thought this is a good idea, mostly in the room and Scott 
so far as agreed that the statements in the room amounted to what I 
wrote.

>when we say that Scott is the editor of documents under the change control
>of the IETF, what we are really saying is that the actual change control is
>held, not by the contributors, acting in concert, under 2026, et alia, to
>create some specification, but by institutional authority figures other than
>the I-D administrator, who may add/delete/modify the text, without undertaking
>the corresponding action on the requirements doc, which has already had WGLC,
>and IETF-LC.

Once again - worry about this in problem-statement.  I ain't about to 
debate the role of the document editor here - the topic is EPP, not 
the IETF.  Scott is recording the consensus of the WG, along with 
much of the material he originally brought to the WG in 2000.  (See 
the charter, it hasn't changed.)

>If someone wants to modify 3375 and delete the manditory announcement clause,
>let them. It is possibly deficient.
>
>If someone wants to modify 3375 and add a manditory enforcement clause, let
>them. It is possibly sufficient.

I don't think that there's much support for writing 3375bis at this 
time.  Perhaps when a WG comes along to advance to Draft Standard it 
would be good to have a document that rolls in operationally derived 
experience, but it's way too premature to consider this now.

>I'm "unhappy" about what I see as the technical difficulty of the proposal,
>the inability of the authors of the proposal to make a technical case for a
>mechanism that doesn't rely upon an appeal to authorty, or exhaustion, and
>the process to effect change control of the provreg work product.

With the high bandwith of voice-over-soundwave (a cutsy name for 
face-to-face meetings) I think we were able to get deeper into the 
issue.

>I wasn't thrilled with the congestion issue either, or the ordering issue,
>but those are damp spots under prior bridges.

I suppose you are referring in some way to the statement that we 
aren't pursuing SMTP or other transports over TCP (or other 
transports at all).

One reason we are not pursuing them is that 1) no one has maintained 
a document on this for a prolonged period of time and 2) no second 
person has cared enough to present an interoperability-motivated 
reason for this to be brought into the group.

I know you have had documents that discussed SMTP.  My reading of 
them was that they were never fully developed enough to trigger me 
into personal action.

As a WG chair, admittance of documents is based in part on a reason 
to use the WG's resources - i.e., the members.  Without voluntary 
member motivation to review the documents, there's not a sufficient 
reason for the WG to expand its horizons.

I.e., although our charter says we will investigate alternate 
transports - it doesn't mean we will develop an alternate transport. 
So far the result of the investigation is that there's been no 
popular support for other transports.

>>  >Question #1: If the client originated a <c-dcp> as part of session
>>  >init, and the server responded with a <s-dcp>, and the evalution
>>  >algorithm (tbd) was simple, e.g., equality, would that meet their
>>  >requirement?
>>
>>  Initially, this might be, but as an outcome of the discussion in the
>>  meeting we felt that finer granularity was desirable and achievable.
>>  We talked about this as being a session-granular thing, but that was
>>  discarded.
>
>I thought so, which is why I asked.
>
>Even if sizeof(server(dcp-space) > BIGNUM, and function(client(dcp-select)
>is unrestricted, _this_isn't_what_the_iesg_wants_.

You've lost me again here.

>On the bright side, this means that all two-step discovery kludges of the
>form Edmon proposed are as KIA as the <dcp>.
>
>On the dim side, this seems to mean that the issue is syntax or religion,
>as there's a heck of a lot of values less than BIGNUM (or a full DOM tree),
>and a baroque richesse of choices when one is unrestricted. So semantics is
>possibly _not_ the issue.
>
>>
>>  >In eppcom-1.0.xsd we have this:
>>
>>  You're getting into an implementation detail.  At this point, we are
>>  hashing out the problem statement.
>
>I could be wrong, but the authors of the document offering guidance on the
>use of xml in IETF protocols may have failed to mention an edge case.
>
>If a type is inextensible, and is used to type a datum that cannot be
>semantically conditioned by any means other than extension, for reasons
>that are non-sytactic in nature, an "owie" occurs. I'm sure there is a
>better form of expressing this than "owie".

There may be a better form of saying "owie" but the cost-benefit of 
finding this seems to be discouraging to the group.  (I.e., we've 
been running around just trying to figure out how to spell pirvayc at 
that point.)

>The point of the implementation detail is that I think (I'd prefer to be
>wrong) that we need to put a layer between the syntax of EPP extensions
>to XML, and the basic types of XML, so that "policy" can be hidden in the
>syntax, which I don't see a way to do with the "mail" element's "token"
>type.
>
>Eventually all this garbage, mine and anyone else's, gets tossed into a
>validating parser. What comes out may come as a surprise to me.

Valid concern, but as I said before - implementation detail.

>Are there any success or failure semantics? Is the transaction atomic and
>unitary, or is a partial write success?

It's all policy as far as we can tell.

>Is the new semantic capable of test by any in-protocol means?

Well, we want to be able to set, check, change and define the meaning 
of absence.

>How large is the policy value space?
>
>Taking the phone number example above, the value space appears to encode
>neatly into a single bit.
>
>
>If so, while I'm typing this I've found one solution to the "email" element
>qustion I thought was awkward. Suff one extra bit, like NeuStar's proposal
>to pun the size type and signal directionality, into an octet. Violate some
>rule about octets in mail addrs, e.g., set a high bit in the domain name.
>If high-bit on, semantic one flag set and unset bit before store.
>If high-bit off, semantic one flag not set.
>
>mail="[email-masked](eval((0x164+0x177)"
>
>Wierd. I guess the same could be done to the e164 type too.
>
>Of course, if the value space doesn't encode neatly into one bit, then
>this won't work, unless applied iteratively.
>
>Eric

Details, implementation details...

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

I've had it with world domination.  The maintenance fees are too high.

To: Edward Lewis <[email-masked]>
cc: Eric Brunner-Williams in Portland Maine <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: [ietf-provreg] Our "Privacy Issue" 
Date: Tue, 25 Mar 2003 13:21:40 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

Hi Ed,

Long and interlinear. 

> At 18:33 -0500 3/24/03, Eric Brunner-Williams in Portland Maine wrote:
> >It had one error. The assertion that to function (at all) some delta
> >is required. The correct statement is to function (as required post
> >rfc3375) some delta is required.
> 
> Eric, help me here.  What is your point?

You wrote:

        What is desired is a mechanism that will let EPP support thick
        registries, in which social data is held by the registry.

No new mechanism is required by this sentence.
                                                                  In such
        situations, the registrar needs to inform the registry of
        restrictions on the redistribution of the data submitted to the
        registry.

False. It is a requirement not in 3375. It is a new requirement, one that
modifies some functionality.

OK, so neither of us writing or grading english compositions. EPP "works"
as is (-02, -04, -06, ... for some value of "works"), and some new thing
is desired by someone in -0N, for some value of N. Fair enough.

> >Requirement by assertion is more popular than I recall.
> 
> I'm still not getting your point.  I'm not sure if you are unhappy 
> that someone wants to add client-sent statements on privacy or that 
> the someone is the IESG.  I'm not sure I see a reason from you 
> explaining why adding this is a bad idea.

Any requirement not in the req doc is either a) previously rejected, or
b) a failure of the process that created the req doc, or c) neither a)
nor b). Suppose c.

We don't know it is a good idea, we do know that it is the IESG's idea. So,
when we say that Scott is the editor of documents under the change control
of the IETF, what we are really saying is that the actual change control is
held, not by the contributors, acting in concert, under 2026, et alia, to
create some specification, but by institutional authority figures other than
the I-D administrator, who may add/delete/modify the text, without undertaking
the corresponding action on the requirements doc, which has already had WGLC,
and IETF-LC.

If someone wants to modify 3375 and delete the manditory announcement clause,
let them. It is possibly deficient.

If someone wants to modify 3375 and add a manditory enforcement clause, let
them. It is possibly sufficient.

I'm "unhappy" about what I see as the technical difficulty of the proposal,
the inability of the authors of the proposal to make a technical case for a
mechanism that doesn't rely upon an appeal to authorty, or exhaustion, and
the process to effect change control of the provreg work product.

I wasn't thrilled with the congestion issue either, or the ordering issue,
but those are damp spots under prior bridges.

> >Question #1: If the client originated a <c-dcp> as part of session
> >init, and the server responded with a <s-dcp>, and the evalution
> >algorithm (tbd) was simple, e.g., equality, would that meet their
> >requirement?
>
> Initially, this might be, but as an outcome of the discussion in the 
> meeting we felt that finer granularity was desirable and achievable. 
> We talked about this as being a session-granular thing, but that was 
> discarded.

I thought so, which is why I asked.

Even if sizeof(server(dcp-space) > BIGNUM, and function(client(dcp-select)
is unrestricted, _this_isn't_what_the_iesg_wants_.

On the bright side, this means that all two-step discovery kludges of the
form Edmon proposed are as KIA as the <dcp>.

On the dim side, this seems to mean that the issue is syntax or religion,
as there's a heck of a lot of values less than BIGNUM (or a full DOM tree),
and a baroque richesse of choices when one is unrestricted. So semantics is
possibly _not_ the issue.

> 
> >In eppcom-1.0.xsd we have this:
> 
> You're getting into an implementation detail.  At this point, we are 
> hashing out the problem statement.

I could be wrong, but the authors of the document offering guidance on the
use of xml in IETF protocols may have failed to mention an edge case.

If a type is inextensible, and is used to type a datum that cannot be
semantically conditioned by any means other than extension, for reasons
that are non-sytactic in nature, an "owie" occurs. I'm sure there is a
better form of expressing this than "owie".

The point of the implementation detail is that I think (I'd prefer to be
wrong) that we need to put a layer between the syntax of EPP extensions
to XML, and the basic types of XML, so that "policy" can be hidden in the
syntax, which I don't see a way to do with the "mail" element's "token"
type.

Eventually all this garbage, mine and anyone else's, gets tossed into a
validating parser. What comes out may come as a surprise to me.

> >>  The IESG is doing this through the role of protocol design engineer
> >>  review - recognizing functionality that oughta be in a protocol but
> >>  isn't.
> >
> >3375 is the requirements statement.
> 
> Yeah, it is.  Obviously, you mean something by saying that, but it is 
> not clear.

See above. *-LC are not meaningless, and should not be "worked around".

> >>  But the only option available to users of the client is to decide
> >>  whether or not to make the registration.  We want more of an option
> >>  than that.
> >
> >Please explain.
> 
> We want the registrar to be able to say, here's the phone number but 
> don't send it anywhere.  What is meant by 'anywhere' is policy 
> specific, hence outside the WG's concern.

Are there any success or failure semantics? Is the transaction atomic and
unitary, or is a partial write success?

Is the new semantic capable of test by any in-protocol means?

> >It is my sense that "privacy" is not simple.
> 
> Then it's not privacy we are concerned about.  It's about tagging 
> data with something called 'privacy.'

How large is the policy value space?

Taking the phone number example above, the value space appears to encode
neatly into a single bit.

If so, while I'm typing this I've found one solution to the "email" element
qustion I thought was awkward. Suff one extra bit, like NeuStar's proposal
to pun the size type and signal directionality, into an octet. Violate some
rule about octets in mail addrs, e.g., set a high bit in the domain name.
If high-bit on, semantic one flag set and unset bit before store.
If high-bit off, semantic one flag not set.

mail="[email-masked](eval((0x164+0x177)"

Wierd. I guess the same could be done to the e164 type too.

Of course, if the value space doesn't encode neatly into one bit, then
this won't work, unless applied iteratively.

Eric

Date: Tue, 25 Mar 2003 09:51:16 -0500
To: Eric Brunner-Williams in Portland Maine <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: Re: [ietf-provreg] Our "Privacy Issue"
Cc: Edward Lewis <[email-masked]>, Eric Brunner-Williams in Portland Maine <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

At 18:33 -0500 3/24/03, Eric Brunner-Williams in Portland Maine wrote:
>It had one error. The assertion that to function (at all) some delta
>is required. The correct statement is to function (as required post
>rfc3375) some delta is required.

Eric, help me here.  What is your point?

>Requirement by assertion is more popular than I recall.

I'm still not getting your point.  I'm not sure if you are unhappy 
that someone wants to add client-sent statements on privacy or that 
the someone is the IESG.  I'm not sure I see a reason from you 
explaining why adding this is a bad idea.

>Question #1: If the client originated a <c-dcp> as part of session
>init, and the server responded with a <s-dcp>, and the evalution
>algorithm (tbd) was simple, e.g., equality, would that meet their
>requirement?

Initially, this might be, but as an outcome of the discussion in the 
meeting we felt that finer granularity was desirable and achievable. 
We talked about this as being a session-granular thing, but that was 
discarded.

>In eppcom-1.0.xsd we have this:

You're getting into an implementation detail.  At this point, we are 
hashing out the problem statement.

>>  The IESG is doing this through the role of protocol design engineer
>>  review - recognizing functionality that oughta be in a protocol but
>>  isn't.
>
>3375 is the requirements statement.

Yeah, it is.  Obviously, you mean something by saying that, but it is 
not clear.

>>  But the only option available to users of the client is to decide
>>  whether or not to make the registration.  We want more of an option
>>  than that.
>
>Please explain.

We want the registrar to be able to say, here's the phone number but 
don't send it anywhere.  What is meant by 'anywhere' is policy 
specific, hence outside the WG's concern.

>It is my sense that "privacy" is not simple.

Then it's not privacy we are concerned about.  It's about tagging 
data with something called 'privacy.'

Recall that this effort is to build an interoperable, general purpose 
protocol.  If there is something you think is useless and harmless, 
then don't use it and don't complain.  (Harmless = doesn't cause a 
lot of things, including [useless] bloat.)

You may decide that what is here is not enough, then use an 
extension.  You may decide what is here does not apply to you, but if 
it applies to someone else, see if you can live with it.  The process 
is about finding "common denominators" and not tailored, optimized, 
solutions.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

I've had it with world domination.  The maintenance fees are too high.

To: Edward Lewis <[email-masked]>
cc: Eric Brunner-Williams in Portland Maine <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: [ietf-provreg] Our "Privacy Issue" 
Date: Mon, 24 Mar 2003 18:33:16 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

> >I'm not convinced that the issue of contention is technical.
> 
> Then I've failed in my description of the problem.

It had one error. The assertion that to function (at all) some delta
is required. The correct statement is to function (as required post
rfc3375) some delta is required.

Requirement by assertion is more popular than I recall.

> As we sit, EPP requires the registrar to make decisions on whether 
> the submission of a piece of data will be accorded the proper 
> handling with regards to privacy.  The issue is that EPP forces the 
> registrar into this posture, there is no choice.

There are a lot of restrictions. RRP doesn't have this one (it has
others). SRS doesn't have this one (it too has others). Etcetera.

Its a nuance that may be lost on some, but the evaluation possible
by the registrar isn't necessarily prospective (forward looking),
it can be of the announced policy at the moment of transactional
evaluation, with some explicit temporal guarantees. Mind, all of
the evaluation is either optional (epp-07), manditory (epp-08), or
irrelevant (iesg-any).

> What the IESG has asked of us is to make EPP possible to support a 
> scenario in which a registrar gives the data and policy request to 
> the registry and then let the registry decide what to do. 

Question #1: If the client originated a <c-dcp> as part of session
init, and the server responded with a <s-dcp>, and the evalution
algorithm (tbd) was simple, e.g., equality, would that meet their
requirement?

> Furthermore, a basic framework for this is desired to be part of the 
> base protocol.

As the formal specification of this protocol is in XML, this is more
than it appears.

In eppcom-1.0.xsd we have this:

<!--
Non-empty token type.
-->
  <simpleType name="minTokenType">
    <restriction base="token">
      <minLength value="1"/>
    </restriction>
  </simpleType>

We use it to define type ofthe element "email". Now how does a "data
structures 101" compatible tag fit into that? 

> The IESG is doing this through the role of protocol design engineer 
> review - recognizing functionality that oughta be in a protocol but 
> isn't.

3375 is the requirements statement.

> >The registry announces a session-policy. Implementors are free
> >to evaluate the registry-announced policy, and implement local policy,
> >e.g., accept the policy and propogate policied data, or decline.
> 
> But the only option available to users of the client is to decide 
> whether or not to make the registration.  We want more of an option 
> than that.

Please explain.

> >To me, it _was_ just distributed read and write access mechanisms to
> >shared store, with a specific syntax. If someone claims read-on-43
> >exhaustively defines "privacy", I don't care. It doesn't exhaustively
> >define _read_.
> 
> I don't think anyone is trying to link privacy to what's on port 43 
> (whois to most of us).  The goal isn't to tie privacy to any 
> publication mechanism.  This is done with the intent that during the 
> phase of reaching towards DS, we will have more tools for dealing 
> with privacy.  Features are more easily removed from PS to DS than 
> added.

This is where the non-technical bit lives. Let's go back:

> >I'm not convinced that the issue of contention is technical.

Just how complex is "privacy"? Is it a property that a tag is a useful
mechanism to encode it?

If "privacy" is simple, something that fits in a tag, then we have one
technical issue.

If "privacy" is not simple, then we have another technical issue.

It is my sense that "privacy" is not simple.

> >Enforcement is a whole different can of worms, unless this is just a
> >techno-fiction.
> 
> Enforcement is part of policy and we are making every effort to sidestep it.

To avoid non-sensicalness however, an enforcable mechanism needs to be
capable of violation detection. No spitting when I'm not looking is not
impressive.

> >Nope. Seems technically flawed to me, and worse than what we had.
> 
> I don't see how.

Cheers,
Eric

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Edward Lewis'" <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: RE: [ietf-provreg] Our "Privacy Issue"
Date: Mon, 24 Mar 2003 18:07:43 -0500
Sender: [email-masked]

> During the meeting, it was suggested that a mechanism to meet the 
> requirement has already been sent to the mailing list and discussed. 
> The next steps for the WG is to 1) consider and discuss the 
> requirement in this message.  If the WG accepts this as the problem 
> statement as discussion in the room did, the next step will be to 
> open a thread on the modified proposal suggested.  For procedural 
> reasons, I'm not going to mention that proposal until the problem 
> statement is accepted by the WG (i.e., the mailing list).

I accept the problem statement as described.  It reflects what I heard in
the room last Thursday.

-Scott-

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Joe Abley'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: [ietf-provreg] References for Today's Host Object Discussion
Date: Mon, 24 Mar 2003 18:01:16 -0500
Sender: [email-masked]

> I wonder whether it might be reasonable to accommodate the 
> non-host-object case in the current spec before it is shipped for 
> proposed standard. This doesn't seem like it would be a major 
> change to 
> the text, and the impact on existing implementations seems 
> small (zero, 
> maybe) considering that the spec would not change for 
> registries which 
> choose to include host objects.

I'm not one of the people responsible for determining consensus, but I can
say that the domain document has completed both WG and IETF last calls with
the currently specified feature set.  Our chairs can, of course, direct me
to change something if WG consensus is to make a change.  I'd prefer to keep
things as-is, though, because this is _not_ a new argument and we'll have a
chance to address this again when considering what to do when going from
proposed to draft.

One of the things I intend to do once we're there is capture the outstanding
issues in an I-D that can be used to seed the proposed-to-draft discussion.
It would be helpful if people who have issues with any current features
could send me a note (off-list is OK) describing what they don't like _and_
a suggested solution.  We might then have the start of a pretty good problem
statement for EPP 1.1 or 2.0.

-Scott-

Date: Mon, 24 Mar 2003 16:21:09 -0500
To: Eric Brunner-Williams in Portland Maine <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: Re: [ietf-provreg] Our "Privacy Issue"
Cc: Edward Lewis <[email-masked]>, [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

At 11:44 -0500 3/24/03, Eric Brunner-Williams in Portland Maine wrote:
>I'm not convinced that the issue of contention is technical.

Then I've failed in my description of the problem.

As we sit, EPP requires the registrar to make decisions on whether 
the submission of a piece of data will be accorded the proper 
handling with regards to privacy.  The issue is that EPP forces the 
registrar into this posture, there is no choice.

What the IESG has asked of us is to make EPP possible to support a 
scenario in which a registrar gives the data and policy request to 
the registry and then let the registry decide what to do. 
Furthermore, a basic framework for this is desired to be part of the 
base protocol.

The IESG is doing this through the role of protocol design engineer 
review - recognizing functionality that oughta be in a protocol but 
isn't.

>The registry announces a session-policy. Implementors are free
>to evaluate the registry-announced policy, and implement local policy,
>e.g., accept the policy and propogate policied data, or decline.

But the only option available to users of the client is to decide 
whether or not to make the registration.  We want more of an option 
than that.

>To me, it _was_ just distributed read and write access mechanisms to
>shared store, with a specific syntax. If someone claims read-on-43
>exhaustively defines "privacy", I don't care. It doesn't exhaustively
>define _read_.

I don't think anyone is trying to link privacy to what's on port 43 
(whois to most of us).  The goal isn't to tie privacy to any 
publication mechanism.  This is done with the intent that during the 
phase of reaching towards DS, we will have more tools for dealing 
with privacy.  Features are more easily removed from PS to DS than 
added.

>Enforcement is a whole different can of worms, unless this is just a
>techno-fiction.

Enforcement is part of policy and we are making every effort to sidestep it.

>Nope. Seems technically flawed to me, and worse than what we had.

I don't see how.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

I've had it with world domination.  The maintenance fees are too high.

To: Edward Lewis <[email-masked]>
cc: [email-masked], [email-masked], [email-masked]
Subject: Re: [ietf-provreg] Our "Privacy Issue" 
Date: Mon, 24 Mar 2003 11:44:47 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

...
> The protocol must provide a mechanism to allow enforcement

OK. We blew it semantically in the grrq when we stated the req as a
mechanism to announce.

>                                                            of privacy
> policy at either the registrar or registrant.

OK. We blew it semantically in the grrq when we limited the protocol to
registrars and registries.

>                                                This must be done in a
> protocol feature that is "mandatory to implement, optional to use."

No comment.

> Further, the privacy meta-data must be to individual elements of
> social data.

OK. We blew it syntactically by reference to an inextensible type.

> ...  this is what we need to solve ...

I disagree with the claim that any IETF WG needs to be responsive to the
IESG. The claim only begins to approximate "true" iff the WG wants IESG
approval of its work-product.

I'm not convinced that the issue of contention is technical.

> As EPP stands now, privacy policy decisions are only possible at the 
> registrar.  This is because the dcp element allows the registry to 
> tell the registrar the "rules."  Whatever the registrar sends to the 
> registry is considered to be in accordance with the rules.

Correct. The registry announces a session-policy. Implementors are free
to evaluate the registry-announced policy, and implement local policy,
e.g., accept the policy and propogate policied data, or decline.

> What is desired is a mechanism that will let EPP support thick 
> registries, in which social data is held by the registry.

Umm, this _is_ the current model, neh?

>                                                            In such 
> situations, the registrar needs to inform the registry of 
> restrictions on the redistribution of the data submitted to the 
> registry.

This does not follow. Where state is persistent is a different issue
from how may access to that persistent state be implemented.

Just to test the correctness of this reasoning however, if there did
exist a mechanism for a client to select from a menu of policies in
a <dcp> (this begins to look like beep and the srv record), and the
menu offered by a registry was _in_theory_exhaustive_, would the
registrar need to do anything more exciting than pick a policy out of
the extended hat?

> There's one protocol standards consideration I'd like to make.  The 
> more detail and depth in the solution of a problem often leads to a 
> tougher job in reaching consensus.  I.e., as a chair, I appreciate 
> efforts to refine and divine the depths of privacy, but such threads 
> are in danger of becoming distractions to the main job of this WG.

I'll be _happy_ to leave the problem to more capable hands than my own.

To me, it _was_ just distributed read and write access mechanisms to
shared store, with a specific syntax. If someone claims read-on-43
exhaustively defines "privacy", I don't care. It doesn't exhaustively
define _read_.

Enforcement is a whole different can of worms, unless this is just a
techno-fiction.

> For procedural 
> reasons, I'm not going to mention that proposal until the problem 
> statement is accepted by the WG (i.e., the mailing list).

Nope. Seems technically flawed to me, and worse than what we had.

YMMV.

Eric

Date: Sun, 23 Mar 2003 15:23:13 -0500
To: [email-masked]
From: Edward Lewis <[email-masked]>
Subject: [ietf-provreg] Our "Privacy Issue"
Cc: [email-masked], [email-masked]
Sender: [email-masked]

During the face to face meeting in SF, we had a productive discussion 
of the privacy issue that has been holding up progress.  Minutes, 
et.al. of the meeting will be forthcoming, but the first action item 
to arise from the meeting is a presentation to the WG (list) a 
detailed description of the problem.

In a discussion that involved Ted Hardie, our new Area Advisor, and 
Randy Bush, the following comment was cast into the following 
requirement:

The protocol must provide a mechanism to allow enforcement of privacy 
policy at either the registrar or registrant.  This must be done in a 
protocol feature that is "mandatory to implement, optional to use." 
Further, the privacy meta-data must be to individual elements of 
social data.

     First, before going further, what is stated above is the suggestion
     derived during the face-to-face meeting.  Being that this is a
     clarification of the IESG comment obtained with representatives
     present, this is what we need to solve. However, wording changes
     may be made.

As EPP stands now, privacy policy decisions are only possible at the 
registrar.  This is because the dcp element allows the registry to 
tell the registrar the "rules."  Whatever the registrar sends to the 
registry is considered to be in accordance with the rules.

What is desired is a mechanism that will let EPP support thick 
registries, in which social data is held by the registry.  In such 
situations, the registrar needs to inform the registry of 
restrictions on the redistribution of the data submitted to the 
registry.

There are limits to what the WG is being asked to do.  We are not 
being asked to provide a very rich syntax for the mechanism.  For 
example, we are not being asked to provide a means to say "you can 
publish the phone number in whois but not in any other way."  (We 
could, if we desired, but we are not asked to do.)

There's one protocol standards consideration I'd like to make.  The 
more detail and depth in the solution of a problem often leads to a 
tougher job in reaching consensus.  I.e., as a chair, I appreciate 
efforts to refine and divine the depths of privacy, but such threads 
are in danger of becoming distractions to the main job of this WG.

During the meeting, it was suggested that a mechanism to meet the 
requirement has already been sent to the mailing list and discussed. 
The next steps for the WG is to 1) consider and discuss the 
requirement in this message.  If the WG accepts this as the problem 
statement as discussion in the room did, the next step will be to 
open a thread on the modified proposal suggested.  For procedural 
reasons, I'm not going to mention that proposal until the problem 
statement is accepted by the WG (i.e., the mailing list).

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

I've had it with world domination.  The maintenance fees are too high.

From: "Hollenbeck, Scott" <[email-masked]>
To: [email-masked]
Subject: RE: [ietf-provreg] I-D ACTION:draft-ietf-provreg-epp-09.txt
Date: Mon, 24 Mar 2003 08:53:18 -0500
Sender: [email-masked]

Aww, phooey.  This is the document that was edited based on our most recent
miscommunication with the IESG; the response I received from the I-D
administrator said it would NOT be retained when I sent it after the
submission deadline had passed.  As discussed during IETF-56, I didn't send
it in again.

It's going to have to be edited again once we get the privacy topics
discussed during the IETF meeting out on the list for open discussion (hint,
hint).

-Scott-

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, March 24, 2003 7:26 AM
> To: IETF-Announce; @cafax.se
> Cc: [email-masked]
> Subject: [ietf-provreg] I-D ACTION:draft-ietf-provreg-epp-09.txt
> 
> 
> A New Internet-Draft is available from the on-line 
> Internet-Drafts directories.
> This draft is a work item of the Provisioning Registry 
> Protocol Working Group of the IETF.
> 
> 	Title		: Extensible Provisioning Protocol
> 	Author(s)	: S. Hollenbeck
> 	Filename	: draft-ietf-provreg-epp-09.txt
> 	Pages		: 75
> 	Date		: 2003-3-21
> 	
> This document describes an application layer client-server protocol
> for the provisioning and management of objects stored in a shared
> central repository.  Specified in XML, the protocol defines generic
> object management operations and an extensible framework that maps
> protocol operations to objects.  This document includes a protocol
> specification, an object mapping template, and an XML media type
> registration.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-09.txt

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: [ietf-provreg] I-D ACTION:draft-ietf-provreg-epp-09.txt
Date: Mon, 24 Mar 2003 07:25:43 -0500
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Provisioning Registry Protocol Working Group of the IETF.

	Title		: Extensible Provisioning Protocol
	Author(s)	: S. Hollenbeck
	Filename	: draft-ietf-provreg-epp-09.txt
	Pages		: 75
	Date		: 2003-3-21
	
This document describes an application layer client-server protocol
for the provisioning and management of objects stored in a shared
central repository.  Specified in XML, the protocol defines generic
object management operations and an extensible framework that maps
protocol operations to objects.  This document includes a protocol
specification, an object mapping template, and an XML media type
registration.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-09.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-provreg-epp-09.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-provreg-epp-09.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-provreg-epp-09.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-provreg-epp-09.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Mon, 24 Mar 2003 00:59:39 -0500
Subject: Re: [ietf-provreg] References for Today's Host Object Discussion
Cc: "[email-masked]'" <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>
From: Joe Abley <[email-masked]>
Sender: [email-masked]

On Thursday, Mar 20, 2003, at 15:39 Canada/Eastern, Hollenbeck, Scott 
wrote:

> - Allowing a choice between name server host objects and name server 
> domain
> attributes.
> http://www.cafax.se/ietf-provreg/maillist/2001-12/msg00024.html
>
> I've included references to the list archives where I've been able to 
> find
> them.  What did we ever do before google came along...
>
> For what it's worth, I kind of like the last option (or something like 
> it)
> as something to consider for the next version of the protocol.  We've 
> heard
> a lot of comments from people having issues with host objects as name
> servers; maybe we can eliminate the issues if we allow a choice.

Thanks for posting that link; I have been hearing similar comments for 
some time, and I hadn't realised the issue had already been considered. 
Eliminating the requirement to support host objects would make EPP a 
viable prospect for several registries that I have talked to recently.

I wonder whether it might be reasonable to accommodate the 
non-host-object case in the current spec before it is shipped for 
proposed standard. This doesn't seem like it would be a major change to 
the text, and the impact on existing implementations seems small (zero, 
maybe) considering that the spec would not change for registries which 
choose to include host objects.

I would be happy to contribute text if this sounds like a reasonable 
approach.

Joe

To: Randy Bush <[email-masked]>
cc: Eric Brunner-Williams in Portland Maine <[email-masked]>, "Edmon Chung" <[email-masked]>, [email-masked], "Ted Hardie" <[email-masked]>, "Ned Freed" <[email-masked]>, "Edward Lewis" <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: [ietf-provreg] provreg's privacy issue 
Date: Fri, 21 Mar 2003 10:51:29 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

Randy, and anyone else with a view,

> a privacy tag, ...
> ...
> ... it's the privacy semantics which ran aground.

In the abstract, there exists at least two distinct values that an
algorithmic evaluation of a variable may yeild.

Ignoring everything else, is the IESG's guidance on this subject,  
that the set of values for which any algorithmic evaluation of a
privacy tag is exactly two? If it is not exactly two, what is the
exact characterization of the value space?

Thanks in advance,
Eric

To: Randy Bush <[email-masked]>
cc: Eric Brunner-Williams in Portland Maine <[email-masked]>, "Edmon Chung" <[email-masked]>, [email-masked], "Ted Hardie" <[email-masked]>, "Ned Freed" <[email-masked]>, "Edward Lewis" <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: [ietf-provreg] provreg's privacy issue 
Date: Fri, 21 Mar 2003 10:51:33 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

Randy, and anyone else with a view,

> once again, data structures 101 sez that each attribute would have
> a privacy tag, as opposed to a blob of tags at the front.

In the abstract, there exists at least one type definition hierarchy.
At least one hierarchy is non-degenerate, and the "primitive" and
"constructed" model of derivation exists.

Ignoring everything else, is the IESG's guidance on this subject,
that the type definition hierarchies contained in the EPP spec,
fundamentally err by reference to a built-in derived type, or to
a primitive type?

Thanks in advance,
Eric

To: "Edmon Chung" <[email-masked]>
cc: "Eric Brunner-Williams in Portland Maine" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [ietf-provreg] provreg's privacy issue 
Date: Thu, 20 Mar 2003 17:00:33 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

> > So you see this as a field query mechanism.  Fine.
> >
> > > ... it just allows the registry to annouce its policies ...
> >
> > "Which fields are manditory to fill in?"
> 
> No.  This will result in a failure to create, not a successful response.

My point was, you've designed a query mechanism, and what looks like a two
command sequence.

> > is different from
> > "What is done with data provisioned?"
> 
> Yes. This is the intent.  Public means that the info will be published to
> the WHOIS, and Private means that it will be hidden.  The current mechanism
> is this simple.

Well, not-via-:43 is clear. "private" and "public" are terms of art that
resist unambiguous specification.

> > or less the same session, you've not solved for the day when policies do
> > in fact change.
> 
> So you are saying that the server should perhaps queue a msg for the client
> if policies are to be changed?... or something in-band to announce to the
> clients?

I point out that there is a temporal property contained in the <dcp>, that
the retention period of the data (and the policies announced when the server
announces its availability to collect data) is known to the client (along
with anything else that might be in a <dcp>, prior to the client submitting
data to the server.

> > But you thought that through, and decided that the temporal properties of
> > polices is better communicated out-of-band, so they could in fact change
> > without in-band notice.
> 
> Just thought it seems to make a bit more sense in a practical environment.
> For example, when I look at a ccTLD, they will be putting out a public
> statement or even consultation paper or something before they change their
> policies,

Sense? Practicality? Taste varies. I'd like to automate privacy/datacollection
handling in registration systems.

> > If the temporal properties of policies are better communicated
> out-of-band,
> > why are the semantic properties of policies better communicated in-band?
> 
> Because of 2 things:
> 
> 1. the client needs to know what (which info item) exactly they can manage
> (public/private)
> 2. they can toggle public/private on the aspects that are allowed to be
> optional

But with no guarantee that the policies will be consistent between any two
consequtive registrations.

> > Your proposal makes no reliance upon any policy information from the
> > registry. You've proposed a momentary capabilities check arising from
> > a <create> command, but you only get the data in the response.
> 
> So perhaps it is good to extend the check command as well to return the
> policy statements so that clients will know what they are getting into
> beforehand...

Back to the two-step. Familiar to registrars who want to know if a <create>
of "somewellknownname" will fail, before attempting it.

<check><create>.

Not significantly different from

<create><update> (and optionally, if disapointed, <delete>).

> > Its a hell of a lot easier to simply have the server announce its policy,
> > and if a mechanism is necessary to select some set of values from some
> > range of values (and I'm referring to purpose, recipient, retention and
> > so forth, as well as which field in the contact object is optional), to
> > get on with its specification, than finding it after assuming it even
> > exists.
> 
> dcp should be good to deal with the purpose and stuff.  My proposal aims to
> make an effort to allow granular management of information privacy.  We
> could extend the tags so that each facet can be further optionally bound by
> multiple policies based on the usage of data.  Also, I think you are right,
> perhaps the info response should be a bit different and allow the client to
> query for only the privacy policy elements and not return the entire glob
> everytime.  I will make that change.

<info><create>.

Eric

From: "Hollenbeck, Scott" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: [ietf-provreg] References for Today's Host Object Discussion
Date: Thu, 20 Mar 2003 15:39:13 -0500
Sender: [email-masked]

After today's meeting some people asked me for a reference to an earlier
discussion about host objects being used as name servers.  For those of you
who weren't there, we talked a little bit about the history of why we have
an object concept for name server hosts.  Part of the ensuing discussion
touched on all of the options that have been discussed over the last few
years, including:

- Host objects for all name servers.
(This is a simplified expression of what we have in the documents now)

- Host objects for only in-zone hosts, with external hosts specified as
domain object attributes.
http://www.cafax.se/ietf-provreg/maillist/2002-11/msg00008.html

- Allowing a choice between name server host objects and name server domain
attributes.
http://www.cafax.se/ietf-provreg/maillist/2001-12/msg00024.html

I've included references to the list archives where I've been able to find
them.  What did we ever do before google came along...

For what it's worth, I kind of like the last option (or something like it)
as something to consider for the next version of the protocol.  We've heard
a lot of comments from people having issues with host objects as name
servers; maybe we can eliminate the issues if we allow a choice.

-Scott-

From: "Edmon Chung" <[email-masked]>
To: "Eric Brunner-Williams in Portland Maine" <[email-masked]>
Cc: "Eric Brunner-Williams in Portland Maine" <[email-masked]>, <[email-masked]>
Subject: Re: [ietf-provreg] provreg's privacy issue 
Date: Thu, 20 Mar 2003 11:57:05 -0500
Sender: [email-masked]

Hi Eric,

----- Original Message -----
From: "Eric Brunner-Williams in Portland Maine" <[email-masked]>
> I'll send you what I did to de-xml-ize p3p policies on cookies, where
overhead
> did matter. Here however, overhead shouldn't. But don't optimize too early
...

That will be great.  Yeah, we were thinking that we should maintain
flexibility first and then optimize later (in fact, our actual
implementation is much leaner... but because this was intended to be a
protocol discussion, we made it a bit more extensible. and thus, larger
overhead.

> > I do not understand why it does not apply to the WHOIS...
>
> It does, but there are some loopholes.
>
> > ... 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 ...
>
> So you see this as a field query mechanism.  Fine.
>
> > ... it just allows the registry to annouce its policies ...
>
> "Which fields are manditory to fill in?"

No.  This will result in a failure to create, not a successful response.

> is different from
> "What is done with data provisioned?"

Yes. This is the intent.  Public means that the info will be published to
the WHOIS, and Private means that it will be hidden.  The current mechanism
is this simple.

> Yes I do. To be concrete, domains are sold by the COM/NET registry to a
set
> of registrars, for periods of up to 10 years. What are the temporal
properties
> of policy guarantees? If you assume a place-holder create, followed by the
> "real" create, more or less in the same session, or a real create,
followed
> by a series of updates to "tune" the privacy policy to taste, again in
more
> or less the same session, you've not solved for the day when policies do
in
> fact change.

So you are saying that the server should perhaps queue a msg for the client
if policies are to be changed?... or something in-band to announce to the
clients?

> But you thought that through, and decided that the temporal properties of
> polices is better communicated out-of-band, so they could in fact change
> without in-band notice.

Just thought it seems to make a bit more sense in a practical environment.
For example, when I look at a ccTLD, they will be putting out a public
statement or even consultation paper or something before they change their
policies,

> If the temporal properties of policies are better communicated
out-of-band,
> why are the semantic properties of policies better communicated in-band?

Because of 2 things:

1. the client needs to know what (which info item) exactly they can manage
(public/private)
2. they can toggle public/private on the aspects that are allowed to be
optional

> Your proposal makes no reliance upon any policy information from the
> registry. You've proposed a momentary capabilities check arising from
> a <create> command, but you only get the data in the response.

So perhaps it is good to extend the check command as well to return the
policy statements so that clients will know what they are getting into
beforehand...

> Its a hell of a lot easier to simply have the server announce its policy,
> and if a mechanism is necessary to select some set of values from some
> range of values (and I'm referring to purpose, recipient, retention and
> so forth, as well as which field in the contact object is optional), to
> get on with its specification, than finding it after assuming it even
> exists.

dcp should be good to deal with the purpose and stuff.  My proposal aims to
make an effort to allow granular management of information privacy.  We
could extend the tags so that each facet can be further optionally bound by
multiple policies based on the usage of data.  Also, I think you are right,
perhaps the info response should be a bit different and allow the client to
query for only the privacy policy elements and not return the entire glob
everytime.  I will make that change.

Edmon

To: "Edmon Chung" <[email-masked]>
cc: "Eric Brunner-Williams in Portland Maine" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [ietf-provreg] provreg's privacy issue 
Date: Thu, 20 Mar 2003 00:07:50 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

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

No one reads mine, so I'll stop writing it and read yours, its the worst
I can do ;-)

> It is a bit bulky right now.

I'll send you what I did to de-xml-ize p3p policies on cookies, where overhead
did matter. Here however, overhead shouldn't. But don't optimize too early ...

> > o a bi-di glob on <update>!!!
> 
> bi-di glob??... what do you mean?

On both command and response. This is where the action is. Who cares if the
server <info> and <create> responses have new glop? What counts is if by a
write (here <update>) against the shared store (here registry) manages to
either fail to error (glop accepted by registry as some policy description,
considered by registry to be "valid"), or can generate a change in the glop
that comes back in any response. If none, then either the registry had the
"right" policy already, or ignored the attempted policing of data previously
provisioned in the client <create> (and nominally annotated in the new glop
in the <create> repsponse).

> I do not understand why it does not apply to the WHOIS...

It does, but there are some loopholes.

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

So you see this as a field query mechanism.  Fine.

> ... it just allows the registry to annouce its policies ...

	"Which fields are manditory to fill in?"
is different from
	"What is done with data provisioned?"

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

Yes I do. To be concrete, domains are sold by the COM/NET registry to a set
of registrars, for periods of up to 10 years. What are the temporal properties
of policy guarantees? If you assume a place-holder create, followed by the
"real" create, more or less in the same session, or a real create, followed
by a series of updates to "tune" the privacy policy to taste, again in more
or less the same session, you've not solved for the day when policies do in
fact change.

But you thought that through, and decided that the temporal properties of
polices is better communicated out-of-band, so they could in fact change
without in-band notice.

If the temporal properties of policies are better communicated out-of-band,
why are the semantic properties of policies better communicated in-band?

> > Why "discover" access policy _after_ a committing a write?
> 
> Please clarify what you mean?

Your proposal makes no reliance upon any policy information from the
registry. You've proposed a momentary capabilities check arising from
a <create> command, but you only get the data in the response.

Therefore, either each <create> command is preceeded by some command who's
side effect is to discover the present policy, or each <create> command is
followed by a series of one or more <update> commands to conform the policy
(applicable to some specific object) at the server to the policy goal held
by the client.

Its a hell of a lot easier to simply have the server announce its policy,
and if a mechanism is necessary to select some set of values from some
range of values (and I'm referring to purpose, recipient, retention and
so forth, as well as which field in the contact object is optional), to
get on with its specification, than finding it after assuming it even
exists.

Eric

P.S. Get rid of everything except the <update> glop. <create>, <update>,
test <update> response, repeat until correct, or failure. Upon failure,
issue <delete>. If <delete> fails, issue <update> with the personal data
of the registry CEO, or the current ICANN CEO, depending on one's sense
of humor.

P.P.S. This only solves for WHOIS, not for any other purpose, mechanism,
or period, to which provisioned data may be used without prior disclosure
and informed consent, or at least the opportunity to form same, buy the
registrar, and presumbly the parties it acts on behalf of.

P.P.P.S. Cheers!

From: "Edmon Chung" <[email-masked]>
To: "Eric Brunner-Williams in Portland Maine" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: [ietf-provreg] provreg's privacy issue 
Date: Wed, 19 Mar 2003 21:30:35 -0500
Sender: [email-masked]

Hi Eric,

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

----- Original Message -----
From: "Eric Brunner-Williams in Portland Maine" <[email-masked]>
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

From: Randy Bush <[email-masked]>
Date: Wed, 19 Mar 2003 15:45:56 -0800
To: Eric Brunner-Williams in Portland Maine <[email-masked]>
Cc: "Edmon Chung" <[email-masked]>, [email-masked], "Ted Hardie" <[email-masked]>, "Ned Freed" <[email-masked]>, "Edward Lewis" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [ietf-provreg] provreg's privacy issue 
Sender: [email-masked]

> 	o a BEGIN END section of formal syntax with very, very little text
> 	  seperating these delimeters (don't worry, we haven't gotten even
> 	  a syntax clue from the IESG),

this is quite incorrect, you just didn't like it.

once again, data structures 101 sez that each attribute would have
a privacy tag, as opposed to a blob of tags at the front.  but, as
far as i am aware, no one on the iesg cares that much about the
syntax, it's the privacy semantics which ran aground.

randy

To: Randy Bush <[email-masked]>
cc: Eric Brunner-Williams in Portland Maine <[email-masked]>, "Edmon Chung" <[email-masked]>, [email-masked], "Ted Hardie" <[email-masked]>, "Ned Freed" <[email-masked]>, "Edward Lewis" <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: [ietf-provreg] provreg's privacy issue 
Date: Wed, 19 Mar 2003 18:53:11 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

> this is quite incorrect, you just didn't like it.

Am I that shallow? Well, a pointer to the item with a substantive proposal
would be nice.

Eric

To: Edward Lewis <[email-masked]>
cc: Eric Brunner-Williams in Portland Maine <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: [ietf-provreg] EPP, data, actors, and access 
Date: Wed, 19 Mar 2003 18:45:22 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

Ed,

A quick reply, between kidz on my end, and distractions on yours.

> Let's do this as a first order approximation - is it possible to 
> specify whether a data item (call it what you will) is not allowed to 
> be repeated by the registry to any one other than the registrar that 
> submitted it?  Is this something that is common enough to be 
> understood by all?  Is this potentially sufficient to satisfy all 
> people's needs here?

The registry can assert that this is its policy via the <dcp>.

Where the value is in having the registrar attempt to bind such a policy
to a data item (I'm partial to mumbles and globs), rather than having a
policy bound to the mumble or glob by the registry is possibly an article
of religious faith.

I've written why the converse is true, possibly in moments of religious
euphoria.

Eric

To: "Edmon Chung" <[email-masked]>
cc: [email-masked], "Ted Hardie" <[email-masked]>, "Ned Freed" <[email-masked]>, [email-masked], "Edward Lewis" <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: [ietf-provreg] provreg's privacy issue 
Date: Wed, 19 Mar 2003 18:39:08 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

Edmon, Henry,

Some text, on this list, before going off into the delirium of boiler-plate,
would have been a blessing, neh?

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,
	o a glob on <create> response, ditto,
	o a bi-di glob on <update>!!!

I see ...
	o a BEGIN END section of formal syntax with very, very little text
	  seperating these delimeters (don't worry, we haven't gotten even
	  a syntax clue from the IESG),

I see ...
	o a totally irrelevent i18n section, but I understand, this is one
	  of Neteka's sweet spots (besides, the IESG will surely appreciate
	  the suggestion that XML will melt if "private parts" is written
	  in Chinese, and the Chinese characters encoded in Big5),

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

So, the inference from the examples is that the syntax is a restatement of
a big bit of the contact object, putting a binary, or enumerated set of
value against each element -- sort of pervasive, but restricted to the
contact object, attributes (but as an additional carried along "shadow"
of the original, unencumbered contact object.

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.

Here's my you-pay-for-dinner question:

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

Heck, lets go for two dinners, there are two of you anyway:

	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.

Now what happens?

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

There is an Americn idiom about closing a barn door _after_ the horses
have left.

I'm always lacking clue,
Eric

Date: Wed, 19 Mar 2003 14:54:03 -0800
To: Eric Brunner-Williams in Portland Maine <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: Re: [ietf-provreg] EPP, data, actors, and access
Cc: [email-masked], [email-masked]
Sender: [email-masked]

At 8:35 -0500 3/19/03, Eric Brunner-Williams in Portland Maine wrote:
>Oki all,
>
>We have two distinct proposals for a specification of access, data, and
>actors for EPP. External to EPP, but possibly relevant, is the existence
>of WHOIS (954).

You are expressing a very detailed understanding of the problem.  One 
of the issues I have with being this detailed is that it makes the 
chance of consensus less likely to achieve.

I can see the point that perhaps I want my telephone number to appear 
in WHOIS but not in DNS (to pick a perverse situation).

Let's do this as a first order approximation - is it possible to 
specify whether a data item (call it what you will) is not allowed to 
be repeated by the registry to any one other than the registrar that 
submitted it?  Is this something that is common enough to be 
understood by all?  Is this potentially sufficient to satisfy all 
people's needs here?

(Presuming the above meets with consensus, and then while sitting at 
proposed we discover that the mechanism is useless, dropping it or 
replacing it is always an option.  At that time, we will be able to 
point to emperical evidence of the goodness/badness of it.)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

Date: Wed, 19 Mar 2003 14:48:30 -0800
To: Eric Brunner-Williams in Portland Maine <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: Re: [ietf-provreg] EPP, data, actors, and access
Cc: Ted Hardie <[email-masked]>, [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

At 14:06 -0500 3/19/03, Eric Brunner-Williams in Portland Maine wrote:
>Ted,
>
>>  I think we have identified ways forward on this issue in this week ...
>
>I've no idea what this means. We (possibly a different value of "we")
>thought we were getting consensus around a proposal (<dcp> manditory),
>some time prior to this week, e.g., last week.

We = some set of people.  It's not important yet, what is important 
is whether or not the WG as a whole also agrees.

Let's not worry about the source of the proposal, let's worry about 
the quality of the proposal.

During the face to face meeting on Thursday, we will systemically not 
come to a conclusion.  The best use of the time is as a "bull" 
session, to throw ideas back and forth for some amount of time (the 
amount given is a function of the relative usefulness of the 
conversation).  At the end of the bull session, it will be the job of 
the chairs to prepare something to put in the list and to then begin 
the process of drafting an approach acceptable to the group as a 
whole.

Consensus is not achieved by voting, but by arriving at a set of 
statements that are acceptable to (nearly) all with a stake - WG 
members, IESG, and the silent masses following this work.  Let's put 
it this way, if we want to rent a car, if 80% of the WG wants to 
require a red one and the other 20% wants blue, we'll settle on 
wanting to just rent a car.

>As to timing of meetings, I don't attend meetings held in belligerant states
>during periods of belligerency. It is dangerous, it requires acts of active
>cooperation with the security regimes of the belligerant state(s), and is
>an endorsement of belligerency. I'd rather not.

Absence is perfectly permissible, after all the IETF is a volunteer 
organization.  The sentiment expressed is that it would have been 
keen to have you in attendance so that we could more quickly arrive 
at a common understanding of the problem.  It is our fault if you 
feel the need to defend your choice not to travel.  (I'm *not* going 
to define "our." ;))

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

From: "Edmon Chung" <[email-masked]>
To: <[email-masked]>, "Ted Hardie" <[email-masked]>, "Ned Freed" <[email-masked]>, <[email-masked]>, "Edward Lewis" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: Re: [ietf-provreg] provreg's privacy issue
Date: Wed, 19 Mar 2003 15:59:57 -0500
Sender: [email-masked]

Hi,

----- Original Message -----
From: "Edward Lewis" <[email-masked]>
> In response to the IESG comment:
>
>      why do domain/contact/.. not have granular information about privacy?
>

I am not sure if the draft that I am working on would help:

http://ner2r.com/draft-ietf-provreg-epp-privacy-00.txt

The document proposes an EPP extension to handle Domain Contact Privacy
Profiles and is kept extremely flexible so that it should be able to adopt
to registry mandated or client enforced/suggested privacy profiles.
It basically describes a private/public toggle for as well as a way to
announce registry policy on each attribute of each contact in a domain name.

This is in fact something similar to what we have implemented for a client.
Mainly for what contact info could/must be published through the WHOIS.

One thing that this current draft has not addressed is if there needs to be
different types of disclosure to different types of querying entities.  But
could be added by allowing multiple policies and to add a policy type
attribute.

Have to admit however that the bulk of the wordings in the document itself
was stolen from Scott's enum draft.  Well... I think Scott did a good job in
providing a great template for EPP extension docs. :-)

Edmon

To: Ted Hardie <[email-masked]>
cc: [email-masked], [email-masked], [email-masked]
Subject: Re: [ietf-provreg] EPP, data, actors, and access 
Date: Wed, 19 Mar 2003 14:06:25 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

Ted,

> I think we have identified ways forward on this issue in this week ...

I've no idea what this means. We (possibly a different value of "we")
thought we were getting consensus around a proposal (<dcp> manditory),
some time prior to this week, e.g., last week.

As to timing of meetings, I don't attend meetings held in belligerant states
during periods of belligerency. It is dangerous, it requires acts of active
cooperation with the security regimes of the belligerant state(s), and is
an endorsement of belligerency. I'd rather not.

Eric

Date: Wed, 19 Mar 2003 09:15:57 -0800
Subject: [ietf-provreg] EPP, data, actors, and access
From: Ted Hardie <[email-masked]>
To: [email-masked], [email-masked]
Sender: [email-masked]

Eric,
	Sorry that you weren't able to make the San Francisco meeting
as one of the real advantages our face-to-face meetings afford is
the opportunity to get high bandwidth immediate response.  I think
we have identified ways forward on this issue in this week.  Given
the press of events during the week, they are not expressed in drafts;
I'm sure they will be expressed in drafts as soon as we all have a 
chance.
	After the ProvReg meeting gets a sense of the room on the
discussion, all of these conversations will be confirmed on the list,
so you will have a chance to discuss them.  As the incoming AD here,
I am trying to catch up on all this as fast as I can; I appreciate the
patience of the group as I work out what I can do to help us all
make progress.
				regards,
						Ted Hardie

To: [email-masked], [email-masked]
Subject: [ietf-provreg] EPP, data, actors, and access
Date: Wed, 19 Mar 2003 08:35:12 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

Oki all,

We have two distinct proposals for a specification of access, data, and
actors for EPP. External to EPP, but possibly relevant, is the existence
of WHOIS (954).

One approach scopes some meta-data to sessions, within a connectionist,
client-server model, with the server originating the meta-data. As a
matter of syntax, this approach is extensible as to semantics associated
with a session.

One approach scopes some meta-data to data only, with the client originating
the meta-data. The syntax for this approach is various, but two designs of
note are an element (in the degenerate case, an attribute only) for some or
all elements of data, and an element for each aggregation of data, e.g., the
contact object, with some mapping to some or all elements of data within the
aggregation.

It is possible that if both a session-scoped mechanism, and a data-scoped
mechanism are presented to a pair of EPP peers, neither being semantically
null, that the peers will not correctly and interoperably evaluate the
semantics of both mechanisms.

This is made more likely if the evaluation-spaces of the two mechanisms
are not identical, nor avail trivial forward and reverse mapping between
nominally equivalent mechanism-specific representations.

A design choice pioneered, at least within the PROVREG context, by one
contributor, is to add a binary toggle, or a set of enumerated values,
that allow some new semantic. As that contributor demonstrated, and as
a subsequent implementations have shown, it is possible to add payload
with a distinct syntactic form. See [1] for details.

I mention this to acknowledge that a WHOIS-specific optimization is a
possibility, that such a "hack" need not conform to the syntax of the
current protocol, and that as an implementation matter, it is tractible.
I add that such an optimization presents challenges for users who may
seek to modify the optimization, or to obtain transparently equivalent
transaction semantics, independent of EPP endpoint operator.

One statement associated with client-origination is that it is actually
registrant-origination. This presents two problems, the first theoretic,
as EPP is between registrars and registries. The working group chose to
create an interoperable protocol for data exchange between registrars and
registries. Some other working group may be formed, if an interoperable
protocol for data exchange between registrants and registrars is useful.

The second problem is user-interface specification. Is the value-space of
the new data binary? Is it an enumerated set?  Is it an enumerated set of
enumerated sets? Is it a tree with some branch ordering and evaluation
property? Isn't this a discussion of what boxes, knobs, and sliders exist
on a registrars registrant-facing data collection API? There are instances
of UI specification within the IETF, but that is not in the PROVREG charter.

I've written quite a bit over the past several months, critically, but
as intelligently as I can manage, on what is referred to as "the IESG
privacy proposal". I have no objective indication that any member of
the IESG has read anything I've contributed to the PROVREG list. That's
OK, this isn't some quest for emotional gratification. What puzzles me
is the utter lack of substantive contribution, whether responsive to
my writings, or those of anyone else, that moves beyond a gesture towards
a requirements statement.

Real requirements are intelligently discussed, unless they arise from
kings, presidents, and voting.

Real proposals are in the form of public drafts, eventually.

Eric

[1] draft-liu-epp-ustld-01.txt, expired. Author at [email-masked].
A copy may exist in the PROVREG list mail archive.

To: Edward Lewis <[email-masked]>
cc: [email-masked], [email-masked], Ted Hardie <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [ietf-provreg] again with the privacy 
Date: Tue, 18 Mar 2003 07:52:12 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

Ed,

A mechanism to disclose the operational practices and policies of operators
of EPP servers with respect to "data collection", aka "privacy", is NOT a
requirement, and section 8.4 of rfc 3375, in particular the final sentance
of para 1, is incorrect.

I can live with being responsible for that train wreck.

Protocols developed under the imprimature of "the IETF", MUST NOT provide
mechanism(s) to disclose the data collection policies, in particular, the
polices to which data which identifies individual persons is subject, of
operators of the protocols.

Sounds grand and very Directorial.

Instead "we're supposed to" come up with some dork that will allow the
naive data we currently have, in the schema we currently have, with the
syntax we currently have, to "twinkle", and to provision, not just any
data collector, but only the registry operator, with this "twinkle"
property, for each provisioned glob of data, and this whole waste of
time is because 954 can't be moved to historic.

I'll be sure and tell my registrar that I want only the octets-pairs that
are prime when interpreted as Mayan digits (base 20) to be "published".

I'm obviously in the wrong IETF. I'm in the one where clue is not held
uniquely by management. The "IETF of Idiots".

I do not see the point in bothering to pretend to write a specification
that is in fact written by someone else. I'll just treat the eventual RFC
as having no more "consensus engineering standards" value than an equal page
count text that comes directly from Verisign. Implement it, and don't think
too hard about it.

I give up. I could use this time better playing with my kids, and making
open, interoperable (but not IETF referencing) product.

Eric

Date: Mon, 17 Mar 2003 21:41:40 -0800 (PST)
From: Rick Wesson <[email-masked]>
To: Edward Lewis <[email-masked]>
cc: <[email-masked]>, <[email-masked]>, Ted Hardie <[email-masked]>, <[email-masked]>
Subject: Re: [ietf-provreg] again with the privacy
Sender: [email-masked]

Ed,

all of the "issues" enumerated below are really non-issues, we only need
the privacy bits for social data not technical data. The IESG didn't ask
us to create a privacy framework for hiding DNS hosts (which is silly) see
[1]

the <dnd> element proposal, not to be confused with the attribute
proposal, does address registrar -> registry boolean notes of what
social data is to remain private.

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

I propose that we don't have the problems you enumerate below if we
restrict the elements that can be enclosed by a <dnd> element are only
social data elements.

-rick

On Mon, 17 Mar 2003, Edward Lewis wrote:

> Jaap and I talked with Ted Hardie (incoming Apps Area AD) and Patrik
> Faltstrom (outgoing Apps Area AD) about the state of the WG.  (Sorry,
> no mics were present to get the verbatim record of this.)  I say this
> because in the past Jaap and I have tried hard to stay away from
> injecting technical material as chairs.  However, it seems clear that
> one more go of this is needed, so we are floating this again.
>
> Below is the proposal that was generated in December in response to
> the IESG comments.  I'm resurrecting it again based on this:
>
>    The IESG wants a means for a registrar to tell a registry whether or
>    not a piece of data can be passed on.  (DCP goes from registry to registrar,
>    we need a reverse version of this communication.)
>
>     dnd="true" means: this info cannot leave the registry, not in DNS, not in
>     whois, not in another means.
>
>    What if a domain name's DNS server is dnd="true"?  Does it make DNS - no.
>    Is this sensible?  Probably not.
>
> This isn't expressive enough for all involved, but it is a basic step.
>
> There were some objections to this in Dec/Jan.
>
> >1. "do not disclose" seems non-extensible, when extensibility seems important.
>
> It's a place holder.  More elaborate information can appear later.
>
> >2. A complete proposal should specify whether a "dnd"d field should be
> >distinguished from a non-existent field when presenting data to clients (e.g.
> >via <info> commands). If it should, then the proscribed manner in which that
> >should be done should be included for <info>.
>
> Good question.  Info could return "value hidden".  What about
> 'hiding' the provisioned name?  I think acknowledging it's
> unavailability is excuseable.
>
> >3. What should <check> return if the object being checked is marked as
> >dnd="true" and the client doing the <check> is one to which disclosure is
> >prohibited?
>
> See above.
>
> >For the server side the attribute based approach is more cumbersome.
>
> I cannot answer that one.
>
> The AD's conjectured that for PS, if we were to put this proposal
> into play and it went unused, it could be removed for DS...
>
> Comments about this?
>
> This will be discussed Thursday morning.
>
> >X-Authentication-Warning: nic.cafax.se: majordom set sender to
> >[email-masked] using -f
> >From: "Hollenbeck, Scott" <[email-masked]>
> >To: "[email-masked]'" <[email-masked]>
> >Subject: Updated (and hopefully the last) EPP Privacy Proposal
> >Date: Mon, 30 Dec 2002 09:08:46 -0500
> >Importance: high
> >X-Priority: 1
> >Sender: [email-masked]
> >Status:
> >
> >In ongoing background discussions with the IESG regarding our EPP documents,
> >we (Jaap, Ed, several IESG members, and I) have continued to talk about the
> >IESG's privacy-related comments and the responses to those comments that
> >have been sent to the WG mailing list.  We've concluded that we need to add
> >a "must implement" feature to the protocol to allow data elements to be
> >tagged with a binary indicator of data owner preference for disclosure of
> >information to third parties that aren't involved in the provisioning
> >transaction.  Back in October [1] I described a proposal to use an XML
> >attribute for this purpose.  Over the last few weeks ([2], [3]) I suggested
> >a few other options.  Considering all of our options, I would again like to
> >suggest an XML attribute-based approach to address this last remaining IESG
> >review issue.
> >
> >This does not mean that the binary indicator is the only way that privacy
> >preferences or policies can be expressed.  Expression of more specific
> >privacy policies can be accomplished using the protocol's extension
> >mechanism.
> >
> >The proposal is to add a new attribute to every object element in the
> >domain, contact, and host mappings.  This boolean attribute, "dnd" (for Do
> >Not Disclose), will be used to note that the value of an element should not
> >be disclosed to third parties.  It will have a default value of "false"
> >(meaning it is ok to disclose info) in the domain and host mappings, and a
> >default value of "true" (meaning it is NOT ok to disclose info) in the
> >contact mapping.  The defaults can be over-ridden and explicitly specified
> >by clients.  Additional constraints can be defined using the protocol
> >extension mechanism.
> >
> >Here are some examples:
> >
> ><contact:email dnd="true">[email-masked]</contact:email>
> ><contact:email>[email-masked]</contact:email>
> >Both of the above mean "do not disclose this email address to third
> >parties".
> >
> ><contact:email dnd="false">[email-masked]</contact:email>
> >This means that the data owner gives permission for the email address to be
> >disclosed to third parties.
> >
> ><extension>
> >   <noWhois><contact:email></noWhois>
> ></extension>
> >
> >(This extension example isn't syntactically valid, but I wanted it to be
> >short, clear, and to the point without the clutter needed to make it valid.
> >In this case it means that the email address should not be published via
> >whois.)
> >
> >I'll also have to add some notes to explain that server policy might not
> >recognize the value of an attribute if it's turned on (like in the email
> >address example above) when turning on the attribute is counter to some
> >policy.
> >
> >A measure of WG support or dissatisfaction with this proposal would be
> >helpful.  Would you please send a note to the mailing list to let the chairs
> >know if you either support the proposal as a way to move forward or if you
> >do not support the proposal?  If you do not support the proposal it would be
> >helpful if you explained why and could suggest modifications (if possible)
> >to make it acceptable.
> >
> >If you do not support the proposal, please recognize that we have been stuck
> >on this issue for quite a while and we need to do something.  On the one
> >hand, we are aware of the differences in privacy policy, laws, et al. facing
> >each registry.  On the other hand, we are being asked to define one standard
> >protocol that is rigorous enough to not let privacy slide by.  So the
> >question is - does this proposal (including extension support) allow for all
> >known policies to be expressed within EPP?
> >
> >-Scott-
> >
> >[1]
> >http://www.cafax.se/ietf-provreg/maillist/2002-10/msg00041.html
> >
> >[2]
> >http://www.cafax.se/ietf-provreg/maillist/2002-12/msg00089.html
> >
> >[3]
> --
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Edward Lewis                                          +1-703-227-9854
> ARIN Research Engineer
>

Date: Mon, 17 Mar 2003 21:13:34 -0800
To: [email-masked]
From: Edward Lewis <[email-masked]>
Subject: [ietf-provreg] again with the privacy
Cc: [email-masked], [email-masked], Ted Hardie <[email-masked]>, [email-masked]
Sender: [email-masked]

Jaap and I talked with Ted Hardie (incoming Apps Area AD) and Patrik 
Faltstrom (outgoing Apps Area AD) about the state of the WG.  (Sorry, 
no mics were present to get the verbatim record of this.)  I say this 
because in the past Jaap and I have tried hard to stay away from 
injecting technical material as chairs.  However, it seems clear that 
one more go of this is needed, so we are floating this again.

Below is the proposal that was generated in December in response to 
the IESG comments.  I'm resurrecting it again based on this:

   The IESG wants a means for a registrar to tell a registry whether or
   not a piece of data can be passed on.  (DCP goes from registry to registrar,
   we need a reverse version of this communication.)

    dnd="true" means: this info cannot leave the registry, not in DNS, not in
    whois, not in another means.

   What if a domain name's DNS server is dnd="true"?  Does it make DNS - no.
   Is this sensible?  Probably not.

This isn't expressive enough for all involved, but it is a basic step.

There were some objections to this in Dec/Jan.

>1. "do not disclose" seems non-extensible, when extensibility seems important.

It's a place holder.  More elaborate information can appear later.

>2. A complete proposal should specify whether a "dnd"d field should be
>distinguished from a non-existent field when presenting data to clients (e.g.
>via <info> commands). If it should, then the proscribed manner in which that
>should be done should be included for <info>.

Good question.  Info could return "value hidden".  What about 
'hiding' the provisioned name?  I think acknowledging it's 
unavailability is excuseable.

>3. What should <check> return if the object being checked is marked as
>dnd="true" and the client doing the <check> is one to which disclosure is
>prohibited?

See above.

>For the server side the attribute based approach is more cumbersome.

I cannot answer that one.

The AD's conjectured that for PS, if we were to put this proposal 
into play and it went unused, it could be removed for DS...

Comments about this?

This will be discussed Thursday morning.

>X-Authentication-Warning: nic.cafax.se: majordom set sender to 
>[email-masked] using -f
>From: "Hollenbeck, Scott" <[email-masked]>
>To: "[email-masked]'" <[email-masked]>
>Subject: Updated (and hopefully the last) EPP Privacy Proposal
>Date: Mon, 30 Dec 2002 09:08:46 -0500
>Importance: high
>X-Priority: 1
>Sender: [email-masked]
>Status:
>
>In ongoing background discussions with the IESG regarding our EPP documents,
>we (Jaap, Ed, several IESG members, and I) have continued to talk about the
>IESG's privacy-related comments and the responses to those comments that
>have been sent to the WG mailing list.  We've concluded that we need to add
>a "must implement" feature to the protocol to allow data elements to be
>tagged with a binary indicator of data owner preference for disclosure of
>information to third parties that aren't involved in the provisioning
>transaction.  Back in October [1] I described a proposal to use an XML
>attribute for this purpose.  Over the last few weeks ([2], [3]) I suggested
>a few other options.  Considering all of our options, I would again like to
>suggest an XML attribute-based approach to address this last remaining IESG
>review issue.
>
>This does not mean that the binary indicator is the only way that privacy
>preferences or policies can be expressed.  Expression of more specific
>privacy policies can be accomplished using the protocol's extension
>mechanism.
>
>The proposal is to add a new attribute to every object element in the
>domain, contact, and host mappings.  This boolean attribute, "dnd" (for Do
>Not Disclose), will be used to note that the value of an element should not
>be disclosed to third parties.  It will have a default value of "false"
>(meaning it is ok to disclose info) in the domain and host mappings, and a
>default value of "true" (meaning it is NOT ok to disclose info) in the
>contact mapping.  The defaults can be over-ridden and explicitly specified
>by clients.  Additional constraints can be defined using the protocol
>extension mechanism.
>
>Here are some examples:
>
><contact:email dnd="true">[email-masked]</contact:email>
><contact:email>[email-masked]</contact:email>
>Both of the above mean "do not disclose this email address to third
>parties".
>
><contact:email dnd="false">[email-masked]</contact:email>
>This means that the data owner gives permission for the email address to be
>disclosed to third parties.
>
><extension>
>   <noWhois><contact:email></noWhois>
></extension>
>
>(This extension example isn't syntactically valid, but I wanted it to be
>short, clear, and to the point without the clutter needed to make it valid.
>In this case it means that the email address should not be published via
>whois.)
>
>I'll also have to add some notes to explain that server policy might not
>recognize the value of an attribute if it's turned on (like in the email
>address example above) when turning on the attribute is counter to some
>policy.
>
>A measure of WG support or dissatisfaction with this proposal would be
>helpful.  Would you please send a note to the mailing list to let the chairs
>know if you either support the proposal as a way to move forward or if you
>do not support the proposal?  If you do not support the proposal it would be
>helpful if you explained why and could suggest modifications (if possible)
>to make it acceptable.
>
>If you do not support the proposal, please recognize that we have been stuck
>on this issue for quite a while and we need to do something.  On the one
>hand, we are aware of the differences in privacy policy, laws, et al. facing
>each registry.  On the other hand, we are being asked to define one standard
>protocol that is rigorous enough to not let privacy slide by.  So the
>question is - does this proposal (including extension support) allow for all
>known policies to be expressed within EPP?
>
>-Scott-
>
>[1]
>http://www.cafax.se/ietf-provreg/maillist/2002-10/msg00041.html
>
>[2]
>http://www.cafax.se/ietf-provreg/maillist/2002-12/msg00089.html
>
>[3]
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

To: Eric Brunner-Williams in Portland Maine <[email-masked]>
cc: janusz sienkiewicz <[email-masked]>, Rick Wesson <[email-masked]>, "Hollenbeck, Scott" <[email-masked]>, "'Edward Lewis'" <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: [ietf-provreg] thursday's meeting 
Date: Mon, 17 Mar 2003 14:19:41 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

> Where there really is random variation from one data glob to the next, and
> the variations are meaningfully distinct (a kettle of fish that is not yet
> opened), then clearly the "statefull encoding" of policied sequences of
> data globs is not going to work as well as some "statefull encoding" of
> policied, and uncorrolated data globs. 

Oops. That should read

> opened), then clearly the "statefull encoding" of policied sequences of
> data globs is not going to work as well as some "stateless encoding" of
                                                        ^^^^
Eric

To: janusz sienkiewicz <[email-masked]>
cc: Eric Brunner-Williams in Portland Maine <[email-masked]>, Rick Wesson <[email-masked]>, "Hollenbeck, Scott" <[email-masked]>, "'Edward Lewis'" <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: [ietf-provreg] thursday's meeting 
Date: Mon, 17 Mar 2003 14:16:13 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

> Shouldn't  "send dN+2:p1, send dN+3:p1 .... send dN+M:p1" have p3 instead of
> p1?

I should have been explicit.

I'm drawing on some non-provreg data -- real life with cookies.

Few distinct "privacy" "policies" or "preferences" exist.

The distribution of policied cookies and browser values that result in
these three general categories:
	accept-unconditionally
	warn-accept-or-reject-conditionally
	reject-unconditionally
is small, and the modality is less than the total range of values.

The most likely transition will be from one domainant mode to another.

So, p1 to p2 and back to p1, generally, and p1 to p3 and back to p1.
Less frequently will be pN to pM, where N and M are not in the very
small set of dominant modalities of meaningfully distinct policies.

I wasn't trying to show p1, then p2, then p3 usage, but
	
 ...p1p1p1p1p1<break>p2p2<break>p1p1p1p1p1p1pp1<break>p3<break>p1p1...

Where there really is random variation from one data glob to the next, and
the variations are meaningfully distinct (a kettle of fish that is not yet
opened), then clearly the "statefull encoding" of policied sequences of
data globs is not going to work as well as some "statefull encoding" of
policied, and uncorrolated data globs. 

In a sense, we're just revisiting statefull vs stateless encoding design
issues. How much character-set variation do you think there is in some
character stream? Design accordingly. If few transitions relative to the
byte count, go for what amounts to state shifts (and variable byte counts
per character). If many relative to the byte count, consider using fixed
rather than variable byte counts, and accept the "padding" overhead.

How many interesting ways are there to write: don't publish some or all of
my mumble?

Eric

Date: Mon, 17 Mar 2003 14:07:41 -0500
From: janusz sienkiewicz <[email-masked]>
Organization: LibertyRMS Co.
To: Eric Brunner-Williams in Portland Maine <[email-masked]>
CC: Rick Wesson <[email-masked]>, "Hollenbeck, Scott" <[email-masked]>, "'Edward Lewis'" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [ietf-provreg] thursday's meeting
Sender: [email-masked]

Eric Brunner-Williams in Portland Maine wrote:

> > I suspect because the granularity requetsted is for the registrant not the
> > session, where by one session could do many registrations for many more
> > contacts/registrants.
>
> So, in this model, there is p1, p2, p3; three distinct mumbles that have a
> to be defined, but not session-scoped, definition.
>
> A session between e1 and e2, two EPP endpoints, which transports d1, d2, d3,
> three distinct EPP datums, is:
>
>         e1: session-open; send d1:p1; send d2:p2; send d3:p3; session-close
>         e2: ack, ack, ack, ack (sort of like the Martians in "Mars Attacks")
>
> If so, then while data exhibits a property close to global uniqness within
> each glob of data, the value for the set {p1, p2, p3, ...} may have a much
> smaller cardinality. Somewhere less than 42 seems likely.
>
> If so, then connections should resemble something like this:
>
>         send d1:p1, send d2:p1, send d3:p1 .... send dN:p1 \
>         send dN+1:p2 send dN+2:p1, send dN+3:p1 .... send dN+M:p1
>

Shouldn't  "send dN+2:p1, send dN+3:p1 .... send dN+M:p1" have p3 instead of
p1?

>
> for non-trivial sequences of sequentially identical values of p.
>
> Rewritten, to show policy-scoped sequences of data:
>
>         p1{d1, d2, ... dN}, p2{dN+1}, p1{dN+2, dN+3, ... dN+M}
>

>
> And that looks reasonably amenable to this
>
>         s1{p1{d1, d2, ... dN}}, s2{p2{dN+1}}, s3{p1{dN+2, dN+3, ... dN+M}}
>
> or three sessions, each with an associated single policy on all data.
>
> Operationally, we haven't precluded server operators from assigning well
> known values of p to ports, so that in practice, the above would be three
> distinct connections.
>
> We also haven't precluded server operators from cycling through a set of
> well known values of p whenever the server observes a session-end sent
> by a client, followed by a session-begin.
>
> We could of course add some mechanism for client and server to "dual" with
> <dcp> values, until "trained", but until someone starts putting values for
> p down, we don't actually know if the size of the p value-space is as big
> as 42, or as small as two, or three, or four meaningfully distinct values.
>
> Eric
>
> P.S. I'm having way too much fun with the symbolic general nonsense. The
> proponant(s) of mumble need to attempt to be concret, soon.

Janusz Sienkiewicz

To: Rick Wesson <[email-masked]>
cc: Eric Brunner-Williams in Portland Maine <[email-masked]>, "Hollenbeck, Scott" <[email-masked]>, "'Edward Lewis'" <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: [ietf-provreg] thursday's meeting 
Date: Mon, 17 Mar 2003 13:22:40 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

> I suspect because the granularity requetsted is for the registrant not the
> session, where by one session could do many registrations for many more
> contacts/registrants.

So, in this model, there is p1, p2, p3; three distinct mumbles that have a
to be defined, but not session-scoped, definition.

A session between e1 and e2, two EPP endpoints, which transports d1, d2, d3,
three distinct EPP datums, is:

	e1: session-open; send d1:p1; send d2:p2; send d3:p3; session-close
	e2: ack, ack, ack, ack (sort of like the Martians in "Mars Attacks")

If so, then while data exhibits a property close to global uniqness within
each glob of data, the value for the set {p1, p2, p3, ...} may have a much
smaller cardinality. Somewhere less than 42 seems likely.

If so, then connections should resemble something like this:

	send d1:p1, send d2:p1, send d3:p1 .... send dN:p1 \
	send dN+1:p2 send dN+2:p1, send dN+3:p1 .... send dN+M:p1  

for non-trivial sequences of sequentially identical values of p.

Rewritten, to show policy-scoped sequences of data:

	p1{d1, d2, ... dN}, p2{dN+1}, p1{dN+2, dN+3, ... dN+M}

And that looks reasonably amenable to this

	s1{p1{d1, d2, ... dN}}, s2{p2{dN+1}}, s3{p1{dN+2, dN+3, ... dN+M}}

or three sessions, each with an associated single policy on all data.

Operationally, we haven't precluded server operators from assigning well
known values of p to ports, so that in practice, the above would be three
distinct connections.

We also haven't precluded server operators from cycling through a set of
well known values of p whenever the server observes a session-end sent
by a client, followed by a session-begin.

We could of course add some mechanism for client and server to "dual" with
<dcp> values, until "trained", but until someone starts putting values for
p down, we don't actually know if the size of the p value-space is as big
as 42, or as small as two, or three, or four meaningfully distinct values.

Eric

P.S. I'm having way too much fun with the symbolic general nonsense. The
proponant(s) of mumble need to attempt to be concret, soon.

Date: Mon, 17 Mar 2003 09:21:56 -0800 (PST)
From: Rick Wesson <[email-masked]>
To: Eric Brunner-Williams in Portland Maine <[email-masked]>
cc: "Hollenbeck, Scott" <[email-masked]>, "'Edward Lewis'" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: [ietf-provreg] thursday's meeting 
Sender: [email-masked]

On Mon, 17 Mar 2003, Eric Brunner-Williams in Portland Maine wrote:

> >> Pointing out a specific defect in the <dcp> element's sub-schema would be
> >> really useful.
> >
> > The DCP proposal didn't address how a registrar can tell the registry
> > what can be disclosed. I believe it was the <dnd> proposal that did
> > allow this fine granularity of disclosure.
>
> We don't have a negociation mechanism, for anything.
>
> I don't mind adding one.
>
> Why is the scope of negociation limited to this however?

I suspect because the granularity requetsted is for the registrant not the
session, where by one session could do many registrations for many more
contacts/registrants.

-rick

To: Rick Wesson <[email-masked]>
cc: Eric Brunner-Williams in Portland Maine <[email-masked]>, "Hollenbeck, Scott" <[email-masked]>, "'Edward Lewis'" <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: [ietf-provreg] thursday's meeting 
Date: Mon, 17 Mar 2003 11:34:20 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

>> Pointing out a specific defect in the <dcp> element's sub-schema would be
>> really useful.
>
> The DCP proposal didn't address how a registrar can tell the registry
> what can be disclosed. I believe it was the <dnd> proposal that did
> allow this fine granularity of disclosure.

We don't have a negociation mechanism, for anything.

I don't mind adding one.

Why is the scope of negociation limited to this however?

Eric

Date: Mon, 17 Mar 2003 08:23:22 -0800 (PST)
From: Rick Wesson <[email-masked]>
To: Eric Brunner-Williams in Portland Maine <[email-masked]>
cc: "Hollenbeck, Scott" <[email-masked]>, "'Edward Lewis'" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: [ietf-provreg] thursday's meeting 
Sender: [email-masked]

On Mon, 17 Mar 2003, Eric Brunner-Williams in Portland Maine wrote:

> > >     Our response to the IESG.  The IESG wants "a standard (as
> > > in the base,
> > >     core spec) means for a registrar to tell a registry what
                                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > can be disclosed
> > >     at fine granularity."

[snip]

> Pointing out a specific defect in the <dcp> element's sub-schema would be
> really useful.

The DCP proposal didn't address how a registrar can tell the registry
what can be disclosed. I believe it was the <dnd> proposal that did
allow this fine granularity of disclosure.

-rick

To: "Hollenbeck, Scott" <[email-masked]>
cc: "'Edward Lewis'" <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: [ietf-provreg] thursday's meeting 
Date: Mon, 17 Mar 2003 11:16:31 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

> >     Our response to the IESG.  The IESG wants "a standard (as 
> > in the base,
> >     core spec) means for a registrar to tell a registry what 
> > can be disclosed
> >     at fine granularity."
> > 
> >     A means to avoid host objects.
> 
> We have really got to get a grip on the first item.  I thought we were past
> this as of last week, and here we are again.  There's clearly a
> communications issue somewhere...

I agree.

Either a
	session-scope mechanism, which incidently is independent of 
	syntax and schema (it could be morphed into EBNF if RRP has
	not yet reached its sell-by date),
or a
	base schema mechanism, dependent upon syntax and schema, and
	independent of "session" (aka, "privacy" is a property of
	syntax representations, and transport independent, even if it
	is not transported),
or a
	mechanism which subsets the base schema, and constructs some
	syntax and semantics from some subset, and is also independent
	of "session" (see above, and add complexity for subseting in
	general).

That should read as a switch statement, with no fall-through.

Pointing out a specific defect in the <dcp> element's sub-schema would be
really useful.

Eric

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Edward Lewis'" <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: RE: [ietf-provreg] thursday's meeting
Date: Mon, 17 Mar 2003 08:39:46 -0500
Sender: [email-masked]

> As one might imagine, the agenda is going to be a bit flexible.
> 
> Besides the published agenda, I'd like folks to be prepared to also 
> discuss these items:
> 
>     Our response to the IESG.  The IESG wants "a standard (as 
> in the base,
>     core spec) means for a registrar to tell a registry what 
> can be disclosed
>     at fine granularity."
> 
>     A means to avoid host objects.

We have really got to get a grip on the first item.  I thought we were past
this as of last week, and here we are again.  There's clearly a
communications issue somewhere...

I would hope that whomever wishes to bring up the "avoid host objects" topic
plans to introduce information that hasn't already been talked to death on
the mailing list at multiple times in the past.

-Scott-

Date: Sun, 16 Mar 2003 21:05:56 -0800
To: [email-masked]
From: Edward Lewis <[email-masked]>
Subject: [ietf-provreg] thursday's meeting
Cc: [email-masked], [email-masked]
Sender: [email-masked]

As one might imagine, the agenda is going to be a bit flexible.

Besides the published agenda, I'd like folks to be prepared to also 
discuss these items:

    Our response to the IESG.  The IESG wants "a standard (as in the base,
    core spec) means for a registrar to tell a registry what can be disclosed
    at fine granularity."

    A means to avoid host objects.

I've heard from a few folks that these topics warrant further 
discussion.  I invite those who have been talking to me directly to 
send words to the list to spur discussion.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

Date: Sat, 15 Mar 2003 14:33:59 -0500
Subject: [ietf-provreg] ISC OpenReg 1.0.1 Release
From: Joe Abley <[email-masked]>
To: [email-masked]
Sender: [email-masked]

[this message is being copied to multiple mailing lists; apologies in 
advance for duplicates]

The Internet Software Consortium is pleased to announce the first 
public release of OpenReg, an implementation of a DNS Shared Registry 
System which supports the Extensible Provisioning Protocol (EPP).

For more information, and to download OpenReg, please see:

   http://www.isc.org/products/OpenReg/

OpenReg is free software, released under a BSD-style licence.

From: "Ram Mohan" <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>, <[email-masked]>
Subject: Re: [ietf-provreg] Summary of IESG Comments and Disposition
Date: Wed, 12 Mar 2003 02:20:53 -0500
Organization: Afilias
Sender: [email-masked]

Scott,
Thanks - good work!

-ram
----- Original Message -----
From: "Hollenbeck, Scott" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, March 11, 2003 9:49 AM
Subject: [ietf-provreg] Summary of IESG Comments and Disposition

> This note describes the IESG review comments that we've received and
> addressed in the most recent versions of the EPP specifications.  Here are
> the references to the current documents:
>
> http://www.verisignlabs.com/draft-ietf-provreg-epp-09.txt
> I just finished this version today.  This is a temporary location until
the
> document is announced by the Internet-Drafts administrator after the San
> Francisco meeting.
>
> http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-contact-06.txt
>
> http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-domain-06.txt
>
> http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-host-06.txt
>
> http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-tcp-06.txt
>
> Here are the references to the IESG comments along with a description of
> what was done to address them:
>
> http://www.cafax.se/ietf-provreg/maillist/2002-10/msg00023.html
>
> 1. <draft-ietf-provreg-epp-07.txt>
> Do we put mailing list names and URLs in RFCs?
>
> RESOLUTION: The paragraph describing the mailing list and archives has
been
> removed.
>
> 2. I'd like a stronger Security Considerations section, though I think it
> can be added by an RFC Editor note.  In particular, I want it to say that
> EPP "MUST NOT be used over a transport mechanism that does not provide
> confidentiality", or "All transport mappings for EPP MUST provide
> confidentiality and integrity".  (I think that that's what they intend,
but
> it's not clear enough.)
>
> RESOLUTION: The text has been changed to read "EPP instances MUST be
> protected using a transport mechanism or application protocol that
provides
> integrity and confidentiality".
>
> 3. <draft-ietf-provreg-epp-domain-05.txt>
> What is an "authorization token"?  It's not defined, but it's mandated by
> the security considerations.  (I suspect it's what is discussed in 2.6,
but
> it doesn't use the same words.)
>
> RESOLUTION: The text describing an "authorization token" has been changed
to
> use the same "authorization information" term described in section 2.6.
>
> 4. <draft-ietf-provreg-epp-contact-05.txt>
> What is an "authorization token"?  It's not defined, but it's mandated by
> the security considerations.  (I suspect it's what is discussed in 2.8,
but
> it doesn't use the same words.)
>
> RESOLUTION:  The text describing an "authorization token" has been changed
> to use the same "authorization information" term described in section 2.8.
>
> 5. <draft-ietf-provreg-epp-tcp-05.txt>
> The Security Considerations section seems to require TLS client
> authentication, which in turn requires client certificates. Is this
> intended?  If so, great!  But in that case, what is the fate, if any, of
the
> EPP login/password command?  Is it still needed?  Is it still legal?  What
> does it mean?  Must the identities agree? (The requirement for server
> authentication is excellent, but some more text mentioning the need to
> validate the certificate chain is probably a good idea.)
>
> RESOLUTION: The Security Considerations section has been modified to
> explicitly note the need to validate the certificate chain.  The
> certificates used for TLS authentication authenticate the client and
server
> machines involved in the provisioning exchange.  The EPP login
functionality
> is still needed, though, as it provides a facility to authenticate client
> user identities so that the server can make access control and
authorization
> decisions based on the identity of the client, in addition to the identity
> of the machine the client is using to communicate with the server.
>
> 6. <draft-ietf-provreg-epp-07.txt> sec 2.1
> I think it would be good to be a bit more strict about the use of
congestion
> control protocols specifically require the use of an IETF standards track
> congestion control protocol such as TCP or SCTP
>
>        i.e. change the following line:
>        - The transport mapping MUST manage congestion.
>
>        to:
>        - The transport mapping MUST only be to an IETF standards
>        track congestion control protocol such as TCP or SCTP.
>
> RESOLUTION: Section 2.1 has been modified to read as follows:
>
> "- The transport mapping MUST be onto a transport such as TCP [RFC793] or
> SCTP [RFC2960] that provides congestion avoidance that follows RFC 2914
> [RFC2914], or if it maps onto a protocol such as SMTP [RFC2821] or BEEP
> [RFC3080], then the performance issues need to take into account issues of
> overload, server availability and so forth."
>
> 7. <draft-ietf-provreg-epp-07.txt>
> page 12, example greeting has:
>
>      S: <svID>Example EPP server epp.example.tld</svID>
>
> in an example greeting. Did we not decide at some point that examples
should
> be of the form: epp.example.org ??
>
> RESOLUTION: All examples in all documents have been changed to use the
> example domain names (example.com, example.net, and example.org) described
> in RFC 2606.  Sample IPv4 addresses have been changed to use the Test-Net
> address block listed in RFC 3330.
>
> 8. why do domain/contact/.. not have granular information about privacy?
>
> RESOLUTION: This comment has been addressed through a very lengthy
> discussion process that resulted in making the existing <dcp> element
> mandatory.  This change is reflected in a new version of the core protocol
> document that can be seen at the temporary URL provided at the top of this
> message.  The formal announcement will be made after the San Francisco
IETF
> meeting.
>
> http://www.cafax.se/ietf-provreg/maillist/2002-10/msg00049.html
>
> 1. The transport mapping MUST manage congestion.
>
> RESOLUTION: See the resolution for item 6 above.
>
> http://www.cafax.se/ietf-provreg/maillist/2002-10/msg00114.html
>
> <draft-ietf-provreg-epp-07.txt>
> 1. The transport mapping MUST manage congestion.
>
> RESOLUTION: See the resolution for item 6 above.
>
> 2. Within the optional dcp (data collection policy) element: there is a
> non-technical spin in at least the following label definition, what kind
of
> marketing is meant?
>
>   <contact/>: Contact for marketing purposes.
>
> Please add more to this definition so that is more neutral in in its
> terminology.
>
> RESOLUTION: The description of this element has been changed as follows:
>
> "<contact/>: Contact for marketing purposes.  Information can be used to
> contact individuals, through a communications channel other than the
> protocol, for the promotion of a product or service.".
>
> 3. How does IESG and the community check the extensive XML in a
> specification like this (analogous to the ABNF and MIB checking described
> that is done regularly...)?  How did you check what's here?  Why might it
> not matter?
>
> RESOLUTION: Syntax checking matters.  There are a variety of freely
> available XML syntax checking utilities, such as the Xerces XML parser
> written in Java, that can be used to validate all of the schemas and
> examples provided in the documents.  The normative schemas can be copied
> from the documents, edited to remove page headers and footers, and pasted
> together to create the formal syntax specifications for the protocol.
> Examples can be copied from the documents, edited to remove the "C:" and
> "S:" line prefixes, and pasted together to create a set of sample
instances
> of the protocol.  Scott Hollenbeck has also published external files
> containing all of the examples and schemas in two public places:
>
> ftp://ftp.verisign.com/pub/epp/
>
> http://www.verisign-grs.com/files/
>
> Other WG members are mirroring these file collections to provide
additional
> redundancy.  The examples and schemas can be run through an up-to-date
> validating XML parser to confirm validity.  As part of the normal document
> editing process, Scott has been running all of the examples and schemas
> through the Xerces-J parser to confirm that everything remains valid
> according to the current W3C XML Schema specifications.
>
> <draft-ietf-provreg-epp-tcp-05.txt>
> 1. "An EPP client streams EPP commands to an EPP server on an established
> TCP connection.  A client MAY establish multiple TCP connections to create
> multiple command exchange channels.  A server MAY limit a client to a
> maximum number of TCP connections based on server capabilities and
> operational load."
>
> It is not a good thing for the net for services to choose this approach.
A
> MAY like this is problematic for congestion control reasons.  I would like
> to change this language from "MAY establish" to "MAY but SHOULD NOT" and
> from "A server MAY limit" to "A server SHOULD limit"
>
> RESOLUTION: Text changed as requested.
>
> 2. For references to TCP, besides RFC 793, you need: RFC 2581, 2914
>
> RESOLUTION: References added.
>
> That's it!  I'll try to have the updated EPP schema and example package
> (none of the examples changed) uploaded to the public locations as quickly
> as possible.
>
> -Scott-
>

Date: Tue, 11 Mar 2003 08:50:12 -0800
To: "Hollenbeck, Scott" <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: Re: [ietf-provreg] Summary of IESG Comments and Disposition
Cc: "[email-masked]'" <[email-masked]>
Sender: [email-masked]

Scott, thanks.  I will forward the message to the IESG now (without 
cc'ing the list as we've all seen the text once here ;)).

At 9:49 -0500 3/11/03, Hollenbeck, Scott wrote:
>This note describes the IESG review comments that we've received and
>addressed in the most recent versions of the EPP specifications.  Here are
>the references to the current documents:

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

From: "Hollenbeck, Scott" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: [ietf-provreg] Summary of IESG Comments and Disposition
Date: Tue, 11 Mar 2003 09:49:12 -0500
Importance: high
Sender: [email-masked]

This note describes the IESG review comments that we've received and
addressed in the most recent versions of the EPP specifications.  Here are
the references to the current documents:

http://www.verisignlabs.com/draft-ietf-provreg-epp-09.txt
I just finished this version today.  This is a temporary location until the
document is announced by the Internet-Drafts administrator after the San
Francisco meeting.

http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-contact-06.txt

http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-domain-06.txt

http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-host-06.txt

http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-tcp-06.txt

Here are the references to the IESG comments along with a description of
what was done to address them:

http://www.cafax.se/ietf-provreg/maillist/2002-10/msg00023.html

1. <draft-ietf-provreg-epp-07.txt>
Do we put mailing list names and URLs in RFCs?

RESOLUTION: The paragraph describing the mailing list and archives has been
removed.

2. I'd like a stronger Security Considerations section, though I think it
can be added by an RFC Editor note.  In particular, I want it to say that
EPP "MUST NOT be used over a transport mechanism that does not provide
confidentiality", or "All transport mappings for EPP MUST provide
confidentiality and integrity".  (I think that that's what they intend, but
it's not clear enough.)

RESOLUTION: The text has been changed to read "EPP instances MUST be
protected using a transport mechanism or application protocol that provides
integrity and confidentiality".

3. <draft-ietf-provreg-epp-domain-05.txt>
What is an "authorization token"?  It's not defined, but it's mandated by
the security considerations.  (I suspect it's what is discussed in 2.6, but
it doesn't use the same words.)

RESOLUTION: The text describing an "authorization token" has been changed to
use the same "authorization information" term described in section 2.6.

4. <draft-ietf-provreg-epp-contact-05.txt>
What is an "authorization token"?  It's not defined, but it's mandated by
the security considerations.  (I suspect it's what is discussed in 2.8, but
it doesn't use the same words.)

RESOLUTION:  The text describing an "authorization token" has been changed
to use the same "authorization information" term described in section 2.8.

5. <draft-ietf-provreg-epp-tcp-05.txt>
The Security Considerations section seems to require TLS client
authentication, which in turn requires client certificates. Is this
intended?  If so, great!  But in that case, what is the fate, if any, of the
EPP login/password command?  Is it still needed?  Is it still legal?  What
does it mean?  Must the identities agree? (The requirement for server
authentication is excellent, but some more text mentioning the need to
validate the certificate chain is probably a good idea.)

RESOLUTION: The Security Considerations section has been modified to
explicitly note the need to validate the certificate chain.  The
certificates used for TLS authentication authenticate the client and server
machines involved in the provisioning exchange.  The EPP login functionality
is still needed, though, as it provides a facility to authenticate client
user identities so that the server can make access control and authorization
decisions based on the identity of the client, in addition to the identity
of the machine the client is using to communicate with the server.

6. <draft-ietf-provreg-epp-07.txt> sec 2.1
I think it would be good to be a bit more strict about the use of congestion
control protocols specifically require the use of an IETF standards track
congestion control protocol such as TCP or SCTP

       i.e. change the following line:
       - The transport mapping MUST manage congestion.

       to:
       - The transport mapping MUST only be to an IETF standards
       track congestion control protocol such as TCP or SCTP.

RESOLUTION: Section 2.1 has been modified to read as follows:

"- The transport mapping MUST be onto a transport such as TCP [RFC793] or
SCTP [RFC2960] that provides congestion avoidance that follows RFC 2914
[RFC2914], or if it maps onto a protocol such as SMTP [RFC2821] or BEEP
[RFC3080], then the performance issues need to take into account issues of
overload, server availability and so forth."

7. <draft-ietf-provreg-epp-07.txt>
page 12, example greeting has:

     S: <svID>Example EPP server epp.example.tld</svID>

in an example greeting. Did we not decide at some point that examples should
be of the form: epp.example.org ??

RESOLUTION: All examples in all documents have been changed to use the
example domain names (example.com, example.net, and example.org) described
in RFC 2606.  Sample IPv4 addresses have been changed to use the Test-Net
address block listed in RFC 3330.

8. why do domain/contact/.. not have granular information about privacy?

RESOLUTION: This comment has been addressed through a very lengthy
discussion process that resulted in making the existing <dcp> element
mandatory.  This change is reflected in a new version of the core protocol
document that can be seen at the temporary URL provided at the top of this
message.  The formal announcement will be made after the San Francisco IETF
meeting.

http://www.cafax.se/ietf-provreg/maillist/2002-10/msg00049.html

1. The transport mapping MUST manage congestion.

RESOLUTION: See the resolution for item 6 above.

http://www.cafax.se/ietf-provreg/maillist/2002-10/msg00114.html

<draft-ietf-provreg-epp-07.txt>
1. The transport mapping MUST manage congestion.

RESOLUTION: See the resolution for item 6 above.

2. Within the optional dcp (data collection policy) element: there is a
non-technical spin in at least the following label definition, what kind of
marketing is meant?

  <contact/>: Contact for marketing purposes.

Please add more to this definition so that is more neutral in in its
terminology.

RESOLUTION: The description of this element has been changed as follows:

"<contact/>: Contact for marketing purposes.  Information can be used to
contact individuals, through a communications channel other than the
protocol, for the promotion of a product or service.".

3. How does IESG and the community check the extensive XML in a
specification like this (analogous to the ABNF and MIB checking described
that is done regularly...)?  How did you check what's here?  Why might it
not matter?

RESOLUTION: Syntax checking matters.  There are a variety of freely
available XML syntax checking utilities, such as the Xerces XML parser
written in Java, that can be used to validate all of the schemas and
examples provided in the documents.  The normative schemas can be copied
from the documents, edited to remove page headers and footers, and pasted
together to create the formal syntax specifications for the protocol.
Examples can be copied from the documents, edited to remove the "C:" and
"S:" line prefixes, and pasted together to create a set of sample instances
of the protocol.  Scott Hollenbeck has also published external files
containing all of the examples and schemas in two public places:

ftp://ftp.verisign.com/pub/epp/

http://www.verisign-grs.com/files/

Other WG members are mirroring these file collections to provide additional
redundancy.  The examples and schemas can be run through an up-to-date
validating XML parser to confirm validity.  As part of the normal document
editing process, Scott has been running all of the examples and schemas
through the Xerces-J parser to confirm that everything remains valid
according to the current W3C XML Schema specifications.

<draft-ietf-provreg-epp-tcp-05.txt>
1. "An EPP client streams EPP commands to an EPP server on an established
TCP connection.  A client MAY establish multiple TCP connections to create
multiple command exchange channels.  A server MAY limit a client to a
maximum number of TCP connections based on server capabilities and
operational load."

It is not a good thing for the net for services to choose this approach.  A
MAY like this is problematic for congestion control reasons.  I would like
to change this language from "MAY establish" to "MAY but SHOULD NOT" and
from "A server MAY limit" to "A server SHOULD limit"

RESOLUTION: Text changed as requested.

2. For references to TCP, besides RFC 793, you need: RFC 2581, 2914

RESOLUTION: References added.

That's it!  I'll try to have the updated EPP schema and example package
(none of the examples changed) uploaded to the public locations as quickly
as possible.

-Scott-

Date: Tue, 11 Mar 2003 15:32:24 +0100
From: Otmar Lendl <[email-masked]>
To: [email-masked]
Subject: [ietf-provreg] EPP/TCP server testing tools
Sender: [email-masked]

As I'm in the process of polishing and testing my mod_epp (EPP as Apache
2.0 module) EPP/TCP implementation [1], I'm wondering if anybody has already
done some work concerning server testing software.

All the client toolkits are nice and fine for testing the EPP backend
logic, but right now I'm much more interested in the EPP/TCP layer.

For example: Wrong framing, arbitrary delays between header and the
XML, pipelining, DoS, TCP/out-of-band, refusing to read answers, ...

Can anybody share code which does these tests?

/ol

[1] http://sourceforge.net/projects/aepps/
    (for current code see CVS.)

To: [email-masked]
Subject: Re: [ietf-provreg] URL element in contact mapping
From: Hideki Noma <[email-masked]>
Date: Tue, 11 Mar 2003 12:26:24 +0900
Sender: [email-masked]

Thank you for responding.

Sorry for late action.

How about this kind of element.

<contact:url>https://ssl.d4u.jp/Contact.cgi</contact:url>

or in case there needs some distinction on which type of url;
(like as whois offered by whois.internic.net)

<contact:url type="web">https://ssl.d4u.jp/Contact.cgi</contact:url>
<contact:url type="whois">whois.internic.net</contact:url>

this should serve fine.

Adding url parameter might help in solving the privacy issue as
offering another means to contact the registrant, don't you think so?

Hideki Noma
Humeia Limited Partnership

> The WG (which is the mailing list) has not heard of this before, so 
> we are unable to send you a reference.
> 
> We would appreciate more information on this topic so that the 
> protocol is capable of handling all it needs to handle.
> 
> 
> At 12:37 +0900 3/4/03, Hideki Noma wrote:
> >Hello,
> >
> >There will be a URL element introduced in .JP contact information in 
> >near future.
> >And I beleive that some sort of element representing a URL of domain 
> >owner or contact
> >is necessary.In fact whois.internic.net has both url element of 
> >whois server and
> >web server.
> >
> >I understand that url element should be optional or even, extention 
> >implemented by registrars,
> >however the element name must be standardized. I don't know why JP 
> >registry is not commenting on
> >this but as one of JP registrar, I strongly request it.
> >
> >If there has been a discussion around this topic I've missed it, 
> >please point me
> >where to look at.
> >
> >Hideki Noma
> >Humeia Limited Partnership
> 
> -- 
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Edward Lewis                                          +1-703-227-9854
> ARIN Research Engineer
> 
> 

Date: Mon, 10 Mar 2003 11:18:52 -0800
To: Eric Brunner-Williams in Portland Maine <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: Re: [ietf-provreg] Re: provreg's privacy issue
Cc: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?=  <[email-masked]>, Edward Lewis <[email-masked]>, Ted Hardie <[email-masked]>, Ned Freed <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

At 13:50 -0500 3/10/03, Eric Brunner-Williams in Portland Maine wrote:
>I guess I missed Allison's note. It wasn't the one in reply to Rick, right?

http://www.cafax.se/ietf-provreg/maillist/2002-10/msg00114.html

(Is that what you need?)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[email-masked]>
cc: Edward Lewis <[email-masked]>, Ted Hardie <[email-masked]>, Ned Freed <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [ietf-provreg] Re: provreg's privacy issue 
Date: Mon, 10 Mar 2003 13:50:10 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

I guess I missed Allison's note. It wasn't the one in reply to Rick, right?

Date: Mon, 10 Mar 2003 10:46:49 -0800
To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?=  <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: [ietf-provreg] Re: provreg's privacy issue
Cc: Edward Lewis <[email-masked]>, Ted Hardie <[email-masked]>, Ned Freed <[email-masked]>, [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

At 19:15 +0100 3/10/03, Patrik Fältström wrote:
>On måndag, mar 10, 2003, at 17:08 Europe/Stockholm, Edward Lewis wrote:
>
>>  Returning to the IESG review of these documents sometime around October, we
>>feel that we have addressed all of the comments now.
>
>Also the one from Allison which sort of disappeared in the flurry of other
>discussions?

We 'think' we addressed that issue long ago, the answer to it should 
already be in the specs in the repository.

Perhaps it would be good to prepare a summary of answers to the IESG comments.

>>  As soon as the new documents hit the repository, we ask that the IESG
>>resume its review of the specifications.
>
>Thanks!
>
>   paf

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

From: "Hollenbeck, Scott" <[email-masked]>
To: =?iso-8859-1?Q?=27Patrik_F=E4ltstr=F6m=27?= <[email-masked]>, Edward Lewis <[email-masked]>
Cc: Ted Hardie <[email-masked]>, Ned Freed <[email-masked]>, [email-masked], [email-masked]
Subject: [ietf-provreg] RE: provreg's privacy issue
Date: Mon, 10 Mar 2003 13:32:19 -0500
Sender: [email-masked]

> On måndag, mar 10, 2003, at 17:08 Europe/Stockholm, Edward 
> Lewis wrote:
> 
> > Returning to the IESG review of these documents sometime around 
> > October, we feel that we have addressed all of the comments now.
> 
> Also the one from Allison which sort of disappeared in the flurry of 
> other discussions?

Yes -- the documents that are currently available were modified to address
all of Allison's comments.

-Scott-

Date: Mon, 10 Mar 2003 19:15:21 +0100
Subject: [ietf-provreg] Re: provreg's privacy issue
Cc: Ted Hardie <[email-masked]>, Ned Freed <[email-masked]>, [email-masked], [email-masked], [email-masked]
To: Edward Lewis <[email-masked]>
From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[email-masked]>
Sender: [email-masked]

On måndag, mar 10, 2003, at 17:08 Europe/Stockholm, Edward Lewis wrote:

> Returning to the IESG review of these documents sometime around 
> October, we feel that we have addressed all of the comments now.

Also the one from Allison which sort of disappeared in the flurry of 
other discussions?

> As soon as the new documents hit the repository, we ask that the IESG 
> resume its review of the specifications.

Thanks!

   paf

Date: Mon, 10 Mar 2003 08:08:29 -0800
To: [email-masked], Ted Hardie <[email-masked]>, Ned Freed <[email-masked]>, [email-masked]
From: Edward Lewis <[email-masked]>
Subject: [ietf-provreg] provreg's privacy issue
Cc: [email-masked], [email-masked]
Sender: [email-masked]

In response to the IESG comment:

     why do domain/contact/.. not have granular information about privacy?

The provreg WG has apparently reached consensus upon this suggestion:

     That being the case, my preference would be to put _all_ of the DNP
     syntax and semantics into an extension (where the problem can be
     addressed as a whole) while making the existing DCP element mandatory
     if that resolves the privacy issue with the IESG.

For the WG, Scott Hollenbeck will make the necessary changes to the 
base specification to reflect this consensus.  (Scott: please do this 
as soon as you get the chance.[0])  It would help the IESG to see the 
formalized text based on this.

Returning to the IESG review of these documents sometime around 
October, we feel that we have addressed all of the comments now.  As 
soon as the new documents hit the repository, we ask that the IESG 
resume its review of the specifications.

[0] Yeah, I realize that drafts submissions are being held up until 
after the IETF meeting week.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

Date: Mon, 10 Mar 2003 08:47:17 -0800
To: [email-masked], [email-masked]
From: Edward Lewis <[email-masked]>
Subject: [ietf-provreg] provreg agenda for SF
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Provreg: Thursday, March 20, 9-11:30

1. Agenda Bashing

2. WG status (where we are document-wise)

3. Current status of the IESG review
      draft-ietf-provreg-epp-08.txt
      draft-ietf-provreg-epp-contact-06.txt
      draft-ietf-provreg-epp-domain-06.txt
      draft-ietf-provreg-epp-host-06.txt
      draft-ietf-provreg-epp-tcp-06.txt

4. Extending EPP document
      draft-ietf-provreg-epp-ext-00.txt

5. Other issues with the Base Spec
      Issues have been raised and mostly dropped over the past few months.
      No issue to date seems to have generated enough interest to halt
      publication as a Proposed Standard.
      (Speak now or hold your peace until Draft Standard.)

6. Other Transports
      This is in our charter, proposals to do this pop up, but no effort has
      been sustained.

7. Special Request: IDN in EPP
      A request to discuss this has been made.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

From: "Ram Mohan" <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>, "'Edward Lewis'" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: Re: [ietf-provreg] Fwd: Re: provreg milestones
Date: Fri, 7 Mar 2003 15:35:59 -0500
Organization: Afilias
Sender: [email-masked]

agreed, both personally and for the .info registry.

-ram
----- Original Message ----- 
From: "Hollenbeck, Scott" <[email-masked]>
To: "'Edward Lewis'" <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, March 07, 2003 7:23 AM
Subject: RE: [ietf-provreg] Fwd: Re: provreg milestones

> > Also to the group - as far as the privacy thing being resolved, I'm a 
> > bit hesitant to declare consensus yet to the proposal in:
> > 
> > # From: "Hollenbeck, Scott" <[email-masked]>
> > # Date: Mon, 3 Mar 2003 13:02:34 -0500
> > #
> > # As far as .com is concerned, I have no doubt that an 
> > extension will be
> > # required even if we were to adopt the IESG's element 
> > tagging suggestion.
> > # That being the case, my preference would be to put _all_ of 
> > the DNP syntax
> > # and semantics into an extension (where the problem can be 
> > addressed as a
> > # whole) while making the existing DCP element mandatory if 
> > that resolves the
> > # privacy issue with the IESG.
> > 
> > (Aka - 
> > http://www.cafax.se/ietf-provreg/maillist/2003-03/msg00010.html)
> > 
> > So let me hear about that...
> 
> Ed, please note these supporting comments sent prior to your note:
> 
> http://www.cafax.se/ietf-provreg/maillist/2003-03/msg00015.html
> 
> http://www.cafax.se/ietf-provreg/maillist/2003-03/msg00023.html
> 
> -Scott-
> 

From: "Liu, Hong" <[email-masked]>
To: "'Edward Lewis'" <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: RE: [ietf-provreg] Fwd: Re: provreg milestones
Date: Fri, 7 Mar 2003 12:56:19 -0500 
Sender: [email-masked]

Ed,

I think Scott's proposal is a reasonable one going forward. I will support
it.

--Hong

-----Original Message-----
From: Edward Lewis [mailto:[email-masked]]
Sent: Thursday, March 06, 2003 4:38 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [ietf-provreg] Fwd: Re: provreg milestones

Also to the group - as far as the privacy thing being resolved, I'm a 
bit hesitant to declare consensus yet to the proposal in:

# From: "Hollenbeck, Scott" <[email-masked]>
# Date: Mon, 3 Mar 2003 13:02:34 -0500
#
# As far as .com is concerned, I have no doubt that an extension will be
# required even if we were to adopt the IESG's element tagging suggestion.
# That being the case, my preference would be to put _all_ of the DNP syntax
# and semantics into an extension (where the problem can be addressed as a
# whole) while making the existing DCP element mandatory if that resolves
the
# privacy issue with the IESG.

(Aka - http://www.cafax.se/ietf-provreg/maillist/2003-03/msg00010.html)

So let me hear about that...

>Date: Thu, 6 Mar 2003 21:48:31 +0100
>Subject: Re: provreg milestones
>Cc: [email-masked], Ted Hardie <[email-masked]>
>To: Edward Lewis <[email-masked]>
>From: Patrik Fältström <[email-masked]>
>X-OriginalArrivalTime: 06 Mar 2003 20:48:37.0518 (UTC) 
>FILETIME=[C2ED4AE0:01C2E421]
>Status:
>
>This looks good.
>
>Please send the new milestones to [email-masked].
>
>I also understand the privacy thing is now resolved. I saw a few 
>messages on the mailing list about it.
>
>May I suggest you (or someone) write a summary of what the solution 
>is, and send it to me, randy, allison (and also cc Ned and Ted as 
>co-AD's -- yes, Ted is formally not onboard, but anyway). You can of 
>course also cc the mailing list if you want to.
>
>     paf
>
>On torsdag, mar 6, 2003, at 16:59 Europe/Stockholm, Edward Lewis wrote:
>
>>  I've heard no response to this from 'above.'
>>
>>  The FEB 03 milestone now should be MAR 03 I guess.
>>
>>>  Date: Fri, 31 Jan 2003 10:14:40 -0500
>>>  To: [email-masked], [email-masked]
>>>  From: Edward Lewis <[email-masked]>
>>>  Subject: provreg milestones
>>>  Cc: [email-masked], [email-masked]
>>>  Bcc:
>>>  X-Attachments:
>>>
>>>  While we still have an open issue with regards to privacy, I want 
>>>to move on and at least refresh the group's milestones.
>>>
>>>  FEB 03 Respond to the IESG Comments (for Proposed)
>>>  MAR 03 Submit Guidelines for Extending the EPP to IESG (Informational)
>>>  APR 03 Decision on Alternate Transports
>>>  SEP 03 Perform Interoperability Tests
>>>  OCT 03 Submit Interoperability Report to IESG (Informational)
>>>  OCT 03 Submit Extensible Provisioning Protocol to IESG (Draft)
>>>  OCT 03 Submit EPP Contact Mapping to IESG (Draft)
>>>  OCT 03 Submit EPP Domain Name Mapping to IESG (Draft)
>>>  OCT 03 Submit EPP Host Mapping to IESG (Draft)
>>>  OCT 03 Submit EPP Transport Over TCP to IESG (Draft)
>>>
>>>  Look these over carefully.  I added the first because we haven't 
>>>closed that off, as well as having some potential threads to cover 
>>>in addition to the privacy question.
>>>
>>>  A "Decision on Alternate Transports" is on there because our 
>>>charter talks about  "support for multiple operational choices, 
>>>such as for transport".  At times support has been expressed for 
>>>BEEP, SMTP, and SOAP, but none have garnered much support.  My 
>>>vague opinion is that alternate transports will need to come with 
>>>code, not just documents, before they can be taken seriously by 
>>>the WG.
>>>
>>>  Note that SMTP and SOAP milestones are not on there.  Not to 
>>>denigrate the work, but they haven't made it to general interest 
>>>for the WG.
>>>
>>>  With this message I am asking our AD to approve these milestones, 
>>>we can adjust them as necessary.
>>
>>  -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>>  Edward Lewis                                          +1-703-227-9854
>>  ARIN Research Engineer
>>
>
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

Date: Fri, 07 Mar 2003 10:42:32 -0500
From: janusz sienkiewicz <[email-masked]>
Organization: LibertyRMS Co.
To: "Hollenbeck, Scott" <[email-masked]>
CC: "[email-masked]'" <[email-masked]>
Subject: Re: [ietf-provreg] FYI: EPP implementation by the Polish registry
Sender: [email-masked]

"Hollenbeck, Scott" wrote:

> > >Does ((dnp==1 at .nl) == (dnp==1 at .com)) semantically
> > evaluate to 1, or 0?
> >
> > The answer to this is a determining factor (to me at least) of
> > whether $dnp is in the base specification or in an extension.
>
> As far as .com is concerned, I have no doubt that an extension will be
> required even if we were to adopt the IESG's element tagging suggestion.
> That being the case, my preference would be to put _all_ of the DNP syntax
> and semantics into an extension (where the problem can be addressed as a
> whole) while making the existing DCP element mandatory if that resolves the
> privacy issue with the IESG.

Making existing DCP element mandatory and dealing with other specific privacy
requirements within extensions looks to me like a better way of addressing
privacy issues in EPP protocol than mandatory, binary DNP attribute.

> -Scott-

Janusz Sienkiewicz

To: Edward Lewis <[email-masked]>
cc: Eric Brunner-Williams in Portland Maine <[email-masked]>, Andrew Newton <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [ietf-provreg] proto-agenda 
Date: Fri, 07 Mar 2003 10:22:47 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

> There is the expectation that this WG may stick around until we get 
> to DS.  That means that we may remain active in spite of resolving 
> the IESG comment, getting PS documents and not spending time on 
> issues that have flared up and then seemed to go away (ROID).

Understood. HTTP WG hung until Moore and Freed screwed around with
Dave Krystol's state management mechanism draft. Too similar to the
current wrangle for comfort.

> In that case, discussing alt. transports at -57 might not be a bad idea.
> 
> However, 1) no one can promise we will still be active then and 2) 
> starting a discussion on the mail list at any time is preferable for 
> waiting to start a discussion at  an in-face meeting.

Of course.

Date: Fri, 7 Mar 2003 10:07:57 -0500
To: Eric Brunner-Williams in Portland Maine <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: Re: [ietf-provreg] proto-agenda
Cc: Edward Lewis <[email-masked]>, Andrew Newton <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

I see no rush to define another transport, but keep these 'realities' in mind:

There is the expectation that this WG may stick around until we get 
to DS.  That means that we may remain active in spite of resolving 
the IESG comment, getting PS documents and not spending time on 
issues that have flared up and then seemed to go away (ROID).

In that case, discussing alt. transports at -57 might not be a bad idea.

However, 1) no one can promise we will still be active then and 2) 
starting a discussion on the mail list at any time is preferable for 
waiting to start a discussion at  an in-face meeting.

At 9:44 -0500 3/7/03, Eric Brunner-Williams in Portland Maine wrote:
>Ed,
>
>There has been a note to the list about an implementation over HTTP.
>All things considered, -56 time available, and proximity of -57 venue
>to the implementor, that may be the better time to do other-than-tcp.
>
>Eric

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

To: Edward Lewis <[email-masked]>
cc: Andrew Newton <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [ietf-provreg] proto-agenda 
Date: Fri, 07 Mar 2003 09:44:44 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

Ed,

There has been a note to the list about an implementation over HTTP.
All things considered, -56 time available, and proximity of -57 venue
to the implementor, that may be the better time to do other-than-tcp.

Eric

Date: Fri, 7 Mar 2003 09:18:19 -0500
To: Andrew Newton <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: Re: [ietf-provreg] proto-agenda
Cc: Edward Lewis <[email-masked]>, [email-masked]
Sender: [email-masked]

Discussing alternate transports in in our charter:

"The group will consider support for multiple operational choices, 
such as for transport..."

So far, no transport other than TCP has sparked widespread interest. 
One person  is touting SMTP, a few others expressed support for SOAP 
a few months ago.  It doesn't appear that there's an alternative to 
TCP that is on the verge of being added as a WG item, but we are 
chartered to explore the possibility.

Note too that the list of which this is a part is not an agenda list, 
but the remaining unresolved items from last time.  If no one has any 
material to discuss in SF, then alternate transports won't appear on 
the agenda.

At 18:43 -0500 3/6/03, Andrew Newton wrote:
>Edward Lewis wrote:
>>  2) Alternate transports
>
>Does this item need to be included?
>
>I just ran through the list, and the last talk of this seems to be 
>in December, which might be summarized as: 1) a new draft was 
>promised before Christmas (the current one expires this month), and 
>2) several people agreeing that it should be experimental.
>
>-andy

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

To: Edward Lewis <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: [ietf-provreg] proto-agenda 
Date: Fri, 07 Mar 2003 08:13:16 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

[non-attendee comments on proposed agenda.]

> 3. Clarify the adoption of P3P concepts.

Pointing out a specific defect in the <dcp> element's sub-schema would be
really useful.

> 5. An SMTP mapping is all but dead in the water.
> 
> Unless someone objects on the mail list, we're dropping all
> milestones relating to SMTP.

I object.

> 8. Discuss 'lastVerified' - mandatory, extension or optional

I think this is a bad idea sneaking in from some other policy area.
I could be mistaken.

> 9. Discuss handling of external hosts

That should be interesting.

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Edward Lewis'" <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: RE: [ietf-provreg] Fwd: Re: provreg milestones
Date: Fri, 7 Mar 2003 07:23:14 -0500 
Sender: [email-masked]

> Also to the group - as far as the privacy thing being resolved, I'm a 
> bit hesitant to declare consensus yet to the proposal in:
> 
> # From: "Hollenbeck, Scott" <[email-masked]>
> # Date: Mon, 3 Mar 2003 13:02:34 -0500
> #
> # As far as .com is concerned, I have no doubt that an 
> extension will be
> # required even if we were to adopt the IESG's element 
> tagging suggestion.
> # That being the case, my preference would be to put _all_ of 
> the DNP syntax
> # and semantics into an extension (where the problem can be 
> addressed as a
> # whole) while making the existing DCP element mandatory if 
> that resolves the
> # privacy issue with the IESG.
> 
> (Aka - 
> http://www.cafax.se/ietf-provreg/maillist/2003-03/msg00010.html)
> 
> So let me hear about that...

Ed, please note these supporting comments sent prior to your note:

http://www.cafax.se/ietf-provreg/maillist/2003-03/msg00015.html

http://www.cafax.se/ietf-provreg/maillist/2003-03/msg00023.html

-Scott-

To: "Hollenbeck, Scott" <[email-masked]>
cc: "'Eric Brunner-Williams in Portland Maine'" <[email-masked]>, "[email-masked]'" <[email-masked]>, [email-masked]
Subject: Re: [ietf-provreg] FYI: EPP implementation by the Polish registry 
Date: Thu, 06 Mar 2003 20:01:35 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

The distinction between "social" (billing) and "technical" (zone files)
is not quite the same as between registrar-retained-authoritative (RRP)
and registry-retained-authoritative (EPP). If we're going to create two
(or more) baskets to put data into, which would allow some alternate to
the session-scoped <dcp> that has basket-of-stuff-scope, then we need
to define the baskets, but without dependency upon the distinction of
RRP vs EPP, and "thin" vs "thick" registry models.

Humor me. In a "pure thin EPP", there'd be no whois:43 issue for the 
protocol, the registry would never see anything but NS and A records.
That liability would remain with the registrars and their whois servers.
In a "pure thick EPP" (what we're writing), there is data that is
published via 1034/35 (NS and A records), and data that is published
via 954 (everything, including personally identifying registrant data).
We can't define a distinction in a "pure thick EPP" specification by
making direct, or indirect reference or comparison to the RRP model.
At least, not without something like a dangling pointer.

I've used "pure" in the para above because some registrars are also
registries, though not necessarily of the same namespaces, and I want
to ignore the complication of a registrar who is a whois operator (RRP)
as well as a registry operator, and a registrar who is not a whois
operator (EPP) as well as a registry operator that is a whois operator.
That kind of stuff gets me dizzy.

So, if we say publication via 1034/35, of A and NS records (we're domain
name specific, at least momentarily, and "privacy/data collection" may
not mean the same thing, or anything, in an address registry context, or
other possible SRS contexts), _is_ technical data, and everything else
isn't (which is almost what we had), then we may have a useful definition.

It may help (or I may be going out unnecessarily on a limb) if we make
the distinction between non-technical data and data that is sufficient
to construct persistent unique identifiers. If it helps, in the 95/46/EC
context, the 32 bits of an ipv4 endpoint identifer is subject to data
collection disclosure, hence the (IMO lame) definition in P3P of a 25 bit
addr as something other than "personally identifying" (a unique endpoint
identifier, or one that can be resonably constructed from the collected
data).

Names, telnos, postals, ips fit into this. Admin and Tech contacts don't.

Mind, the simpler course is to stay with a session-scoped policy dingus,
and not dive into what data means what when and to whom. It may not seem
like it, but I'm a big fan of _simple_.

<dcp> manditory.

Eric

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Eric Brunner-Williams in Portland Maine'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: [ietf-provreg] FYI: EPP implementation by the Polish registry
Date: Thu, 6 Mar 2003 19:27:46 -0500 
Sender: [email-masked]

> The problem with where we left off (in 3375 and with Ross' 
> -dn-), is that
> we were letting the RRP vs EPP (thick/thin) act as our framework. Here
> we need to look, not at who has the data, but at what data 
> has what kind
> of function. Almost, but not quite, the same.

This is where you start to lose me.  What data functions (beyond the
provisioning and management of the data itself) are in-scope for us?

-Scott-

Date: Thu, 06 Mar 2003 18:43:01 -0500
From: Andrew Newton <[email-masked]>
To: Edward Lewis <[email-masked]>
CC: [email-masked]
Subject: Re: [ietf-provreg] proto-agenda
Sender: [email-masked]

Edward Lewis wrote:
> 2) Alternate transports

Does this item need to be included?

I just ran through the list, and the last talk of this seems to be in 
December, which might be summarized as: 1) a new draft was promised 
before Christmas (the current one expires this month), and 2) several 
people agreeing that it should be experimental.

-andy

To: "Hollenbeck, Scott" <[email-masked]>
cc: "'Edward Lewis'" <[email-masked]>, "[email-masked]'" <[email-masked]>, [email-masked]
Subject: Re: [ietf-provreg] FYI: EPP implementation by the Polish registry 
Date: Thu, 06 Mar 2003 18:06:27 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

> > At 10:47 -0500 3/3/03, Eric Brunner-Williams in Portland Maine wrote:
> > >adding attributes to elements is either pervasive, or 
> > specific. As this
> > >WG lost the technical/social distinction with the expiry of 
> > Ross' draft,
> > 
> > What parts of the material in Ross' draft need to be added (as 
> > terminology definitions) in the base spec (or base spec-bis)?
> 
> Note that section 1.1 of requirements RFC 3375 includes parenthetical
> descriptions for "social" and "technical" information in the definition of a
> "thick" registry.

See: Subject: Is it "social" or is it "model" or is it "mechanism"?
Sent to this list on 02.13.03

We simply need to seperate the thick/thin (registry model) from the 
publication mechanisms (1034/35), and be dns-specific (for a change),
and speak er, write about the RRs we provision, without being Master
File Format specific (and triggering a valid DJB criticism).

The problem with where we left off (in 3375 and with Ross' -dn-), is that
we were letting the RRP vs EPP (thick/thin) act as our framework. Here
we need to look, not at who has the data, but at what data has what kind
of function. Almost, but not quite, the same.

Eric

Date: Thu, 06 Mar 2003 18:13:46 -0500
From: Daniel Manley <[email-masked]>
To: Edward Lewis <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: [ietf-provreg] Fwd: Re: provreg milestones
Sender: [email-masked]

Here's my vote for consensus.  Let's put this to rest.  This solution 
addresses enough to declare privacy policy to EPP clients.  With the 
variety of privacy policies out there in the world, putting client 
overrides into the extension framework keep this flexible for all 
parties involved.  EPP's been all about extensibility from the start.

Dan

Edward Lewis wrote:

> Also to the group - as far as the privacy thing being resolved, I'm a 
> bit hesitant to declare consensus yet to the proposal in:
>
> # From: "Hollenbeck, Scott" <[email-masked]>
> # Date: Mon, 3 Mar 2003 13:02:34 -0500
> #
> # As far as .com is concerned, I have no doubt that an extension will be
> # required even if we were to adopt the IESG's element tagging 
> suggestion.
> # That being the case, my preference would be to put _all_ of the DNP 
> syntax
> # and semantics into an extension (where the problem can be addressed 
> as a
> # whole) while making the existing DCP element mandatory if that 
> resolves the
> # privacy issue with the IESG.
>
> (Aka - http://www.cafax.se/ietf-provreg/maillist/2003-03/msg00010.html)
>
> So let me hear about that...
>
>> Date: Thu, 6 Mar 2003 21:48:31 +0100
>> Subject: Re: provreg milestones
>> Cc: [email-masked], Ted Hardie <[email-masked]>
>> To: Edward Lewis <[email-masked]>
>> From: Patrik Fältström <[email-masked]>
>> X-OriginalArrivalTime: 06 Mar 2003 20:48:37.0518 (UTC) 
>> FILETIME=[C2ED4AE0:01C2E421]
>> Status:
>>
>> This looks good.
>>
>> Please send the new milestones to [email-masked].
>>
>> I also understand the privacy thing is now resolved. I saw a few 
>> messages on the mailing list about it.
>>
>> May I suggest you (or someone) write a summary of what the solution 
>> is, and send it to me, randy, allison (and also cc Ned and Ted as 
>> co-AD's -- yes, Ted is formally not onboard, but anyway). You can of 
>> course also cc the mailing list if you want to.
>>
>>     paf
>>
>> On torsdag, mar 6, 2003, at 16:59 Europe/Stockholm, Edward Lewis wrote:
>>
>>>  I've heard no response to this from 'above.'
>>>
>>>  The FEB 03 milestone now should be MAR 03 I guess.
>>>
>>>>  Date: Fri, 31 Jan 2003 10:14:40 -0500
>>>>  To: [email-masked], [email-masked]
>>>>  From: Edward Lewis <[email-masked]>
>>>>  Subject: provreg milestones
>>>>  Cc: [email-masked], [email-masked]
>>>>  Bcc:
>>>>  X-Attachments:
>>>>
>>>>  While we still have an open issue with regards to privacy, I want 
>>>> to move on and at least refresh the group's milestones.
>>>>
>>>>  FEB 03 Respond to the IESG Comments (for Proposed)
>>>>  MAR 03 Submit Guidelines for Extending the EPP to IESG 
>>>> (Informational)
>>>>  APR 03 Decision on Alternate Transports
>>>>  SEP 03 Perform Interoperability Tests
>>>>  OCT 03 Submit Interoperability Report to IESG (Informational)
>>>>  OCT 03 Submit Extensible Provisioning Protocol to IESG (Draft)
>>>>  OCT 03 Submit EPP Contact Mapping to IESG (Draft)
>>>>  OCT 03 Submit EPP Domain Name Mapping to IESG (Draft)
>>>>  OCT 03 Submit EPP Host Mapping to IESG (Draft)
>>>>  OCT 03 Submit EPP Transport Over TCP to IESG (Draft)
>>>>
>>>>  Look these over carefully.  I added the first because we haven't 
>>>> closed that off, as well as having some potential threads to cover 
>>>> in addition to the privacy question.
>>>>
>>>>  A "Decision on Alternate Transports" is on there because our 
>>>> charter talks about  "support for multiple operational choices, 
>>>> such as for transport".  At times support has been expressed for 
>>>> BEEP, SMTP, and SOAP, but none have garnered much support.  My 
>>>> vague opinion is that alternate transports will need to come with 
>>>> code, not just documents, before they can be taken seriously by the 
>>>> WG.
>>>>
>>>>  Note that SMTP and SOAP milestones are not on there.  Not to 
>>>> denigrate the work, but they haven't made it to general interest 
>>>> for the WG.
>>>>
>>>>  With this message I am asking our AD to approve these milestones, 
>>>> we can adjust them as necessary.
>>>
>>>
>>>  -- 
>>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>>>  Edward Lewis                                          +1-703-227-9854
>>>  ARIN Research Engineer
>>>
>>

Date: Thu, 6 Mar 2003 16:38:02 -0500
To: [email-masked]
From: Edward Lewis <[email-masked]>
Subject: [ietf-provreg] Fwd: Re: provreg milestones
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Also to the group - as far as the privacy thing being resolved, I'm a 
bit hesitant to declare consensus yet to the proposal in:

# From: "Hollenbeck, Scott" <[email-masked]>
# Date: Mon, 3 Mar 2003 13:02:34 -0500
#
# As far as .com is concerned, I have no doubt that an extension will be
# required even if we were to adopt the IESG's element tagging suggestion.
# That being the case, my preference would be to put _all_ of the DNP syntax
# and semantics into an extension (where the problem can be addressed as a
# whole) while making the existing DCP element mandatory if that resolves the
# privacy issue with the IESG.

(Aka - http://www.cafax.se/ietf-provreg/maillist/2003-03/msg00010.html)

So let me hear about that...

>Date: Thu, 6 Mar 2003 21:48:31 +0100
>Subject: Re: provreg milestones
>Cc: [email-masked], Ted Hardie <[email-masked]>
>To: Edward Lewis <[email-masked]>
>From: Patrik Fältström <[email-masked]>
>X-OriginalArrivalTime: 06 Mar 2003 20:48:37.0518 (UTC) 
>FILETIME=[C2ED4AE0:01C2E421]
>Status:
>
>This looks good.
>
>Please send the new milestones to [email-masked].
>
>I also understand the privacy thing is now resolved. I saw a few 
>messages on the mailing list about it.
>
>May I suggest you (or someone) write a summary of what the solution 
>is, and send it to me, randy, allison (and also cc Ned and Ted as 
>co-AD's -- yes, Ted is formally not onboard, but anyway). You can of 
>course also cc the mailing list if you want to.
>
>     paf
>
>On torsdag, mar 6, 2003, at 16:59 Europe/Stockholm, Edward Lewis wrote:
>
>>  I've heard no response to this from 'above.'
>>
>>  The FEB 03 milestone now should be MAR 03 I guess.
>>
>>>  Date: Fri, 31 Jan 2003 10:14:40 -0500
>>>  To: [email-masked], [email-masked]
>>>  From: Edward Lewis <[email-masked]>
>>>  Subject: provreg milestones
>>>  Cc: [email-masked], [email-masked]
>>>  Bcc:
>>>  X-Attachments:
>>>
>>>  While we still have an open issue with regards to privacy, I want 
>>>to move on and at least refresh the group's milestones.
>>>
>>>  FEB 03 Respond to the IESG Comments (for Proposed)
>>>  MAR 03 Submit Guidelines for Extending the EPP to IESG (Informational)
>>>  APR 03 Decision on Alternate Transports
>>>  SEP 03 Perform Interoperability Tests
>>>  OCT 03 Submit Interoperability Report to IESG (Informational)
>>>  OCT 03 Submit Extensible Provisioning Protocol to IESG (Draft)
>>>  OCT 03 Submit EPP Contact Mapping to IESG (Draft)
>>>  OCT 03 Submit EPP Domain Name Mapping to IESG (Draft)
>>>  OCT 03 Submit EPP Host Mapping to IESG (Draft)
>>>  OCT 03 Submit EPP Transport Over TCP to IESG (Draft)
>>>
>>>  Look these over carefully.  I added the first because we haven't 
>>>closed that off, as well as having some potential threads to cover 
>>>in addition to the privacy question.
>>>
>>>  A "Decision on Alternate Transports" is on there because our 
>>>charter talks about  "support for multiple operational choices, 
>>>such as for transport".  At times support has been expressed for 
>>>BEEP, SMTP, and SOAP, but none have garnered much support.  My 
>>>vague opinion is that alternate transports will need to come with 
>>>code, not just documents, before they can be taken seriously by 
>>>the WG.
>>>
>>>  Note that SMTP and SOAP milestones are not on there.  Not to 
>>>denigrate the work, but they haven't made it to general interest 
>>>for the WG.
>>>
>>>  With this message I am asking our AD to approve these milestones, 
>>>we can adjust them as necessary.
>>
>>  -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>>  Edward Lewis                                          +1-703-227-9854
>>  ARIN Research Engineer
>>
>
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Edward Lewis'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: [ietf-provreg] FYI: EPP implementation by the Polish registry
Date: Thu, 6 Mar 2003 12:40:24 -0500 
Sender: [email-masked]

> At 10:47 -0500 3/3/03, Eric Brunner-Williams in Portland Maine wrote:
> >adding attributes to elements is either pervasive, or 
> specific. As this
> >WG lost the technical/social distinction with the expiry of 
> Ross' draft,
> 
> What parts of the material in Ross' draft need to be added (as 
> terminology definitions) in the base spec (or base spec-bis)?

Note that section 1.1 of requirements RFC 3375 includes parenthetical
descriptions for "social" and "technical" information in the definition of a
"thick" registry.

-Scott-

Date: Thu, 6 Mar 2003 11:14:32 -0500
To: Eric Brunner-Williams in Portland Maine <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: Re: [ietf-provreg] FYI: EPP implementation by the Polish registry
Cc: "Hollenbeck, Scott" <[email-masked]>, "'Edward Lewis'" <[email-masked]>, "[email-masked]'" <[email-masked]>, [email-masked]
Sender: [email-masked]

At 10:47 -0500 3/3/03, Eric Brunner-Williams in Portland Maine wrote:
>adding attributes to elements is either pervasive, or specific. As this
>WG lost the technical/social distinction with the expiry of Ross' draft,

What parts of the material in Ross' draft need to be added (as 
terminology definitions) in the base spec (or base spec-bis)?

>954 that is of issue, particularly in the EU, but also in the OEDC, and

What is OEDC?

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

Date: Thu, 6 Mar 2003 11:30:19 -0500
To: Hideki Noma <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: Re: [ietf-provreg] URL element in contact mapping
Cc: [email-masked]
Sender: [email-masked]

The WG (which is the mailing list) has not heard of this before, so 
we are unable to send you a reference.

We would appreciate more information on this topic so that the 
protocol is capable of handling all it needs to handle.

At 12:37 +0900 3/4/03, Hideki Noma wrote:
>Hello,
>
>There will be a URL element introduced in .JP contact information in 
>near future.
>And I beleive that some sort of element representing a URL of domain 
>owner or contact
>is necessary.In fact whois.internic.net has both url element of 
>whois server and
>web server.
>
>I understand that url element should be optional or even, extention 
>implemented by registrars,
>however the element name must be standardized. I don't know why JP 
>registry is not commenting on
>this but as one of JP registrar, I strongly request it.
>
>If there has been a discussion around this topic I've missed it, 
>please point me
>where to look at.
>
>Hideki Noma
>Humeia Limited Partnership

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

Date: Thu, 6 Mar 2003 11:03:58 -0500
To: [email-masked]
From: Edward Lewis <[email-masked]>
Subject: [ietf-provreg] proto-agenda
Cc: [email-masked]
Sender: [email-masked]

Based on what I've seen on the list:

1) Getting to the bottom of the privacy issue - the one in front of 
us, that is.

2) Alternate transports

3) IDN in EPP

Does anyone still want to discuss a problem with ROID?

Here are action items I recorded in December:

1. Respond to the IESG comments.

Most of the comments are easily addressed.  A few need further
discussion (and are listed as separate action items).

2. Come to a final understanding of UDP and EPP.

There have been some words posted to the "outlawing" of UDP, one
response was to require stream based protocols.

3. Clarify the adoption of P3P concepts.

P3P was written for website environments, not a business to business
situation.  This is reflected in some of our examples and needs to be
cleaned up.

Rick Wesson volunteered to summarize a discussion on privacy issues.
It might be up to us to forge new ground here as we are one of the
few protocols that gathers personal information (for registration
information).

4. Whether or not we adopt a work item for the SOAP 'as transport' draft.

A thread has been started on the list, but the results are luke warm for now.

5. An SMTP mapping is all but dead in the water.

Unless someone objects on the mail list, we're dropping all
milestones relating to SMTP.

6. Continue to progress on Guidelines.

No sense of urgency, at least not until we get #1 above done.

Two other action items...

7. Clean up the milestones.

After the meeting we talked and decided that the milestones on the
web page aren't sufficiently descriptive.  Before fixing them, #4 and
#5 need answers.

8. Discuss 'lastVerified' - mandatory, extension or optional

9. Discuss handling of external hosts

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

To: Vittorio Bertola <[email-masked]>
cc: Eric Brunner-Williams in Portland Maine <[email-masked]>, "[email-masked]'" <[email-masked]>, [email-masked]
Subject: Re: [ietf-provreg] FYI: EPP implementation by the Polish registry 
Date: Thu, 06 Mar 2003 08:12:33 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

CRISP, WHOISFIX, NOT43, ... deal with publication protocols.
DNSOP, DNSSEC, ... also deal with publication protocls.

Generally, they start with some authoritative instance of some datum,
and unconditionally replicate non-authoritative copies of that datum.

The access and persistence properties of these do not subset the
maximums for both generally.

PROVREG and its anticeedents, the DOMREG BoF(s) and the authors
of RRP, ... deal with provisioning protocols. 

Generally, they start with some non-authoritative instance of some
datum, and conditionally allocate an authoritative instance of that
datum.

The access and persistence properties of these subset the maximums
for both generally.

OTHER PUBLICATION PROTOCOLS EXIST.

Bulk copy, with "sale", "lease" and "rent" of mailing lists, postal
and electronic, exists. Some implementations use "sneaker net".

Other technical mechanisms, which exploit properties of domain name
data in particular, the nameserver, technical and administrative
contact, even the character space properties of a domain name (marks,
soundex, Hamming Distrance from, ...) which REPURPOSE data, also exist.

Data provisioned via protocol (RRP, SRS, EPP, ... NEXT) may be merged
with data acquired by other means.

Since the beginning of this Working Group, there have been contributors
who want to "solve" the 954 problem within EPP. This approach does not
solve for other publication mechanisms, nor does it solve for the user
informed portion of the informed consent meta-requirement placed on all
data collectors by 95/46/EC and related texts that address directories,
and related tools for the management of endpoint identifiers which may
identify individual persons.

If the better reading of 95/46/EC et seq. is that it applies to port 43,
and originators need only (may only) make port-specific negative assertions,
then a "publication" framework (yours and others, e.g., the IESG) may be
sufficient.

Having done this twice before, I don't think so. Besides, I don't know
that EPP can't be used for keyword systems, that may not use :43, and
for anything similar.

It would work for the US, and anywhere else where the IAB (the other one,
the Internet Advertising Board) and the DMA (Direct Marketing Association)
and similar trade groups control the "opt-in vs opt-out" policy issue.

I now know it would work in Holland also. I don't understand this, but
the European Data Commissioners I've communicated with over the past three
years are French and German, so I've obviously missed something.

Pointing out a specific defect in the <dcp> element's sub-schema would be
really useful.

Eric

From: Vittorio Bertola <[email-masked]>
To: Eric Brunner-Williams in Portland Maine <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: Re: [ietf-provreg] FYI: EPP implementation by the Polish registry 
Date: Thu, 06 Mar 2003 10:06:02 +0100
Sender: [email-masked]

On Mon, 03 Mar 2003 10:47:52 -0500, you wrote:

>> The third is a message describing the EU perspective on why this must
>> be solved.
>
>Oh thank heavens! A live EU national who is a self-described "newbie" and
>neither an implementor, nor an operator, nor an author, nor apparently a
>specification reader. Now I can stop thinking.

Just for the sake of precision... I am an ICT engineer, I've been
reading and using RFCs for the last 8 years, and I am sufficiently
geek to often use e-mail by telnet 25/110 :-) I do not work in the
domain name business and I am a newbie in this working group, and this
is why I don't want to make suggestions about the technicalities,
given that you all here have been discussing them for years. So I'm
just lurking the list as often as I can. But the CRISP group has found
my suggestions useful enough to include them in the latest CRISP
requirements draft.

>Note Bene Chair:
>	1. IESG (Randy or Allison) asked and answered
>	2. IESG (Patrick) asked and answered
>	3. .NL asked and not responsive
>	4. .PL asked and not responsive
>	5. Newbie noises

My intention was not to produce "noise" but just to help the group
understanding the issues at stake from a different perspective. Please
pardon me if I failed in this.

(However this thread is going off topic, so please consider replying
in private.)
-- 
vb.                  [Vittorio Bertola - vb [at] bertola.eu.org]<---
-------------------> http://bertola.eu.org/ <-----------------------

To: [email-masked]
Subject: [ietf-provreg] Synchronisity
Date: Wed, 05 Mar 2003 21:50:53 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

All,

Context - new IRTF trainwreck, gazillion opinion posts posing as charter
wrangles. In a nutshell ...

>> ...which violates german privacy laws...

> I guess different cultures have different ideas of privacy...

We're not alone. There is unintelligent life in the universe.

Eric

P.S. To be cheritable, relay is in theory some form of onward-transport
problem. Contrast this with geopriv, which is a captive-leaf (roaming)
problem. Geopriv has done a new document cycle, if anyone cares.

------- Forwarded Message

From: Keith Moore <[email-masked]>
To: Hadmut Danisch <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: [Asrg] desirable characteristics of source tracking (was:
 Requirements for source tracking)

...
> > 
> > What I might like to know are things like:
> > 
> > a. is the sender's account new, or has it been around awhile?
> > b. does the source ISP have a reliable way to bill the sender?
> >    (or is this from someone who got a 100 hours free CD in the mail?)
> > c. have there been many complaints about mail from this sender?
> 
> 
> ...which violates german privacy laws...
> 
> Privacy is fortunately highly protected over here.

let me get this straight - it's not a violation of privacy to insist on
knowing the real identity of someone who sent a message, but it is a violation
of privacy to provide a slight bit of additional information about an
anonymous  or pseudonymous sender?

I guess different cultures have different ideas of privacy...

that's okay - there's no reqirement for the ISP to provide such information.
but if the ISP can legally do so, and is willing to do so, then the sender
can provide preferential treatment of the message.

I don't think we're going to end up with a uniform global solution for spam in
any case, because different people and different cultures vary not only
according to what kinds of protection they consider important, but also in
what they consider offensive or unacceptable.

Keith
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

------- End of Forwarded Message

To: Jaap Akkerhuis <[email-masked]>
cc: Eric Brunner-Williams in Portland Maine <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [ietf-provreg] FYI: EPP implementation by the Polish registry 
Date: Tue, 04 Mar 2003 11:34:41 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

> Two followups for a charater change.

Covered in my prior reply.

> You said:
> 
>     1. Application of the IESG proposal to "technical" data.
>     
...
>     other than error upon query or transform. I can't imagine an application
>     to an address registry's operational practices, but I don't have direct
>     knowledge of address registry or registrar operational art.
> 
> That shows. Note I said, that this was a hypothetical case.

OK. We're past technical issues, and on to list dysfunction.

It is a small matter. 

Eric

To: Jaap Akkerhuis <[email-masked]>
cc: Eric Brunner-Williams in Portland Maine <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [ietf-provreg] FYI: EPP implementation by the Polish registry 
Date: Tue, 04 Mar 2003 10:56:32 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

Jaap,

The third URL should have a value one greater than the second, it was
cut and paste, and I only noticed after send.

Eric

To: Eric Brunner-Williams in Portland Maine <[email-masked]>
cc: [email-masked]
Subject: Re: [ietf-provreg] FYI: EPP implementation by the Polish registry 
Date: Tue, 04 Mar 2003 16:31:02 +0100
From: Jaap Akkerhuis <[email-masked]>
Sender: [email-masked]

    It appears I did read that. I replied with about 60 lines of comment in
    
    http://www.cafax.se/ietf-provreg/maillist/2003-01/msg00062.html
    
    and a one character correction in
    
    http://www.cafax.se/ietf-provreg/maillist/2003-01/msg00063.html
    
    and followed up with 
    
    http://www.cafax.se/ietf-provreg/maillist/2003-01/msg00063.html

Two followups for a charater change.

You said:

    1. Application of the IESG proposal to "technical" data.
    
    The .NL registry defines (hypothetically of course) a dnp==true value for
    one or more elements as an error condition, and presumably returns some
    error code.
    
    Someone, Scott if my memory serves, mentioned a registry which defines a
    dnp==true value for one or more elements as a non-error, and presumably
    returns something other than an error code.
    
    Is using EPP with dcp==true for technical data a good thing? I see it as
    an operation to modify the string-space, with no external manifestation,
    other than error upon query or transform. I can't imagine an application
    to an address registry's operational practices, but I don't have direct
    knowledge of address registry or registrar operational art.

That shows. Note I said, that this was a hypothetical case.
    
    2. Application of the IESG proposal to "social" data at a registry.
    
    The .NL registry anticipates (effective 29 Jan 2003) operating under the
    general framework of a European Union member state's Data Protection Act.
    
    Consistent with the general framework of EU's Data Protection Directives,
    the access, purpose, recipient, and retention are all contractually defined.
    
    This is not generally the case for registries operating outside of the EU,
    nor for registrars and resellers operating outside of the EU.
    
    It would be helpful if the details of data protection between a non-EU
    resident .NL regsitrar and the .NL registry were available, assuming any
    exist.

Note that we do this under dutch law. If registrars and registrations
doesn't want to confirm to that, there is no point in registrting
in .NL.
    
    3. Existance of the PROVREG proposal, in the presence of the IESG proposal.
    
    Would the .NL registry operator use both the session-level <dcp> data, and
    the element-level opt-{in|out} data? If the answer is "no", as I suspect
    it is, then <dcp> use either a) is error, or b) is silently discarded.

No, it is not discarded. Reread. And I din't mentioned both elements
at all.

    If the answer is "yes", which takes precidence in the event of conflict?

    Trying to keep concrete, data originates from a registrant and is collected
    by a US-Reseller, and in turn provisioned to a CA-Registrar, and in turn is
    provisioned to a .EU-Registry. Is the mechanism that provides the guidance
    for operational art at each onward-transport entity out-of-band (contract),
    or is it in-band, and if in-band, did the IESG proposal provide the same
    policy at each collector/onward-transporter as the European Union member
    state's Data Protection Act?
    
    I don't think so.
    
    I could be wrong.
    
    A p|np toggle is fine if purpose/recipient/retention/access are already
    taken care of (the Data Protection case). Where they are not, (OEDC and
    US cases), a p|np toggle may solve the 954 problem. How it can be applied
    to non-954 (and 954bis) is not stated.
    
Deliver text.

	jaap

To: "Edmon Chung" <[email-masked]>
cc: "Eric Brunner-Williams in Portland Maine" <[email-masked]>, "Rick Wesson" <[email-masked]>, [email-masked], "Edward Lewis" <[email-masked]>, [email-masked]
Subject: Re: [ietf-provreg] our meeting slot in SF 
Date: Tue, 04 Mar 2003 08:58:24 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

so, in a nutshell, you'd like a mechanism that allows for the expression
of some new semantic, in particular, some form of equivalence class(es),
where the semantics of "equivalence" is some property of some provisioned
object.

we had this at one point, in one form. containers. mind, it wasn't for
octet or sequenct of octets equivalence classes (however defined).

well, if you can find a general expression, i'd be interested in reading
it.

cheers,
eric

From: "Edmon Chung" <[email-masked]>
To: "Eric Brunner-Williams in Portland Maine" <[email-masked]>
Cc: "Eric Brunner-Williams in Portland Maine" <[email-masked]>, "Rick Wesson" <[email-masked]>, <[email-masked]>, "Edward Lewis" <[email-masked]>
Subject: Re: [ietf-provreg] our meeting slot in SF 
Date: Tue, 4 Mar 2003 08:40:32 -0500
Sender: [email-masked]

----- Original Message -----
From: "Eric Brunner-Williams in Portland Maine" <[email-masked]>
> > And, I think what we want to discuss in this work group is not the
actual
> > "mapping tables", but the framework for doing provisioning.
>
> What part is "interoperable", and subject to specification, assuming that
> a requirements statement exists, or can be frobbed up in finite time?

The framework of the provisioning should be interoperable and subject to
specification.  For example, on domain create, the response should contain a
list of "reserved variants".  The annoucement of the list and the types of
reserved variants could be specified.  The actual list would be based on the
registry policy.

> > It has more to do with how the management of reserved variants and zone
> > variants can be provisioned.
>
> This doesn't seem to be a likely candidate for "interoperable", etc.

The policy itself would not be of the interest of this discussion.  Rather
the provisioning protocol should be.  For further example, on query for
domain info there should be additional list that contains the reserved
variants and zone variants.  Also for domain update, there should be ways to
manage the reserved variants and zone variants.  These could all be
standardized even if the particular zone policies are different.  Just like
some TLDs might consider fax number to be "required" and some "optional",
but the provisioning protocol supports the communication of fax numbers.

Edmon

To: "Edmon Chung" <[email-masked]>
cc: "Eric Brunner-Williams in Portland Maine" <[email-masked]>, "Rick Wesson" <[email-masked]>, [email-masked], "Edward Lewis" <[email-masked]>, [email-masked]
Subject: Re: [ietf-provreg] our meeting slot in SF 
Date: Tue, 04 Mar 2003 08:08:14 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

> I thought you didnt like the idea... ;-D

Correct.

> And, I think what we want to discuss in this work group is not the actual
> "mapping tables", but the framework for doing provisioning.

What part is "interoperable", and subject to specification, assuming that
a requirements statement exists, or can be frobbed up in finite time?

> It has more to do with how the management of reserved variants and zone
> variants can be provisioned.

This doesn't seem to be a likely candidate for "interoperable", etc., but
by all means, don't listen to me, you've bet your business that I'm wrong
and dns operators are just dying to shell out shell metacharacters to the
clammoring masses.

She sells sea shells by the sea shore ... and in zone files.

Cheers,
Eric

To: Jaap Akkerhuis <[email-masked]>
cc: Eric Brunner-Williams in Portland Maine <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [ietf-provreg] FYI: EPP implementation by the Polish registry 
Date: Tue, 04 Mar 2003 07:22:16 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

>    Really? It seems that Scott (ages ago, London-context) said "contracts" as
>    the mechanism. I'm sorry but I don't know which earlier response you are
>    referring to. Could you provide a date? I'll read it.
>
>	    http://www.cafax.se/ietf-provreg/maillist/2003-01/msg00049.html    

It appears I did read that. I replied with about 60 lines of comment in

http://www.cafax.se/ietf-provreg/maillist/2003-01/msg00062.html

and a one character correction in

http://www.cafax.se/ietf-provreg/maillist/2003-01/msg00063.html

and followed up with 

http://www.cafax.se/ietf-provreg/maillist/2003-01/msg00063.html

Well, my baby wants pick-up, and she won't wait 9 weeks until I get
around to paying attention to her needs.

Eric

To: Eric Brunner-Williams in Portland Maine <[email-masked]>
cc: [email-masked]
Subject: Re: [ietf-provreg] FYI: EPP implementation by the Polish registry 
Date: Tue, 04 Mar 2003 10:57:36 +0100
From: Jaap Akkerhuis <[email-masked]>
Sender: [email-masked]

    Really? It seems that Scott (ages ago, London-context) said "contracts" as
    the mechanism. I'm sorry but I don't know which earlier response you are
    referring to. Could you provide a date? I'll read it.

http://www.cafax.se/ietf-provreg/maillist/2003-01/msg00049.html    

	jaap

To: Hideki Noma <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: [ietf-provreg] URL element in contact mapping 
Date: Mon, 03 Mar 2003 22:55:06 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

Hideki,

I don't think there has been any discussion around this topic.

Why don't you start to suggest how to specify this?

Eric

To: [email-masked]
Subject: [ietf-provreg] URL element in contact mapping
From: Hideki Noma <[email-masked]>
Date: Tue, 4 Mar 2003 12:37:33 +0900
Sender: [email-masked]

Hello,

There will be a URL element introduced in .JP contact information in near future.
And I beleive that some sort of element representing a URL of domain owner or contact
is necessary.In fact whois.internic.net has both url element of whois server and
web server.

I understand that url element should be optional or even, extention implemented by registrars,
however the element name must be standardized. I don't know why JP registry is not commenting on
this but as one of JP registrar, I strongly request it.

If there has been a discussion around this topic I've missed it, please point me
where to look at.

Hideki Noma
Humeia Limited Partnership

To: Jaap Akkerhuis <[email-masked]>
cc: Eric Brunner-Williams in Portland Maine <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [ietf-provreg] FYI: EPP implementation by the Polish registry 
Date: Mon, 03 Mar 2003 16:03:58 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

I'm not twisting your words, I'm not doing anything but try to get to the
bottom of something.
    
>     Correct.
>     
>     So there no semantic consequence to the registrar being, or not being,
>     "based within the European Union."
> 
> Not with respect of the privacy issues. That is under Dutch regulation,
> as I have said before.

OK.
http://www.nic.nl/sidn/flat/Deelnemers/Deelnemer_worden/index.html
is garbage, in this context.

>     The registrar may (hypothetically) provision some datum to the .nl registry,
>     with some (equally hypothetical) binary toggle set to ZERO, or to ONE, with
>     out difference, independent of the registrar's location. Is this correct?
> 
> Yup, see above.

Good.

>     What contract?
> 
> Between registry and registrar.
>     
>     Better still, if a registrar doesn't need to signal in-band it accepts
>     anything, then it doesn't need to even know whatever that useless thing
>     is.
> 
> You are twiting words. See my earlier response how this might work.

Really? It seems that Scott (ages ago, London-context) said "contracts" as
the mechanism. I'm sorry but I don't know which earlier response you are
referring to. Could you provide a date? I'll read it.

>     8.4 has a MUST in it, which appears to have no meaning at all if I
>     finally understand you. Everything is in the contract -- Scott's opening
>     position, that bilateral out-of-band mechanism (contract) covered the
>     requirement.
> 
> A MUST in a requirement document might work out differently in practice.

In theory ... Yeah. Patrick's quote.

>     Well, you're a co-chair, so I guess we're finnished with
> 
>        The protocol MUST provide services to identify data collection policies.
>     
>     and are on to
>     
>        "the proper element in the protocol which help to implement a policy"
>     
>     Gosh this is such fun. Not.
> 
> I was not talking as co-chair.
> 
> 	jaap
> 

These two sentences mean very different kinds of things.

One attempts to describe a non-trivial policy space, without knowing a priori
the constraints. A mechanism of description. A "what".

One attempts to select from a set of elements (generally) the one(s) which can
effect a particular policy (possibly pluralized). A mechanism of effectation.
A "how".

Usually "how" comes after "what" (except in cowboy and indian movies), not
as an alternative to "what".

Eric

To: Eric Brunner-Williams in Portland Maine <[email-masked]>
cc: [email-masked]
Subject: Re: [ietf-provreg] FYI: EPP implementation by the Polish registry 
Date: Mon, 03 Mar 2003 21:32:57 +0100
From: Jaap Akkerhuis <[email-masked]>
Sender: [email-masked]

    Correct.
    
    So there no semantic consequence to the registrar being, or not being,
    "based within the European Union."

Not with respect of the privacy issues. That is under Dutch regulation,
as I have said before.
    
    The registrar may (hypothetically) provision some datum to the .nl registry,
    with some (equally hypothetical) binary toggle set to ZERO, or to ONE, with
    out difference, independent of the registrar's location. Is this correct?

Yup, see above.

    What contract?

Between registry and registrar.
    
    Better still, if a registrar doesn't need to signal in-band it accepts
    anything, then it doesn't need to even know whatever that useless thing
    is.

You are twiting words. See my earlier response how this might work.
    
    8.4 has a MUST in it, which appears to have no meaning at all if I
    finally understand you. Everything is in the contract -- Scott's opening
    position, that bilateral out-of-band mechanism (contract) covered the
    requirement.

A MUST in a requirement document might work out differently in practice.
    
    Well, you're a co-chair, so I guess we're finnished with

       The protocol MUST provide services to identify data collection policies.
    
    and are on to
    
       "the proper element in the protocol which help to implement a policy"
    
    Gosh this is such fun. Not.

I was not talking as co-chair.

	jaap

From: "Michael Young" <[email-masked]>
To: "'Ross Wm. Rader'" <[email-masked]>, "'Hollenbeck, Scott'" <[email-masked]>, "'Edward Lewis'" <[email-masked]>, <[email-masked]>
Subject: RE: [ietf-provreg] FYI: EPP implementation by the Polish registry
Date: Mon, 3 Mar 2003 15:10:10 -0500
Importance: Normal
Sender: [email-masked]

Likewise, we are also happy with that approach.

Michael Young 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Ross Wm. Rader
Sent: March 3, 2003 1:50 PM
To: Hollenbeck, Scott; 'Edward Lewis'; [email-masked]'
Subject: RE: [ietf-provreg] FYI: EPP implementation by the Polish
registry

--On Monday, March 03, 2003 1:02 PM -0500 "Hollenbeck, Scott" 
<[email-masked]> mentioned that:

> That being the case, my preference would be to put _all_ of the DNP 
> syntax and semantics into an extension (where the problem can be 
> addressed as a
> whole) while making the existing DCP element mandatory

We'd be happy with that as well.

regards,

                       -rwr

"There's a fine line between fishing and standing on the shore like an 
idiot."
- Steven Wright

Get Blog... http://www.byte.org/

To: Jaap Akkerhuis <[email-masked]>
cc: Eric Brunner-Williams in Portland Maine <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [ietf-provreg] FYI: EPP implementation by the Polish registry 
Date: Mon, 03 Mar 2003 14:57:46 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

>    
>    	[Category I participation Category I participation is open
>    	to businesses and institutions based within the European Union.] 
>
>Oh that. I thought that it was lifted. But it is still completely
>irrelevant for the privacy discussion.

OK. What, if anything, is relevant?

>    The "us" (parties having the capacity to register domain names on behalf
>    of clients) for which "the non-disclose attribute will work" appears to
>    be a scoped set of (eventual) EPP participants. The charter for this WG
>    is not to create a registry-specific, or regime-specific, or jurisdiction-
>    specific, or object-specific protocol.
>    
>I'm not bringing this up. You are.

Correct.

So there no semantic consequence to the registrar being, or not being,
"based within the European Union."

The registrar may (hypothetically) provision some datum to the .nl registry,
with some (equally hypothetical) binary toggle set to ZERO, or to ONE, with
out difference, independent of the registrar's location. Is this correct?

I was totally mislead by the .nl registry's Dutch page on the subject of
registrar requirements. Fine. I can live with being stupid. I don't have
a lot of choice in the matter anyway.

>    How can a registrar signal in-band to a registry that it accepts
>    the general Data Protection framework, and any specific terms
>    and conditions?
>
>It doesn't need to. It should first abide to the contract. That is
>not-in band.

What contract?

Better still, if a registrar doesn't need to signal in-band it accepts
anything, then it doesn't need to even know whatever that useless thing
is.

8.4 has a MUST in it, which appears to have no meaning at all if I
finally understand you. Everything is in the contract -- Scott's opening
position, that bilateral out-of-band mechanism (contract) covered the
requirement.

>    More generally, how can any two (or more) participants in the
>    onward-transport of customer data signal in-band their data
>    collection practices, and automate the management of onward-transport?
>    
>That's not question this group has to answer. The only question is,
>what is the proper element in the protocol which help to implement
>a policy as been spelled out in the legal framework.

Well, you're a co-chair, so I guess we're finnished with

   The protocol MUST provide services to identify data collection policies.

and are on to

   "the proper element in the protocol which help to implement a policy"

Gosh this is such fun. Not.

Eric

To: Andrew Newton <[email-masked]>
cc: Eric Brunner-Williams in Portland Maine <[email-masked]>, Edward Lewis <[email-masked]>, "[email-masked]'" <[email-masked]>, [email-masked]
Subject: Re: [ietf-provreg] FYI: EPP implementation by the Polish registry 
Date: Mon, 03 Mar 2003 14:53:28 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

try lack of signal.

would it have been more polite to suggest a low s/n ratio?

Date: Mon, 03 Mar 2003 14:50:24 -0500
From: Andrew Newton <[email-masked]>
To: Eric Brunner-Williams in Portland Maine <[email-masked]>
CC: Edward Lewis <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: [ietf-provreg] FYI: EPP implementation by the Polish registry
Sender: [email-masked]

Eric Brunner-Williams in Portland Maine wrote:
>>The latter case - "newbie" is rather derogatory term.
> 
> 
> From <[email-masked]> 
> 
> 
>>I am a newbie of this group and of the IETF WGs in general (please
>>pardon me for anything inappropriate I might unvoluntarily do).
>>However, I have been discussing DNS privacy issues extensively in the
>>last years, so please allow me to give my point of view on the ongoing
>>privacy discussion.
> 
> 
> Note.

I think it was the use of the words "newbie noises"... "noise" sometimes 
referencing an engineering term for signal ignored or unwanted.

-andy

From: "Edmon Chung" <[email-masked]>
To: "Eric Brunner-Williams in Portland Maine" <[email-masked]>
Cc: "Rick Wesson" <[email-masked]>, <[email-masked]>, "Edward Lewis" <[email-masked]>, <[email-masked]>
Subject: Re: [ietf-provreg] our meeting slot in SF 
Date: Mon, 3 Mar 2003 14:23:42 -0500
Sender: [email-masked]

:-)

I thought you didnt like the idea... ;-D

And, I think what we want to discuss in this work group is not the actual
"mapping tables", but the framework for doing provisioning.

It has more to do with how the management of reserved variants and zone
variants can be provisioned.

Edmon

----- Original Message -----
From: "Eric Brunner-Williams in Portland Maine" <[email-masked]>
To: "Edmon Chung" <[email-masked]>
Cc: "Rick Wesson" <[email-masked]>; <[email-masked]>; "Edward Lewis"
<[email-masked]>; <[email-masked]>
Sent: Monday, March 03, 2003 1:59 PM
Subject: Re: [ietf-provreg] our meeting slot in SF

> Gosh Edmon, don't forget to mention the utility of adding "$" and other
> neato gizmos to the string-space.
>
> JonnyCa$h.com, JonnyCash.com, really important stuff like that. It isn't
> fair that I'm the only Provreg contributor that you've tried to sell shell
> metacharacters to. Everyone should have a crack at adding reserved regex
> chars to their ASCII-only zone files.
>
> I'm going to miss the dim sum in SF...
>
> Eric
>

To: Eric Brunner-Williams in Portland Maine <[email-masked]>
cc: [email-masked]
Subject: Re: [ietf-provreg] FYI: EPP implementation by the Polish registry 
Date: Mon, 03 Mar 2003 20:13:16 +0100
From: Jaap Akkerhuis <[email-masked]>
Sender: [email-masked]

    	[Category I participation Category I participation is open
    	to businesses and institutions based within the European Union.] 

Oh that. I thought that it was lifted. But it is still completely
irrelevant for the privacy discussion.

    The "us" (parties having the capacity to register domain names on behalf
    of clients) for which "the non-disclose attribute will work" appears to
    be a scoped set of (eventual) EPP participants. The charter for this WG
    is not to create a registry-specific, or regime-specific, or jurisdiction-
    specific, or object-specific protocol.
    
I'm not bringing this up. You are.

    How can a registrar signal in-band to a registry that it accepts
    the general Data Protection framework, and any specific terms
    and conditions?

It doesn't need to. It should first abide to the contract. That is
not-in band.
    
    More generally, how can any two (or more) participants in the
    onward-transport of customer data signal in-band their data
    collection practices, and automate the management of onward-transport?
    
That's not question this group has to answer. The only question is,
what is the proper element in the protocol which help to implement
a policy as been spelled out in the legal framework.

	jaap

To: "Edmon Chung" <[email-masked]>
cc: "Rick Wesson" <[email-masked]>, [email-masked], "Edward Lewis" <[email-masked]>, [email-masked]
Subject: Re: [ietf-provreg] our meeting slot in SF 
Date: Mon, 03 Mar 2003 13:59:37 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

Gosh Edmon, don't forget to mention the utility of adding "$" and other
neato gizmos to the string-space.

JonnyCa$h.com, JonnyCash.com, really important stuff like that. It isn't
fair that I'm the only Provreg contributor that you've tried to sell shell
metacharacters to. Everyone should have a crack at adding reserved regex 
chars to their ASCII-only zone files.

I'm going to miss the dim sum in SF...

Eric

To: Jaap Akkerhuis <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: [ietf-provreg] FYI: EPP implementation by the Polish registry
Date: Mon, 03 Mar 2003 13:52:28 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

> I don't recall the question, at least I don't recognize it. The
> basic answer is no.  There is no requirement for EU residency for
> registars nor registrants. All contracts are under dutch law. To
> force this, there should be a dutch adress to which papers can be
> presented.  But that has nothing to do with privacy apart from the
> fact that the dutch privacy law should be followed by .nl.

See "Deelnemers categorie I", below.

------- Forwarded Message

Delivery-Date: Tue Jan 21 19:48:52 2003
To: Edward Lewis <[email-masked]>
cc: "Hollenbeck, Scott" <[email-masked]>, [email-masked],
   brunner
Subject: Re: [ietf-provreg] where are we with privacy 
Date: Tue, 21 Jan 2003 19:48:51 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>

> I would also like others to comment on Jaap's message and assessment that:

OK, part 2.

> At 13:43 +0100 1/10/03, Jaap Akkerhuis wrote:
> ...
> >So yes, the non-disclose attribute will work for us without any
> >problem. It is possible that we might do extensions to aid with the
> ...
> >
> >	jaap

\begin{quote}
Deelnemers
...
Deelnemer worden
...
Deelnemers categorie I
	Voor het deelnemerschap categorie I komen in aanmerking
	bedrijven in instellingen die zijn gevestigd op het grondgebied
	van de Euorpese Unie.

	[Category I participation Category I participation is open
	to businesses and institutions based within the European Union.] 

	...

	Het deelnemerschap geeft recht tot:

		o het verzorgen van de registratie van domeinnamen ten
		  behoeve van klanten;

	[Category I participants have the following rights:

		o To apply to register domain names on behalf of
		  clients;]
\end{quote}

The "us" (parties having the capacity to register domain names on behalf
of clients) for which "the non-disclose attribute will work" appears to
be a scoped set of (eventual) EPP participants. The charter for this WG
is not to create a registry-specific, or regime-specific, or jurisdiction-
specific, or object-specific protocol.

How can a registrar signal in-band to a registry that it accepts the general
Data Protection framework, and any specific terms and conditions?

More generally, how can any two (or more) participants in the onward-transport
of customer data signal in-band their data collection practices, and automate
the management of onward-transport?

Eric

------- End of Forwarded Message

Date: Mon, 03 Mar 2003 13:50:28 -0500
From: "Ross Wm. Rader" <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>, "'Edward Lewis'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: [ietf-provreg] FYI: EPP implementation by the Polish registry
Sender: [email-masked]

--On Monday, March 03, 2003 1:02 PM -0500 "Hollenbeck, Scott" 
<[email-masked]> mentioned that:

> That being the case, my preference would be to put _all_ of the DNP syntax
> and semantics into an extension (where the problem can be addressed as a
> whole) while making the existing DCP element mandatory

We'd be happy with that as well.

regards,

                       -rwr

"There's a fine line between fishing and standing on the shore like an 
idiot."
- Steven Wright

Get Blog... http://www.byte.org/

To: Eric Brunner-Williams in Portland Maine <[email-masked]>
cc: "Hollenbeck, Scott" <[email-masked]>, "'Edward Lewis'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: [ietf-provreg] FYI: EPP implementation by the Polish registry 
Date: Mon, 03 Mar 2003 19:30:08 +0100
From: Jaap Akkerhuis <[email-masked]>
Sender: [email-masked]

    > One from Jaap - a look at how privacy concerns with .nl impact the issue.
    
    I sent a public message about the .nl requirement to Jaap not long after
    his note on the subject, that the EU residency requirement for registrars
    provided a contractual equivalent to a <dcp> element, and a simpler form
    (for a hypothetical deployment of epp, as .nl wasn't yet epp-operational)
    of whois-token, while sufficient for endpoints within the EU, would not be 
    capable of allowing non-EU endpoints to register .nl domains.
    
    He hasn't responded.

I don't recall the question, at least I don't recognize it. The
basic answer is no.  There is no requirement for EU residency for
registars nor registrants. All contracts are under dutch law. To
force this, there should be a dutch adress to which papers can be
presented.  But that has nothing to do with privacy apart from the
fact that the dutch privacy law should be followed by .nl.

	jaap

From: "Edmon Chung" <[email-masked]>
To: "Rick Wesson" <[email-masked]>
Cc: <[email-masked]>, "Edward Lewis" <[email-masked]>
Subject: Re: [ietf-provreg] our meeting slot in SF
Date: Mon, 3 Mar 2003 13:21:11 -0500
Sender: [email-masked]

It is not about punycode.

It is about the handling of character equivalence preparations (what I call
charprep): i.e. the creation of reserved variants and the management of zone
variants.  These charprep variants need to be generated upon domain creation
and conveyed to the registrant.

Examples of charprep include Traditional Chinese-Simplified Chinese Mapping
and visually identical characters in the LGC (Latin, Greek, Cyrilic) space.

Edmon

----- Original Message -----
From: "Rick Wesson" <[email-masked]>
To: "Edmon Chung" <[email-masked]>
Cc: <[email-masked]>; "Edward Lewis" <[email-masked]>
Sent: Monday, March 03, 2003 1:14 PM
Subject: Re: [ietf-provreg] our meeting slot in SF

>
>
> Edmon,
>
> Since the EPP specs use utf8 why do we need to encode the domains in
> punnycode?
>
> -rick
>
> On Mon, 3 Mar 2003, Edmon Chung wrote:
>
> > I wonder if there might be interest in discussing the topic of IDN/EPP.
I
> > know that Scott's extension guideline already discussed briefly about
it,
> > but it gave no provisions to the handling of character equivlancy
> > preparation (Charprep) issues and the related reserved variants and zone
> > variants management.
> >
> > I dont have a draft yet, but am working on it.  I gave a presentation on
the
> > issues and some experiments that we have done on a possible architecture
for
> > handling the charprep recently (at the APRICOT) and it received very
good
> > response.  I thought it would be a good idea to present it to the group
and
> > get some feedback as I write my draft on the topic.
> >
> > Edmon
> >
> >
> > ----- Original Message -----
> > From: "Edward Lewis" <[email-masked]>
> > To: <[email-masked]>
> > Cc: <[email-masked]>
> > Sent: Friday, February 28, 2003 1:35 PM
> > Subject: [ietf-provreg] our meeting slot in SF
> >
> >
> > > THURSDAY, March 20, 2003
> > > 0900-1130 Morning Sessions
> > > APP     provreg   Provisioning Registry Protocol WG
> > >
> > >
> > > Time to send in agenda suggestions...there are some obvious ones, I
> > > won't disallow anyone from suggesting the obvious. ;)
> > > --
> > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> > > Edward Lewis                                          +1-703-227-9854
> > > ARIN Research Engineer
> > >
> > >
> >
>
>

Date: Mon, 3 Mar 2003 10:14:37 -0800 (PST)
From: Rick Wesson <[email-masked]>
To: Edmon Chung <[email-masked]>
cc: <[email-masked]>, Edward Lewis <[email-masked]>
Subject: Re: [ietf-provreg] our meeting slot in SF
Sender: [email-masked]

Edmon,

Since the EPP specs use utf8 why do we need to encode the domains in
punnycode?

-rick

On Mon, 3 Mar 2003, Edmon Chung wrote:

> I wonder if there might be interest in discussing the topic of IDN/EPP.  I
> know that Scott's extension guideline already discussed briefly about it,
> but it gave no provisions to the handling of character equivlancy
> preparation (Charprep) issues and the related reserved variants and zone
> variants management.
>
> I dont have a draft yet, but am working on it.  I gave a presentation on the
> issues and some experiments that we have done on a possible architecture for
> handling the charprep recently (at the APRICOT) and it received very good
> response.  I thought it would be a good idea to present it to the group and
> get some feedback as I write my draft on the topic.
>
> Edmon
>
>
> ----- Original Message -----
> From: "Edward Lewis" <[email-masked]>
> To: <[email-masked]>
> Cc: <[email-masked]>
> Sent: Friday, February 28, 2003 1:35 PM
> Subject: [ietf-provreg] our meeting slot in SF
>
>
> > THURSDAY, March 20, 2003
> > 0900-1130 Morning Sessions
> > APP     provreg   Provisioning Registry Protocol WG
> >
> >
> > Time to send in agenda suggestions...there are some obvious ones, I
> > won't disallow anyone from suggesting the obvious. ;)
> > --
> > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> > Edward Lewis                                          +1-703-227-9854
> > ARIN Research Engineer
> >
> >
>

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Edward Lewis'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: [ietf-provreg] FYI: EPP implementation by the Polish registry
Date: Mon, 3 Mar 2003 13:02:34 -0500 
Sender: [email-masked]

> >Does ((dnp==1 at .nl) == (dnp==1 at .com)) semantically 
> evaluate to 1, or 0?
> 
> The answer to this is a determining factor (to me at least) of 
> whether $dnp is in the base specification or in an extension.

As far as .com is concerned, I have no doubt that an extension will be
required even if we were to adopt the IESG's element tagging suggestion.
That being the case, my preference would be to put _all_ of the DNP syntax
and semantics into an extension (where the problem can be addressed as a
whole) while making the existing DCP element mandatory if that resolves the
privacy issue with the IESG.

-Scott-

From: "Edmon Chung" <[email-masked]>
To: <[email-masked]>, "Edward Lewis" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: [ietf-provreg] our meeting slot in SF
Date: Mon, 3 Mar 2003 13:08:20 -0500
Sender: [email-masked]

I wonder if there might be interest in discussing the topic of IDN/EPP.  I
know that Scott's extension guideline already discussed briefly about it,
but it gave no provisions to the handling of character equivlancy
preparation (Charprep) issues and the related reserved variants and zone
variants management.

I dont have a draft yet, but am working on it.  I gave a presentation on the
issues and some experiments that we have done on a possible architecture for
handling the charprep recently (at the APRICOT) and it received very good
response.  I thought it would be a good idea to present it to the group and
get some feedback as I write my draft on the topic.

Edmon

----- Original Message -----
From: "Edward Lewis" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, February 28, 2003 1:35 PM
Subject: [ietf-provreg] our meeting slot in SF

> THURSDAY, March 20, 2003
> 0900-1130 Morning Sessions
> APP     provreg   Provisioning Registry Protocol WG
>
>
> Time to send in agenda suggestions...there are some obvious ones, I
> won't disallow anyone from suggesting the obvious. ;)
> --
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Edward Lewis                                          +1-703-227-9854
> ARIN Research Engineer
>
>

To: Edward Lewis <[email-masked]>
cc: "[email-masked]'" <[email-masked]>, [email-masked]
Subject: Re: [ietf-provreg] FYI: EPP implementation by the Polish registry 
Date: Mon, 03 Mar 2003 12:49:20 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

> The latter case - "newbie" is rather derogatory term.

>From <[email-masked]> 

> I am a newbie of this group and of the IETF WGs in general (please
> pardon me for anything inappropriate I might unvoluntarily do).
> However, I have been discussing DNS privacy issues extensively in the
> last years, so please allow me to give my point of view on the ongoing
> privacy discussion.

Note.

> Not addressing the privacy issue in the base protocol would likely
> imply that the service would often be deployed in real life without
> any means to achieve privacy protection.

Agree.

>                                           Unfortunately, the present
> lack of privacy protection in the WHOIS system is plainly illegal in
> many countries, and I don't think it's reasonable to think that this
> situation can go on for long without actual lawsuits starting to
> happen, both towards ccTLD and gTLD registries and registrars. 

Not relevant for a provisioning protocol. Specific to a particular
post-provisioned publication protocol, and none of us should be playing
lawyer on the net.

Its mechanism, mechanism, mechanism, mechanism, mechanism, mechanism and
once more for emphesis, mechanism.

Now I'll go back to my screw driver and duct tape, cause three years
working http-state, onward-transport, and provisioning just haven't
left me with clue parity with jrandom Euros.

I'll send a write up of where we are to the P3P list, we (I've now got
a spiffy "P3P hat" on) have a meeting this Friday. At this point though,
it looks as if the W3C is going one way, and the IETF is going another.
XML on the one hand, and a binary token on the other.

Eric

Date: Mon, 3 Mar 2003 11:39:56 -0500
To: "[email-masked]'" <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: Re: [ietf-provreg] FYI: EPP implementation by the Polish registry
Sender: [email-masked]

At 10:47 -0500 3/3/03, Eric Brunner-Williams in Portland Maine wrote:
>Note Bene Chair:
>	1. IESG (Randy or Allison) asked and answered
>	2. IESG (Patrick) asked and answered
>	3. .NL asked and not responsive
>	4. .PL asked and not responsive
>	5. Newbie noises

I should respond to earlier parts of the mail, but I'll pick on this first.

As far as 1 & 2, the IESG has taken the first step the responsible 
guardian.  I have to admit, however, that the detail I have obtained 
from them has been insufficient to evaluate any proposed solution as 
being "the right one."  I do not dispute the spirit of the IESG 
comments, I just wish that the comments were supported by more 
substance, as could be provided by 3 & 4.

I cannot speak as to why 3 & 4 were not responsive.  But these 
categories represent an important voice that I think needs to be 
heard.  I was looking to such a constituency to give more information 
on what the IESG is hinting we need, but I haven't been able to 
introduce any discussion in this way.

(I should add that I am not so disappointed that 3 and 4 haven't 
responded, I am more disappointed that there haven't been other 
organizations of similar ilk saying anything at all.  Yes, that's a 
generalization - and the IETF is supposed to be individual 
participation, but the list needs to hear folks with knowledge of 
other environments to help pound out a solution to this issue.)

The latter case - "newbie" is rather derogatory term.  Whether or not 
any one person agrees/disagrees with the words uttered, comments of 
this ilk (when on topic) are good to hear.  The IETF isn't about 
making protocols that implementors agree to - it's about making 
interoperable useful protocols.

>Does ((dnp==1 at .nl) == (dnp==1 at .com)) semantically evaluate to 1, or 0?

The answer to this is a determining factor (to me at least) of 
whether $dnp is in the base specification or in an extension.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

To: "Hollenbeck, Scott" <[email-masked]>
cc: "'Edward Lewis'" <[email-masked]>, "[email-masked]'" <[email-masked]>, [email-masked]
Subject: Re: [ietf-provreg] FYI: EPP implementation by the Polish registry 
Date: Mon, 03 Mar 2003 10:47:52 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

> why do domain/contact/.. not have granular information about privacy?

Asked and answered.

1. Because operationally, policing at the session level is sufficient to
support persistent policing across multiple distinct objects, or support
single-object-session policing.

2. Because syntactically, if epp is to remain extensible, and xml-based,
adding attributes to elements is either pervasive, or specific. As this
WG lost the technical/social distinction with the expiry of Ross' draft,
we don't have a handy hook for being "specific", and "pervasive" makes
conditionally "private" even the data the registrants who have standing
to "privacy" under EU framework UNCONDITIONALLY SEEK TO PUBLISH.

3. Because semantically, it isn't simply contemporanious publication via
954 that is of issue, particularly in the EU, but also in the OEDC, and
potentially even the US. Also required is some mechanism to identify the
repurposing of registrant (and registrar) data, as bulk-access is a real
practice, with abuses. Also required is some mechanism to identify the
availability of collected registrant (and registrar) data for correction.
Also required is some mechanism to identify the duration that data is
held by the collector.

Adding these semantics to complexType elements would be complex, and has
no benefit over attaching the same semantics to aggregations of elements
that are NEVER DISAGGREGATED, aka "objects". There is little observed or
hypothetical inter-object disaggregation of policy that cannot be reasonably,
and scalably met, by bounding sessions by policy discontinuity.

See #1, above.

Ops, syn, sem, all covered.

> In a later discussion with Patrik, I was told that the EPP proposal 
> did not meet the requirement in Section 8.4 of RFC 3375. ("See the 
> MUST part of [1].")

I wrote the requirement. The mechanism is the <dcp>, and it is provided by
the protocol.

The requirement does not state:

  The protocol MUST NOT provide services if data collection policies
  are not identified.

If it had, then we'd have had <dcp> (or some other mechanism(s)) as
MANDITORY-TO-IMPLEMENT, rather than OPTIONAL. There was WG consensus that
the <dcp> is in the core schema (epp-1.0.xsd), optional to implement, and
not an optional extension.

> There are three other inputs. 

> One from Jaap - a look at how privacy concerns with .nl impact the issue.

I sent a public message about the .nl requirement to Jaap not long after
his note on the subject, that the EU residency requirement for registrars
provided a contractual equivalent to a <dcp> element, and a simpler form
(for a hypothetical deployment of epp, as .nl wasn't yet epp-operational)
of whois-token, while sufficient for endpoints within the EU, would not be  
capable of allowing non-EU endpoints to register .nl domains.

He hasn't responded.

> The second is a report and discussion on the .pl work in this area. 

I send a public message about the decision of this particular implementor
not to use the <dcp>.

I seem to have missed the response.

> The third is a message describing the EU perspective on why this must
> be solved.

Oh thank heavens! A live EU national who is a self-described "newbie" and
neither an implementor, nor an operator, nor an author, nor apparently a
specification reader. Now I can stop thinking.

Note Bene Chair:
	1. IESG (Randy or Allison) asked and answered
	2. IESG (Patrick) asked and answered
	3. .NL asked and not responsive
	4. .PL asked and not responsive
	5. Newbie noises

What part of IETF process did I miss in IETF grade school back in the
mid-80s?

I don't actually mind if folks creatively craft into "privacy" some form
of market protection, Europe for the Europeans, Africa for the Africans,
Circumpolar Regions for the Very-Well-Dressed. I simply find it amusing
that on the one hand we've people in the IAB/IESG kicking Chinese Butt
big time for attempting to fix Unicode [1], arguing "minimum astonishment"
as if it were an end-to-end principle, and people with the same, or very
similar drinking buddies, arguing that the semanitcs of "{0,1} are context
dependent.

Does ((dnp==1 at .nl) == (dnp==1 at .com)) semantically evaluate to 1, or 0?

I'm always astonished that packets even make it anywhere.

Eric

[1] Yes Virginia, the new IRTF activity specifically BARS the work by the
Joint Engineering Team (.tw/.cn/.kr/.jp) registries and the Chinese Domain
Name Consortium (.tw/.hk/.ma/.cn) on intermediate mappings in particular,
and constructive mechanism in general. I've asked. Twice. Not for IPR reasons
either.

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Edward Lewis'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: [ietf-provreg] FYI: EPP implementation by the Polish registry
Date: Mon, 3 Mar 2003 09:01:53 -0500 
Sender: [email-masked]

> I suppose this isn't the concise message you were hoping for, but I'd 
> rather the WG figure this out rather than have me spoon feed it to 
> you.  E.g., the comment that we don't meet the requirement above was 
> answered by me in a thread with an IESG member that ultimately went 
> no where.  (Maybe someone else needs to try.)

I sent a private message about the DCP requirement to Patrik last Thursday
or Friday.  He hasn't yet responded.

-Scott-

Date: Mon, 3 Mar 2003 08:23:43 -0500
To: "[email-masked]'" <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: RE: [ietf-provreg] FYI: EPP implementation by the Polish registry
Sender: [email-masked]

At 14:52 -0800 2/28/03, Rick Wesson wrote:
>Ed,
>
>The private discussion the wg chairs have had with the IESG have prevented
>this group from moving forward; therefore I request all communication
>between the IESG and the wg chairs also CC the list.

???  "Prevented" is certainly not the right word.

>We have experenced 4 month delay because of this situation and it is
>unacceptable. We still are in a state of limbo.

Instead of trying to find fault, there should be an offering of 
suggestions.  All of the needed data exist in the archives.

>ed, please restate the issues, proposed solutions, wg consensus (if any
>appears evident) and iesg issues in a single concise e-mail to this wg
>so we can at the very least understand where we are in this process, and
>how we can move it forward.

The IESG comment given during the fall (message dated "Tue, 15 Oct 
2002 11:16:53 +0200"):

       why do domain/contact/.. not have granular information about privacy?

In a later discussion with Patrik, I was told that the EPP proposal 
did not meet the requirement in Section 8.4 of RFC 3375. ("See the 
MUST part of [1].")

There are three other inputs.  One from Jaap - a look at how privacy 
concerns with .nl impact the issue.  The second is a report and 
discussion on the .pl work in this area.  The third is a message 
describing the EU perspective on why this must be solved.

First message: Fri, 10 Jan 2003 13:43:22 +0100
Second message: Sat, 01 Feb 2003 18:51:49 +0100, with a followup
                 Tue, 11 Feb 2003 08:30:20 -0500 by Scott Hollenbeck
Third message: Fri, 17 Jan 2003 11:03:26 +0100, Vittorio Bertola

As far as a summary, there's a message dated "Sun, 19 Jan 2003 
21:00:15 -0500" that I sent out, with an ensuing thread.

In the above are proposed solutions, as well as the dcp as it sits in 
the base specification.

The consensus of the WG (or those participating actively on the list) 
is that privacy is too ill defined to put in the base specification. 
I get the feeling from the IESG that thinks the set of those reaching 
this consensus is not representative enough of the Internet in 
general, but this is just a feeling.  (Who out there is not 
engineering to the environment of the shared registry model?  Who is 
engineering toward an independent registry environment?  Are we 
representative of the Internet as a whole?)

I suppose this isn't the concise message you were hoping for, but I'd 
rather the WG figure this out rather than have me spoon feed it to 
you.  E.g., the comment that we don't meet the requirement above was 
answered by me in a thread with an IESG member that ultimately went 
no where.  (Maybe someone else needs to try.)

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

To: Edward Lewis <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: [ietf-provreg] our meeting slot in SF 
Date: Mon, 03 Mar 2003 07:21:00 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

This is an issue-reminder, assuming that the IESG is responsive on the
privacy/data colleciton issue.

mappings over transports other than tcp.

The IESG claim is that commands cannot be reordered, which seems to be
reasonable for the transformational subset of epp commands, but not the
informational subset of epp commands, and this "resonability" appers to
be limited to com/net/org/info/biz/name transactions. Email is used, as
a transport for XML and BNF, elsewhere. Non-interoperation by intent is
an odd proposition, particularly by non-implementors and non-operators.

The IESG claim is also that applications protocols must provide congestion
control. I'm afraid this new requirement seems reflexive, not the product
of actual reflection on the deployment of epp. The publication protocols
commonly in use with registry provisioning include UDP, with absurdly large
difference in scale. Connectionism by design is an odd proposition too,
again by non-implementors and non-operators. It would be reasonable if this
work were within the ITU, which is both connectionist and mandarinist.

Just out of curiosity, since whois is such a problem, why on earth is the
inferred provisioning of social data to the com/net/org et alia whois
servers not _historic_? The US DCA is very, very, dead as an Agency of
Notice or Fashion.

Eric

From: "Ram Mohan" <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>, "'Edward Lewis'" <[email-masked]>, <[email-masked]>
Subject: Re: [ietf-provreg] our meeting slot in SF
Date: Fri, 28 Feb 2003 22:47:21 -0500
Organization: Afilias
Sender: [email-masked]

amen

-ram
----- Original Message -----
From: "Hollenbeck, Scott" <[email-masked]>
To: "'Edward Lewis'" <[email-masked]>; <[email-masked]>
Sent: Friday, February 28, 2003 2:20 PM
Subject: RE: [ietf-provreg] our meeting slot in SF

> > THURSDAY, March 20, 2003
> > 0900-1130 Morning Sessions
> > APP     provreg   Provisioning Registry Protocol WG
> >
> >
> > Time to send in agenda suggestions...there are some obvious ones, I
> > won't disallow anyone from suggesting the obvious. ;)
>
> OK, then how about putting a slot in to get to the bottom of addressing
the
> IESG privacy comment -- assuming we can get the needed IESG members in the
> room to get it settled.
>
> -Scott-
>
>

To: "Hollenbeck, Scott" <[email-masked]>
cc: "'Edward Lewis'" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [ietf-provreg] our meeting slot in SF 
Date: Fri, 28 Feb 2003 22:06:35 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

I second Scott's suggestion, though in the general sense that getting some
substantive response from the IESG is in theory better than not getting a
substantive response, as I won't attend the face-to-face meeting of some
of the working group. I don't personally care if a member of the current
IESG contributes in an individual capacity, or if the IESG sits en banc,
during the scheduled face-to-face, though I appreciate those who've worked
on this set of drafts over the past two years who are present at this
meeting have a keener interest in the time and place some eventual disclosure
is offered.
  
Eric

Date: Fri, 28 Feb 2003 18:25:43 -0500
Subject: Re: [ietf-provreg] FYI: EPP implementation by the Polish registry
Cc: Andrew Newton <[email-masked]>, Edward Lewis <[email-masked]>, "[email-masked]'" <[email-masked]>, [email-masked]
To: Rick Wesson <[email-masked]>
From: Andrew Newton <[email-masked]>
Sender: [email-masked]

On Friday, February 28, 2003, at 05:52 PM, Rick Wesson wrote:

>
> Ed,
>
> The private discussion the wg chairs have had with the IESG have 
> prevented
> this group from moving forward; therefore I request all communication
> between the IESG and the wg chairs also CC the list.

I don't know how you know the private discussions have prevented this 
WG from moving forward, but I'm guessing that it is not true.  PROVREG 
should use the same procedures used by all IETF working groups.  And if 
they aren't working out, then perhaps it should be addressed in a 
broader manner.  Perhaps this would be good input for the problem 
statement work currently in motion.

>
> We have experenced 4 month delay because of this situation and it is
> unacceptable. We still are in a state of limbo.
>

I agree.  Lack of forward motion is frustrating.

> ed, please restate the issues, proposed solutions, wg consensus (if any
> appears evident) and iesg issues in a single concise e-mail to this wg
> so we can at the very least understand where we are in this process, 
> and
> how we can move it forward.
>
This sounds like a good idea.

-andy