RE: [ietf-provreg] provreg wg responses to IESG comments

["Hollenbeck, Scott" <[e-mail]>]

> I understand your position on the core protocol, however we 
> only have one
> use of the core protocol -- domains. We also loose nothing by 
> removing the
> language but loose a lot by retaining it.
> 
> lets drop the marketing language.

I don't think we lose anything by retaining the text (which doesn't say
"we're allowing and encouraging contact for marketing purposes"), and we
lose a lot by softening it.

I don't understand your objection to explicitly disclosing that a server
operator will use data for marketing contact purposes -- if some repository
intends to use data that way, you're suggesting that the protocol not note
it explicitly.  I think softening the text makes this use scenario much less
obvious, taking away an obvious red flag opportunity.  I'd personally prefer
to know up front if I'm dealing with a potential spammer or telephone
solicitor.

By the way, I think you had a typo in your suggested replacement text:

> <contact/>: Contact information not restricted by contact,
> though other AUP may apply

What does "Contact information not restricted by contact" mean?  Plus,
saying "other AUP may apply" only begs the question of "what other AUP?",
and right now we have no way of distributing or announcing acceptable use
policies.

I think it's important to be up front with the purpose of this element,
which is to disclose that data might be used to contact individuals for
marketing purposes.  Softening the text to make this less obvious sounds
like a bad move to me.  It might help me understand where you're coming from
if you explain why you think that disclosing direct marketing practices is a
bad idea.

-Scott-



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3UGsWRN023871 for <[e-mail]>; Wed, 30 Apr 2003 18:54:33 +0200 (MEST)
Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h3UGsW22023870 for ietf-provreg-outgoing; Wed, 30 Apr 2003 18:54:32 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.237.102]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3UGsVRN023865 for <[e-mail]>; Wed, 30 Apr 2003 18:54:32 +0200 (MEST)
Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [10.170.12.38]) by heron.verisign.com (8.12.9/8.12.9) with ESMTP id h3UGtoaj019260; Wed, 30 Apr 2003 12:55:50 -0400 (EDT)
Received: by vsvapostalgw1.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <J8TV8G6J>; Wed, 30 Apr 2003 12:52:37 -0400
Message-ID: <5BEA6CDB196A4241B8BE129D309AA4AF10E70D@vsvapostal8>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Rick Wesson'" <[e-mail]>
Cc: Edward Lewis <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail]
Subject: RE: [ietf-provreg] provreg wg responses to IESG comments
Date: Wed, 30 Apr 2003 12:52:38 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

> I understand your position on the core protocol, however we 
> only have one
> use of the core protocol -- domains. We also loose nothing by 
> removing the
> language but loose a lot by retaining it.
> 
> lets drop the marketing language.

I don't think we lose anything by retaining the text (which doesn't say
"we're allowing and encouraging contact for marketing purposes"), and we
lose a lot by softening it.

I don't understand your objection to explicitly disclosing that a server
operator will use data for marketing contact purposes -- if some repository
intends to use data that way, you're suggesting that the protocol not note
it explicitly.  I think softening the text makes this use scenario much less
obvious, taking away an obvious red flag opportunity.  I'd personally prefer
to know up front if I'm dealing with a potential spammer or telephone
solicitor.

By the way, I think you had a typo in your suggested replacement text:

> <contact/>: Contact information not restricted by contact,
> though other AUP may apply

What does "Contact information not restricted by contact" mean?  Plus,
saying "other AUP may apply" only begs the question of "what other AUP?",
and right now we have no way of distributing or announcing acceptable use
policies.

I think it's important to be up front with the purpose of this element,
which is to disclose that data might be used to contact individuals for
marketing purposes.  Softening the text to make this less obvious sounds
like a bad move to me.  It might help me understand where you're coming from
if you explain why you think that disclosing direct marketing practices is a
bad idea.

-Scott-


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3UGLIRN023523 for <[e-mail]>; Wed, 30 Apr 2003 18:21:18 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h3UGLIjC023522 for ietf-provreg-outgoing; Wed, 30 Apr 2003 18:21:18 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from bean.ar.com (bean.ar.com [66.123.187.68]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3UGLGRN023517 for <[e-mail]>; Wed, 30 Apr 2003 18:21:17 +0200 (MEST)
Received: from flash.ar.com (wessorh@flash [66.123.187.80]) by bean.ar.com (8.12.6/8.12.6) with ESMTP id h3UGL8dX019613; Wed, 30 Apr 2003 09:21:09 -0700 (PDT)
Date: Wed, 30 Apr 2003 09:21:08 -0700 (PDT)
From: Rick Wesson <[e-mail]>
To: "Hollenbeck, Scott" <[e-mail]>
cc: Edward Lewis <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: [ietf-provreg] provreg wg responses to IESG comments
In-Reply-To: <5BEA6CDB196A4241B8BE129D309AA4AF10E6FC@vsvapostal8>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

I understand your position on the core protocol, however we only have one
use of the core protocol -- domains. We also loose nothing by removing the
language but loose a lot by retaining it.

lets drop the marketing language.

thanks,

-rick



On Wed, 30 Apr 2003, Hollenbeck, Scott wrote:

> Rick,
>
> Remember that the DCP is included in the core protocol, so the features
> included have to address use scenarios that go beyond the domain name world.
> I can easily envision situations where the potential for marketing contact
> exists when provisioning objects other than domain names, so I believe the
> text should remain as-is -- even if it won't necessarily apply to domain
> name provisioning.
>
> -Scott-
>
> > -----Original Message-----
> > From: Rick Wesson [mailto:[e-mail]]
> > Sent: Monday, April 28, 2003 4:30 PM
> > To: Edward Lewis
> > Cc: [e-mail]; [e-mail]; [e-mail];
> > [e-mail]
> > Subject: Re: [ietf-provreg] provreg wg responses to IESG comments
> >
> >
> >
> > wow, its amazing that this process works sometimes, ant to
> > all those that
> > have worked on the documents, and especially scott, a hearty
> > thank you.
> >
> > i do still have one issue with the language "for marketing purposes"
> >
> > I know of no AUP under any TLD that allows a contact to be
> > used for ANY
> > marketing purpose, and as suck I request this language be changed to
> >
> > <contact/>: Contact information not restricted by contact,
> > though other
> > AUP may apply.
> >
> > also specificly strike "for the promotion of a product or service."
> >
> > no registry has ever allowed this and most specificly prevent
> > such, this
> > doesn't be long in an RFC.
> >
> > I know all the above was unintentional and i'm sure once you
> > think about
> > it you'll agree too.
> >
> >
> > best,
> >
> > -rick
> >
> >
> >
> > On Mon, 28 Apr 2003, Edward Lewis wrote:
> >
> > >
> > > 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.".
> > >
> >
>



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3UBjbRN020555 for <[e-mail]>; Wed, 30 Apr 2003 13:45:37 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h3UBjbBi020554 for ietf-provreg-outgoing; Wed, 30 Apr 2003 13:45:37 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.237.102]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3UBjZRN020549 for <[e-mail]>; Wed, 30 Apr 2003 13:45:36 +0200 (MEST)
Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [10.170.12.38]) by heron.verisign.com (8.12.9/8.12.9) with ESMTP id h3UBkpaj002739; Wed, 30 Apr 2003 07:46:51 -0400 (EDT)
Received: by vsvapostalgw1.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <J8TV775A>; Wed, 30 Apr 2003 07:43:38 -0400
Message-ID: <5BEA6CDB196A4241B8BE129D309AA4AF10E6FC@vsvapostal8>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Rick Wesson'" <[e-mail]>, Edward Lewis <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail], [e-mail]
Subject: RE: [ietf-provreg] provreg wg responses to IESG comments
Date: Wed, 30 Apr 2003 07:43:30 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Rick,

Remember that the DCP is included in the core protocol, so the features
included have to address use scenarios that go beyond the domain name world.
I can easily envision situations where the potential for marketing contact
exists when provisioning objects other than domain names, so I believe the
text should remain as-is -- even if it won't necessarily apply to domain
name provisioning.

-Scott-

> -----Original Message-----
> From: Rick Wesson [mailto:[e-mail]]
> Sent: Monday, April 28, 2003 4:30 PM
> To: Edward Lewis
> Cc: [e-mail]; [e-mail]; [e-mail];
> [e-mail]
> Subject: Re: [ietf-provreg] provreg wg responses to IESG comments
> 
> 
> 
> wow, its amazing that this process works sometimes, ant to 
> all those that
> have worked on the documents, and especially scott, a hearty 
> thank you.
> 
> i do still have one issue with the language "for marketing purposes"
> 
> I know of no AUP under any TLD that allows a contact to be 
> used for ANY
> marketing purpose, and as suck I request this language be changed to
> 
> <contact/>: Contact information not restricted by contact, 
> though other
> AUP may apply.
> 
> also specificly strike "for the promotion of a product or service."
> 
> no registry has ever allowed this and most specificly prevent 
> such, this
> doesn't be long in an RFC.
> 
> I know all the above was unintentional and i'm sure once you 
> think about
> it you'll agree too.
> 
> 
> best,
> 
> -rick
> 
> 
> 
> On Mon, 28 Apr 2003, Edward Lewis wrote:
> 
> >
> > 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.".
> >
> 


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3SKUNRN026275 for <[e-mail]>; Mon, 28 Apr 2003 22:30:23 +0200 (MEST)
Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h3SKUNsh026274 for ietf-provreg-outgoing; Mon, 28 Apr 2003 22:30:23 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from bean.ar.com (bean.ar.com [66.123.187.68]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3SKULRN026269 for <[e-mail]>; Mon, 28 Apr 2003 22:30:22 +0200 (MEST)
Received: from flash.ar.com (wessorh@flash [66.123.187.80]) by bean.ar.com (8.12.6/8.12.6) with ESMTP id h3SKUHdX019323; Mon, 28 Apr 2003 13:30:17 -0700 (PDT)
Date: Mon, 28 Apr 2003 13:30:15 -0700 (PDT)
From: Rick Wesson <[e-mail]>
To: Edward Lewis <[e-mail]>
cc: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: Re: [ietf-provreg] provreg wg responses to IESG comments
In-Reply-To: <a05111b02bad2d71131b5@[192.136.136.76]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

wow, its amazing that this process works sometimes, ant to all those that
have worked on the documents, and especially scott, a hearty thank you.

i do still have one issue with the language "for marketing purposes"

I know of no AUP under any TLD that allows a contact to be used for ANY
marketing purpose, and as suck I request this language be changed to

<contact/>: Contact information not restricted by contact, though other
AUP may apply.

also specificly strike "for the promotion of a product or service."

no registry has ever allowed this and most specificly prevent such, this
doesn't be long in an RFC.

I know all the above was unintentional and i'm sure once you think about
it you'll agree too.


best,

-rick



On Mon, 28 Apr 2003, Edward Lewis wrote:

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



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3SI4JRN024887 for <[e-mail]>; Mon, 28 Apr 2003 20:04:19 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h3SI4IZj024886 for ietf-provreg-outgoing; Mon, 28 Apr 2003 20:04:18 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from smtp2.arin.net (smtp2.arin.net [192.149.252.32]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3SI4HRN024881 for <[e-mail]>; Mon, 28 Apr 2003 20:04:17 +0200 (MEST)
Received: by smtp2.arin.net (Postfix, from userid 5003) id 88846405; Mon, 28 Apr 2003 14:04:16 -0400 (EDT)
Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id 4415B42B; Mon, 28 Apr 2003 14:04:15 -0400 (EDT)
Received: from [127.0.0.1] (HELO [66.44.64.217]) by arin.net (CommuniGate Pro SMTP 4.0.6) with ESMTP id 200480; Mon, 28 Apr 2003 13:53:54 -0400
Mime-Version: 1.0
X-Sender: edlewis@127.0.0.1 (Unverified)
Message-Id: <a05111b02bad2d71131b5@[192.136.136.76]>
Date: Mon, 28 Apr 2003 14:04:11 -0400
To: [e-mail], [e-mail]
From: Edward Lewis <[e-mail]>
Subject: [ietf-provreg] provreg wg responses to IESG comments
Cc: Edward Lewis <[e-mail]>, [e-mail], [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Status: No, hits=-1.3 required=5.0 tests=AWL,SIGNATURE_SHORT_SPARSE,SPAM_PHRASE_00_01 version=2.43-arin1
X-Spam-Level: 
Sender: [e-mail]
Precedence: bulk

About this message:

The original form of this note is written by Scott Hollenback.  I've 
updated it based on our further work on one comment and the addition 
of host attributes which is summarized after the IESG comment 
responses.

  - - -

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

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

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

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

Here are the references to the IESG comments (part I) 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 and the addition of a disclose element.  Making <dcp> mandatory
is documented in the EPP base document, descriptive text in section 2.3
and in the schema in section 4.1.

The definition of the <disclose> element appears in the contact mapping
document, first appearing in section "2.9 Disclosure of Data Elements 
and Attributes" with modifications to sections 3.1.2, 3.2.1, and 
3.2.5.  In
section 3.1.2, the <authInfo> element is added to <info> command so 
that authorization decisions can be made when disclosure elements are 
also provided.

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

http://www.cafax.se/ietf-provreg/maillist/2003-04/msg00116.html and 
follow ups to that message.

IESG comments, part 2, as in the following URL:
   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.

  ----------------------------Other Edits------------------------------

Due to comments received by the chairs off list, the WG revisited the issue
of hosts-as-attributes instead of host objects.  The reason for revisiting
this issue at such a late date is the increasingly widespread review 
of the EPP documents by individuals.

http://www.cafax.se/ietf-provreg/maillist/2003-04/msg00051.html

The WG has adopted the the option of including hosts (name servers) 
as attributes on domain objects as a mutually exclusive option to 
host objects.  As part of this, address data is also permitted but no 
other DNS data.  These
changes appear in the domain mapping document, first at the end of 
section 1.1 to describe new provisions.  Also, modified schema and 
text appear in sections 3.1.2, 3.2.1, and 3.2.5.  In the new section 
"2.7 Other DNS Resource Record Attributes" contains a discussion that 
limits DNS data to just addresses.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            [phone]
ARIN Research Engineer

A compiler-directive person living in an HTML-tagged world.


Return-Path: <[e-mail]>
Received: from sina.com.tw (TC218-187-135-150.adsl.pl.apol.com.tw [218.187.135.150]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3R7FeRN009044 for <[e-mail]>; Sun, 27 Apr 2003 09:15:42 +0200 (MEST)
Message-Id: <[e-mail]>
From: [e-mail]
Subject: ¥xÆW¥v¤Wªº³ÐÁ|
Reply-To: [e-mail]
Date: 27 Apr 2003 15:08:56 +0800
Organization: Foobar Inc.
X-Mailer: Gammadyne Mailer
x-delete-me: 1 (this tells Gammadyne's server to delete the message)
MIME-Version: 1.0
Content-Type: text/html
Content-Transfer-Encoding: 8bit

<html>

<head>
<meta http-equiv="Content-Language" content="zh-tw">
<meta name="GENERATOR" content="Microsoft FrontPage 4.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<meta http-equiv="Content-Type" content="text/html; charset=big5">
<title>±z¬O¤U­±¨º¤@¨º¤@ºØ¨­¥÷</title>
<bgsound src="http://140.114.79.84:7000/midi/foreign/latin/reloj.mid" loop="1">
</head>

<body>

<div style="background-color: #FFCC00; background-image: url('http://scort.org..tw~tp40/pic/m-flower.gif'); background-repeat: repeat-x; border-style: outset; border-width: 4">
  <div style="width: 728; height: 78; background-color: #FFCC00; background-image: url('http://www.scout.org.tw/~tp40/pic/m-flower.gif'); background-repeat: repeat-x; background-position: medium 50%">
  <p align="center">¡@</p>
  </div>
  <p>¡@</p>
  <p><span style="background-color: #FFCC00"><font face="µØ±dÄײʶê" size="6">±z</font><font face="µØ±dÄײʶê" size="4">¬O¤U­±¨º¤@¨º¤@ºØ¨­¥÷¡G</font></span></p>
  <p><span style="background-color: #FFCC00"><font face="µØ±dÄײʶê" size="4">¡@</font><font size="4" face="¼Ð·¢Åé">¡@<b>¢°.¬O¤@¦ì</b></font><font face="¼Ð·¢Åé"><b><a href="http://home.kimo.com.tw/amityydimon/joinus.asp.htm"><font color="#800000" style="font-size: 15pt">·QÁÈ¿úªº¾Ç¥Í</font></a></b></font><font size="4" face="¼Ð·¢Åé">¡A<b>«o¥u¯àÁȨì¨C¤p®É70¡ã100ªº®ÉÁ~¡A²Ö¿n¤£¤F°]´I¡C</b></font></span></p>
  <p><span style="background-color: #FFCC00"><font face="¼Ð·¢Åé" size="4">¡@¡@<b>¢±.¬O¤@¦ì</b></font><font face="¼Ð·¢Åé"><b><a href="http://home.kimo.com.tw/amityydimon/joinus.asp.htm"><font color="#800000" style="font-size: 15pt">¤W¯Z±Ú</font></a></b></font><font face="¼Ð·¢Åé" size="4">¡A<b>¨C¤Ñ¥´¥d¡¨¤W¡¨¡¨¤U¡¨¯Z¡A­è¦n¥d¦b¨º¸Ì¡A¤S¾á¤ß³Qµô­û¡C</b></font></span></p>
  <p><span style="background-color: #FFCC00"><font face="¼Ð·¢Åé" size="4">¡@¡@<b>¢².¬O¤@¦ì·QÀ°®a®x¦hÁȨǿú¡A¨Ó¬°®a®xºÉ¤ßºÉ¤Oªº</b></font><font face="¼Ð·¢Åé"><b><a href="http://home.kimo.com.tw/amityydimon/joinus.asp.htm"><font color="#800000" style="font-size: 15pt">®a®x¥D°ü</font></a></b></font><b><font face="¼Ð·¢Åé" size="4">¡C</font></b></span></p>
  <p align="left"><span style="background-color: #FFCC00">
  <font size="4" face="µØ±d·¢®ÑÅéW5"><b>¡@¡@¡@ ¦pªG§A¯uªº·Q¼W¥[¦¬¤J¡A¤S¨ã³Æ¤F¤@¨Ç¹q¸£ªº°ò¦</b>¡I</font></span></p>
  <p align="left"><span style="background-color: #FFCC00"><font face="¼Ð·¢Åé"><b>
  <font color="#FF0000" size="5">&nbsp;&nbsp;&nbsp;&nbsp; ¨º»ò®¥³ß±z¡I</font></b></font><b><font face="¼Ð·¢Åé" size="4" color="#FF0000">³o±N·|¬O±z³Ì¦nªº¾÷·|¡I</font></b></span></p>     
  <p><span style="background-color: #FFCC00"><font face="µØ±dÄײʶê" size="6">±z</font><font face="µØ±dÄײʶê" size="4">ª¾¹D¶Ü¡H</font></span></p>
  <p><span style="background-color: #FFCC00">
  <font face="µØ±dÄײʶê" size="4" color="#FFFFFF">¡@¡@­ì¨Ó¶R¤ú»I¡A¥Î½Ã¥Í¯È¡A¤]¯à²Ö¿n°]´I¡I¦A°t¤W±M·~ªººô¸ô¦æ¾P¤è¦¡¡I</font></span><font size="4" face="µØ±dÄײʶê" color="#FFFFFF">µ´¹ï¤ÞÃz¥«³õ¡I</font></p>
  <p>¡@</p>
  <p align="center"><span style="background-color: #FFCC00">
  <font face="µØ±dÄײʶê" size="5">
  <a href="http://home.kimo.com.tw/amityydimon/joinus.asp.htm">§Ú·Q¬Ý¶R¤ú»I¤Î¥Î½Ã¥Í¯ÈÁÈ¿úªº¼v¤ù</a></font></span></p>
  <p align="center"><span style="background-color: #FFCC00">
  <font color="#FFFF00">&nbsp;</font><b><font color="#CC0099" face="µØ±dÄ׶®§º" size="5"><a href="http://home.kimo.com.tw/amityydimon"><font color="#CC0099">§Ú­n¶i¤@¨B¤F¸Ñ</font></a></font></b></span></p>
  <p align="center">
  <img border="0" src="http://ruzunet.myrice.com/0328.gif" width="45" height="52"><span style="background-color: #FFCC00"><b><font color="#800000" face="µØ±dÄ׶®§º" size="5"><a href="http://home.kimo.com.tw/amityydimon/joinus.asp.htm">§Ú­nÁÈ¿ú¡A½Ð±zÁpµ¸§Ú¡I</a></font></b></span></p>
  <p align="center">¡@</div>
<p align="center"><b><img border="0" src="http://www.scout.org.tw/~tp40/pic/m-java.gif" width="64" height="64"><font size="4"><a href="http://home.kimo.com.tw/amityydimon">¤F¸Ñ¬O¤£¥Îªá¿úªº!!</a></font></b>¾÷·|¬O´x´¤¦b¥ýª¾¥ýıªº¤H¤â¤W,´x´¤¥ý¾÷¡A´N¬OĹ®a¡I<br>
<br>
<font class="unnamed1" color="#ff0000" size="2">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;      
·í¾÷·|¥X²{¡@±z¬O¬Ý¨ì¥¦½§²Lªº§Î»ª¡@ÁÙ¬O¤w¬Ý¨ì¨ä¤º²[ªº²`«× ¥¿©Ò¿×¼z²´ÃÑ­^¶¯<br>     
¡@¡@¡@¡@³o¤Ç¤d¨½°¨ <b>¥u¦³¿W¨ã¼z²´ªº§B¼Ö</b> ¥i¥H¬Ý¨ì¥Lªº¼ç¤O»P»ù­È</font></p>     
<p align="center"><b><font face="·s²Ó©úÅé">­Y¦]¤H¼Æ¤Ó¦h,¼v¤ùµLªk¥¿±`Æ[¬Ý,<a href="http://home.kimo.com.tw/amityydimon/joinus.asp.htm">½Ð±zª½±µ¯d¤U±zªº¸ê®Æ</a>,§Ú±N·|ºÉ³t»P±z³sµ¸!</font></b></p>

</body>

</html>



Return-Path: <[e-mail]>
Received: from sina.com.tw (TC218-187-135-150.adsl.pl.apol.com.tw [218.187.135.150]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3QBF1RN001577 for <[e-mail]>; Sat, 26 Apr 2003 13:15:04 +0200 (MEST)
Message-Id: <[e-mail]>
From: [e-mail]
Subject: ¥xÆW¥v¤Wªº³ÐÁ|
Reply-To: [e-mail]
Date: 26 Apr 2003 19:14:21 +0800
Organization: Foobar Inc.
X-Mailer: Gammadyne Mailer
x-delete-me: 1 (this tells Gammadyne's server to delete the message)
MIME-Version: 1.0
Content-Type: text/html
Content-Transfer-Encoding: 8bit

<html>

<head>
<meta http-equiv="Content-Language" content="zh-tw">
<meta name="GENERATOR" content="Microsoft FrontPage 4.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<meta http-equiv="Content-Type" content="text/html; charset=big5">
<title>±z¬O¤U­±¨º¤@¨º¤@ºØ¨­¥÷</title>
<bgsound src="http://140.114.79.84:7000/midi/foreign/latin/reloj.mid" loop="1">
</head>

<body>

<div style="background-color: #FFCC00; background-image: url('http://scort.org..tw~tp40/pic/m-flower.gif'); background-repeat: repeat-x; border-style: outset; border-width: 4">
  <div style="width: 728; height: 78; background-color: #FFCC00; background-image: url('http://www.scout.org.tw/~tp40/pic/m-flower.gif'); background-repeat: repeat-x; background-position: medium 50%">
  <p align="center">¡@</p>
  </div>
  <p>¡@</p>
  <p><span style="background-color: #FFCC00"><font face="µØ±dÄײʶê" size="6">±z</font><font face="µØ±dÄײʶê" size="4">¬O¤U­±¨º¤@¨º¤@ºØ¨­¥÷¡G</font></span></p>
  <p><span style="background-color: #FFCC00"><font face="µØ±dÄײʶê" size="4">¡@</font><font size="4" face="¼Ð·¢Åé">¡@<b>¢°.¬O¤@¦ì</b></font><font face="¼Ð·¢Åé"><b><a href="http://home.kimo.com.tw/amityydimon/joinus.asp.htm"><font color="#800000" style="font-size: 15pt">·QÁÈ¿úªº¾Ç¥Í</font></a></b></font><font size="4" face="¼Ð·¢Åé">¡A<b>«o¥u¯àÁȨì¨C¤p®É70¡ã100ªº®ÉÁ~¡A²Ö¿n¤£¤F°]´I¡C</b></font></span></p>
  <p><span style="background-color: #FFCC00"><font face="¼Ð·¢Åé" size="4">¡@¡@<b>¢±.¬O¤@¦ì</b></font><font face="¼Ð·¢Åé"><b><a href="http://home.kimo.com.tw/amityydimon/joinus.asp.htm"><font color="#800000" style="font-size: 15pt">¤W¯Z±Ú</font></a></b></font><font face="¼Ð·¢Åé" size="4">¡A<b>¨C¤Ñ¥´¥d¡¨¤W¡¨¡¨¤U¡¨¯Z¡A­è¦n¥d¦b¨º¸Ì¡A¤S¾á¤ß³Qµô­û¡C</b></font></span></p>
  <p><span style="background-color: #FFCC00"><font face="¼Ð·¢Åé" size="4">¡@¡@<b>¢².¬O¤@¦ì·QÀ°®a®x¦hÁȨǿú¡A¨Ó¬°®a®xºÉ¤ßºÉ¤Oªº</b></font><font face="¼Ð·¢Åé"><b><a href="http://home.kimo.com.tw/amityydimon/joinus.asp.htm"><font color="#800000" style="font-size: 15pt">®a®x¥D°ü</font></a></b></font><b><font face="¼Ð·¢Åé" size="4">¡C</font></b></span></p>
  <p align="left"><span style="background-color: #FFCC00">
  <font size="4" face="µØ±d·¢®ÑÅéW5"><b>¡@¡@¡@ ¦pªG§A¯uªº·Q¼W¥[¦¬¤J¡A¤S¨ã³Æ¤F¤@¨Ç¹q¸£ªº°ò¦</b>¡I</font></span></p>
  <p align="left"><span style="background-color: #FFCC00"><font face="¼Ð·¢Åé"><b>
  <font color="#FF0000" size="5">&nbsp;&nbsp;&nbsp;&nbsp; ¨º»ò®¥³ß±z¡I</font></b></font><b><font face="¼Ð·¢Åé" size="4" color="#FF0000">³o±N·|¬O±z³Ì¦nªº¾÷·|¡I</font></b></span></p>     
  <p><span style="background-color: #FFCC00"><font face="µØ±dÄײʶê" size="6">±z</font><font face="µØ±dÄײʶê" size="4">ª¾¹D¶Ü¡H</font></span></p>
  <p><span style="background-color: #FFCC00">
  <font face="µØ±dÄײʶê" size="4" color="#FFFFFF">¡@¡@­ì¨Ó¶R¤ú»I¡A¥Î½Ã¥Í¯È¡A¤]¯à²Ö¿n°]´I¡I¦A°t¤W±M·~ªººô¸ô¦æ¾P¤è¦¡¡I</font></span><font size="4" face="µØ±dÄײʶê" color="#FFFFFF">µ´¹ï¤ÞÃz¥«³õ¡I</font></p>
  <p>¡@</p>
  <p align="center"><span style="background-color: #FFCC00">
  <font face="µØ±dÄײʶê" size="5">
  <a href="http://home.kimo.com.tw/amityydimon/joinus.asp.htm">§Ú·Q¬Ý¶R¤ú»I¤Î¥Î½Ã¥Í¯ÈÁÈ¿úªº¼v¤ù</a></font></span></p>
  <p align="center"><span style="background-color: #FFCC00">
  <font color="#FFFF00">&nbsp;</font><b><font color="#CC0099" face="µØ±dÄ׶®§º" size="5"><a href="http://home.kimo.com.tw/amityydimon"><font color="#CC0099">§Ú­n¶i¤@¨B¤F¸Ñ</font></a></font></b></span></p>
  <p align="center">
  <img border="0" src="http://ruzunet.myrice.com/0328.gif" width="45" height="52"><span style="background-color: #FFCC00"><b><font color="#800000" face="µØ±dÄ׶®§º" size="5"><a href="http://home.kimo.com.tw/amityydimon/joinus.asp.htm">§Ú­nÁÈ¿ú¡A½Ð±zÁpµ¸§Ú¡I</a></font></b></span></p>
  <p align="center">¡@</div>
<p align="center"><b><img border="0" src="http://www.scout.org.tw/~tp40/pic/m-java.gif" width="64" height="64"><font size="4"><a href="http://home.kimo.com.tw/amityydimon">¤F¸Ñ¬O¤£¥Îªá¿úªº!!</a></font></b>¾÷·|¬O´x´¤¦b¥ýª¾¥ýıªº¤H¤â¤W,´x´¤¥ý¾÷¡A´N¬OĹ®a¡I<br>
<br>
<font class="unnamed1" color="#ff0000" size="2">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;      
·í¾÷·|¥X²{¡@±z¬O¬Ý¨ì¥¦½§²Lªº§Î»ª¡@ÁÙ¬O¤w¬Ý¨ì¨ä¤º²[ªº²`«× ¥¿©Ò¿×¼z²´ÃÑ­^¶¯<br>     
¡@¡@¡@¡@³o¤Ç¤d¨½°¨ <b>¥u¦³¿W¨ã¼z²´ªº§B¼Ö</b> ¥i¥H¬Ý¨ì¥Lªº¼ç¤O»P»ù­È</font></p>     
<p align="center"><b><font face="·s²Ó©úÅé">­Y¦]¤H¼Æ¤Ó¦h,¼v¤ùµLªk¥¿±`Æ[¬Ý,<a href="http://home.kimo.com.tw/amityydimon/joinus.asp.htm">½Ð±zª½±µ¯d¤U±zªº¸ê®Æ</a>,§Ú±N·|ºÉ³t»P±z³sµ¸!</font></b></p>

</body>

</html>



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3PBkHRN019894 for <[e-mail]>; Fri, 25 Apr 2003 13:46:17 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h3PBkHZQ019893 for ietf-provreg-outgoing; Fri, 25 Apr 2003 13:46:17 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3PBkGRN019888 for <[e-mail]>; Fri, 25 Apr 2003 13:46:16 +0200 (MEST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03660; Fri, 25 Apr 2003 07:43:29 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: [ietf-provreg] I-D ACTION:draft-ietf-provreg-epp-host-07.txt
Date: Fri, 25 Apr 2003 07:43:29 -0400
Sender: [e-mail]
Precedence: bulk

--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 Host Mapping
	Author(s)	: S. Hollenbeck
	Filename	: draft-ietf-provreg-epp-host-07.txt
	Pages		: 33
	Date		: 2003-4-24
	
This document describes an Extensible Provisioning Protocol (EPP)
mapping for the provisioning and management of Internet host names
stored in a shared central repository.  Specified in XML, the mapping
defines EPP command syntax and semantics as applied to host names.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-host-07.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-host-07.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:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-provreg-epp-host-07.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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

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

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

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3PBkBRN019883 for <[e-mail]>; Fri, 25 Apr 2003 13:46:11 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h3PBkBq9019882 for ietf-provreg-outgoing; Fri, 25 Apr 2003 13:46:11 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3PBk9RN019877 for <[e-mail]>; Fri, 25 Apr 2003 13:46:10 +0200 (MEST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03640; Fri, 25 Apr 2003 07:43:23 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: [ietf-provreg] I-D ACTION:draft-ietf-provreg-epp-domain-07.txt
Date: Fri, 25 Apr 2003 07:43:22 -0400
Sender: [e-mail]
Precedence: bulk

--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 Domain Name Mapping
	Author(s)	: S. Hollenbeck
	Filename	: draft-ietf-provreg-epp-domain-07.txt
	Pages		: 49
	Date		: 2003-4-24
	
This document describes an Extensible Provisioning Protocol (EPP) map-
ping for the provisioning and management of Internet domain names
stored in a shared central repository.  Specified in XML, the mapping
defines EPP command syntax and semantics as applied to domain names

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-domain-07.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-domain-07.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:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-provreg-epp-domain-07.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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

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

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

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3PBk5RN019874 for <[e-mail]>; Fri, 25 Apr 2003 13:46:05 +0200 (MEST)
Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h3PBk5X5019873 for ietf-provreg-outgoing; Fri, 25 Apr 2003 13:46:05 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3PBk3RN019868 for <[e-mail]>; Fri, 25 Apr 2003 13:46:03 +0200 (MEST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03624; Fri, 25 Apr 2003 07:43:16 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: [ietf-provreg] I-D ACTION:draft-ietf-provreg-epp-contact-07.txt
Date: Fri, 25 Apr 2003 07:43:16 -0400
Sender: [e-mail]
Precedence: bulk

--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 Contact Mapping
	Author(s)	: S. Hollenbeck
	Filename	: draft-ietf-provreg-epp-contact-07.txt
	Pages		: 46
	Date		: 2003-4-24
	
This document describes an Extensible Provisioning Protocol (EPP)
mapping for the provisioning and management of individual or
organizational social information identifiers (known as 'contacts')
stored in a shared central repository. Specified in XML, the mapping
defines EPP command syntax and semantics as applied to contacts.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-contact-07.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-contact-07.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:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-provreg-epp-contact-07.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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

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

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

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3OCr3RN005852 for <[e-mail]>; Thu, 24 Apr 2003 14:53:03 +0200 (MEST)
Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h3OCr3ax005851 for ietf-provreg-outgoing; Thu, 24 Apr 2003 14:53:03 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.237.102]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3OCr1RN005846 for <[e-mail]>; Thu, 24 Apr 2003 14:53:02 +0200 (MEST)
Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [10.170.12.38]) by heron.verisign.com (8.12.9/8.12.9) with ESMTP id h3OCsJaj006261; Thu, 24 Apr 2003 08:54:19 -0400 (EDT)
Received: by vsvapostalgw1.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <JL3XPTQL>; Thu, 24 Apr 2003 08:51:17 -0400
Message-ID: <5BEA6CDB196A4241B8BE129D309AA4AF10E6F4@vsvapostal8>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Edward Lewis'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: [ietf-provreg] Proposed Text for Contact Mapping Disclosure E lements
Date: Thu, 24 Apr 2003 08:51:17 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

> As soon as you get to it, submit the current round of documents. 
> I'll give them a look through before alerting the IESG - just to make 
> sure everything is in place and to give a short breather to the group 
> to look once.  (It's not a WG last call - just a sanity check.  As 
> I've said before, it's never too late to complain, but we do want 
> documents through the system.)

I just sent the updated contact, domain, and host mapping documents to the
I-D administrator; they'll probably be announced tomorrow.  The TCP and core
documents haven't changed.

-Scott-


Return-Path: <[e-mail]>
Received: from sina.com.tw (TC218-187-130-218.adsl.pl.apol.com.tw [218.187.130.218]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3O17pRN029536 for <[e-mail]>; Thu, 24 Apr 2003 03:07:52 +0200 (MEST)
Message-Id: <[e-mail]>
From: [e-mail]
Subject: ¿ú,,,,,¿ú,,,,,,¿ú,,,,¦n¦hªü
Reply-To: [e-mail]
Date: 24 Apr 2003 08:53:44 +0800
Organization: Foobar Inc.
X-Mailer: Gammadyne Mailer
x-delete-me: 1 (this tells Gammadyne's server to delete the message)
MIME-Version: 1.0
Content-Type: text/html
Content-Transfer-Encoding: 8bit

<html>

<head>
<meta http-equiv="Content-Language" content="zh-tw">
<meta name="GENERATOR" content="Microsoft FrontPage 4.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<meta http-equiv="Content-Type" content="text/html; charset=big5">
<title>±z¬O¤U­±¨º¤@¨º¤@ºØ¨­¥÷</title>
<bgsound src="http://140.114.79.84:7000/midi/foreign/latin/reloj.mid" loop="1">
</head>

<body>

<div style="background-color: #FFCC00; background-image: url('http://scort.org..tw~tp40/pic/m-flower.gif'); background-repeat: repeat-x; border-style: outset; border-width: 4">
  <div style="width: 728; height: 78; background-color: #FFCC00; background-image: url('http://www.scout.org.tw/~tp40/pic/m-flower.gif'); background-repeat: repeat-x; background-position: medium 50%">
  <p align="center">¡@</p>
  </div>
  <p>¡@</p>
  <p><span style="background-color: #FFCC00"><font face="µØ±dÄײʶê" size="6">±z</font><font face="µØ±dÄײʶê" size="4">¬O¤U­±¨º¤@¨º¤@ºØ¨­¥÷¡G</font></span></p>
  <p><span style="background-color: #FFCC00"><font face="µØ±dÄײʶê" size="4">¡@</font><font size="4" face="¼Ð·¢Åé">¡@<b>¢°.¬O¤@¦ì</b></font><font face="¼Ð·¢Åé"><b><a href="http://home.kimo.com.tw/leaderdimon/joinus.asp.htm"><font color="#800000" style="font-size: 15pt">·QÁÈ¿úªº¾Ç¥Í</font></a></b></font><font size="4" face="¼Ð·¢Åé">¡A<b>«o¥u¯àÁȨì¨C¤p®É70¡ã100ªº®ÉÁ~¡A²Ö¿n¤£¤F°]´I¡C</b></font></span></p>
  <p><span style="background-color: #FFCC00"><font face="¼Ð·¢Åé" size="4">¡@¡@<b>¢±.¬O¤@¦ì</b></font><font face="¼Ð·¢Åé"><b><a href="http://home.kimo.com.tw/leaderdimon/joinus.asp.htm"><font color="#800000" style="font-size: 15pt">¤W¯Z±Ú</font></a></b></font><font face="¼Ð·¢Åé" size="4">¡A<b>¨C¤Ñ¥´¥d¡¨¤W¡¨¡¨¤U¡¨¯Z¡A­è¦n¥d¦b¨º¸Ì¡A¤S¾á¤ß³Qµô­û¡C</b></font></span></p>
  <p><span style="background-color: #FFCC00"><font face="¼Ð·¢Åé" size="4">¡@¡@<b>¢².¬O¤@¦ì·QÀ°®a®x¦hÁȨǿú¡A¨Ó¬°®a®xºÉ¤ßºÉ¤Oªº</b></font><font face="¼Ð·¢Åé"><b><a href="http://home.kimo.com.tw/leaderdimon/joinus.asp.htm"><font color="#800000" style="font-size: 15pt">®a®x¥D°ü</font></a></b></font><b><font face="¼Ð·¢Åé" size="4">¡C</font></b></span></p>
  <p align="left"><span style="background-color: #FFCC00">
  <font size="4" face="µØ±d·¢®ÑÅéW5"><b>¡@¡@¡@ ¦pªG§A¯uªº·Q¼W¥[¦¬¤J¡A¤S¨ã³Æ¤F¤@¨Ç¹q¸£ªº°ò¦</b>¡I</font></span></p>
  <p align="left"><span style="background-color: #FFCC00"><font face="¼Ð·¢Åé"><b>
  <font color="#FF0000" size="5">&nbsp;&nbsp;&nbsp;&nbsp; ¨º»ò®¥³ß±z¡I</font></b></font><b><font face="¼Ð·¢Åé" size="4" color="#FF0000">³o±N·|¬O±z³Ì¦nªº¾÷·|¡I</font></b></span></p>    
  <p><span style="background-color: #FFCC00"><font face="µØ±dÄײʶê" size="6">±z</font><font face="µØ±dÄײʶê" size="4">ª¾¹D¶Ü¡H</font></span></p>
  <p><span style="background-color: #FFCC00">
  <font face="µØ±dÄײʶê" size="4" color="#FFFFFF">¡@¡@­ì¨Ó¶R¤ú»I¡A¥Î½Ã¥Í¯È¡A¤]¯à²Ö¿n°]´I¡I¦A°t¤W±M·~ªººô¸ô¦æ¾P¤è¦¡¡I</font></span><font size="4" face="µØ±dÄײʶê" color="#FFFFFF">µ´¹ï¤ÞÃz¥«³õ¡I</font></p>
  <p>¡@</p>
  <p align="center"><span style="background-color: #FFCC00">
  <font face="µØ±dÄײʶê" size="5">
  <a href="http://home.kimo.com.tw/leaderdimon/joinus.asp.htm">§Ú·Q¬Ý¶R¤ú»I¤Î¥Î½Ã¥Í¯ÈÁÈ¿úªº¼v¤ù</a></font></span></p>
  <p align="center"><span style="background-color: #FFCC00">
  <font color="#FFFF00">&nbsp;</font><b><font color="#CC0099" face="µØ±dÄ׶®§º" size="5"><a href="http://home.kimo.com.tw/leaderdimon"><font color="#CC0099">§Ú­n¶i¤@¨B¤F¸Ñ</font></a></font></b></span></p>
  <p align="center">
  <img border="0" src="http://ruzunet.myrice.com/0328.gif" width="45" height="52"><span style="background-color: #FFCC00"><b><font color="#800000" face="µØ±dÄ׶®§º" size="5"><a href="http://home.kimo.com.tw/leaderdimon/joinus.asp.htm">§Ú­nÁÈ¿ú¡A½Ð±zÁpµ¸§Ú¡I</a></font></b></span></p>
  <p align="center">¡@</div>
<p align="center"><b><img border="0" src="http://www.scout.org.tw/~tp40/pic/m-java.gif" width="64" height="64"><font size="4"><a href="http://home.kimo.com.tw/leaderdimon">¤F¸Ñ¬O¤£¥Îªá¿úªº!!</a></font></b>¾÷·|¬O´x´¤¦b¥ýª¾¥ýıªº¤H¤â¤W,´x´¤¥ý¾÷¡A´N¬OĹ®a¡I<br>
<br>
<font class="unnamed1" color="#ff0000" size="2">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;     
·í¾÷·|¥X²{¡@±z¬O¬Ý¨ì¥¦½§²Lªº§Î»ª¡@ÁÙ¬O¤w¬Ý¨ì¨ä¤º²[ªº²`«× ¥¿©Ò¿×¼z²´ÃÑ­^¶¯<br>    
¡@¡@¡@¡@³o¤Ç¤d¨½°¨ <b>¥u¦³¿W¨ã¼z²´ªº§B¼Ö</b> ¥i¥H¬Ý¨ì¥Lªº¼ç¤O»P»ù­È</font></p>    
<p align="center"><b><font face="·s²Ó©úÅé">­Y¦]¤H¼Æ¤Ó¦h,¼v¤ùµLªk¥¿±`Æ[¬Ý,<a href="http://home.kimo.com.tw/leaderdimon/joinus.asp.htm">½Ð±zª½±µ¯d¤U±zªº¸ê®Æ</a>,§Ú±N·|ºÉ³t»P±z³sµ¸!</font></b></p>

</body>

</html>



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3NIdYRN025706 for <[e-mail]>; Wed, 23 Apr 2003 20:39:34 +0200 (MEST)
Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h3NIdY9S025705 for ietf-provreg-outgoing; Wed, 23 Apr 2003 20:39:34 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from smtp2.arin.net (smtp2.arin.net [192.149.252.32]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3NIdXRN025700 for <[e-mail]>; Wed, 23 Apr 2003 20:39:33 +0200 (MEST)
Received: by smtp2.arin.net (Postfix, from userid 5003) id B1823401; Wed, 23 Apr 2003 14:39:30 -0400 (EDT)
Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id 3C1CF3FC for <[e-mail]>; Wed, 23 Apr 2003 14:39:30 -0400 (EDT)
Received: from [192.136.136.61] (HELO [192.149.252.108]) by arin.net (CommuniGate Pro SMTP 4.0.6) with ESMTP id 195170; Wed, 23 Apr 2003 14:29:30 -0400
Mime-Version: 1.0
X-Sender: edlewis@mta
Message-Id: <a05111b16bacc8ca722b7@[192.149.252.108]>
Date: Wed, 23 Apr 2003 14:39:29 -0400
To: [e-mail]
From: Edward Lewis <[e-mail]>
Subject: [ietf-provreg] upcoming activity
Cc: Edward Lewis <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,SIGNATURE_SHORT_SPARSE,SPAM_PHRASE_01_02 version=2.43-arin1
X-Spam-Level: 
Sender: [e-mail]
Precedence: bulk

We're close to sending the docs back to the IESG.

That means that we have the extensions draft to look at now.  Scott 
recently put a fresh copy in the repository:

    http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-ext-01.txt

Once we do get the core docs back to the IESG, there will be a WG 
last call on this document, leading towards informational.  Given 
that folks have already given thought to extensions, we should 
already have the background to give this a good review.

We will want to have the last call extend past the RIPE meeting in 
the hopes of contacting some ccTLD's that have done work in this 
area.  I'm saying this now as an invitation for folks attending RIPE 
to bug myself and Jaap when we are there to give us any non-list 
feedback if they so desire.  (Yes, this feedback only counts if it is 
at least summarized on the WG list as this is a WG document.)

One other item to keep in mind, the call for meetings in Vienna has 
already started.  There's a slim chance we might need to meet - we 
might have to react to more IESG comments, we might have something on 
the extensions recommendation document.  Right now I don't foresee us 
meeting, so it's time to convince me I'm wrong, if you want to, on 
this point.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            [phone]
ARIN Research Engineer

A compiler-directive person living in an HTML-tagged world.


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3NEc1RN022583 for <[e-mail]>; Wed, 23 Apr 2003 16:38:01 +0200 (MEST)
Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h3NEc0YU022582 for ietf-provreg-outgoing; Wed, 23 Apr 2003 16:38:00 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from smtp2.arin.net (smtp2.arin.net [192.149.252.32]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3NEbxRN022577 for <[e-mail]>; Wed, 23 Apr 2003 16:37:59 +0200 (MEST)
Received: by smtp2.arin.net (Postfix, from userid 5003) id EF0CB317; Wed, 23 Apr 2003 10:37:58 -0400 (EDT)
Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id 74C1D303; Wed, 23 Apr 2003 10:37:58 -0400 (EDT)
Received: from [192.136.136.61] (HELO [192.149.252.108]) by arin.net (CommuniGate Pro SMTP 4.0.6) with ESMTP id 194838; Wed, 23 Apr 2003 10:27:59 -0400
Mime-Version: 1.0
X-Sender: edlewis@mta
Message-Id: <a05111b06bacc55071943@[192.149.252.108]>
In-Reply-To: <5BEA6CDB196A4241B8BE129D309AA4AF10E6E8@vsvapostal8>
References: <5BEA6CDB196A4241B8BE129D309AA4AF10E6E8@vsvapostal8>
Date: Wed, 23 Apr 2003 10:37:57 -0400
To: "Hollenbeck, Scott" <[e-mail]>
From: Edward Lewis <[e-mail]>
Subject: RE: [ietf-provreg] Proposed Text for Contact Mapping Disclosure E lements
Cc: "'Edward Lewis'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Status: No, hits=-2.9 required=5.0 tests=AWL,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_SPARSE,SPAM_PHRASE_03_05 version=2.43-arin1
X-Spam-Level: 
Sender: [e-mail]
Precedence: bulk

Yeah, for me.  Others?

As soon as you get to it, submit the current round of documents. 
I'll give them a look through before alerting the IESG - just to make 
sure everything is in place and to give a short breather to the group 
to look once.  (It's not a WG last call - just a sanity check.  As 
I've said before, it's never too late to complain, but we do want 
documents through the system.)

At 10:16 -0400 4/23/03, Hollenbeck, Scott wrote:
>>  At 11:32 -0400 4/21/03, Hollenbeck, Scott wrote:
>>  >If you're not, you don't.  So do I need to add a sentence in
>>  the <info>
>>  >description that describes the primacy of authorization?
>>
>>  Given (my) experience with other IETF specs, yeah.
>
>Looking at the current specs I see that this means that I really need to add
>an optional authInfo element to the contact <info> command, too.  Here's the
>text that I'll suggest we add to the earlier text to address authorization
>and in-band disclosure:
>
>"Client identification features provided by the EPP <login> command and
>contact authorization information are used to determine if a client is
>authorized to perform contact information query commands.  These features
>also determine if a client is authorized to receive data in a query response
>that is otherwise marked for non-disclosure."
>
>Does this work?
>
>-Scott-

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            [phone]
ARIN Research Engineer

A compiler-directive person living in an HTML-tagged world.


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3NEMDRN022392 for <[e-mail]>; Wed, 23 Apr 2003 16:22:13 +0200 (MEST)
Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h3NEMDLS022391 for ietf-provreg-outgoing; Wed, 23 Apr 2003 16:22:13 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.237.102]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3NEMBRN022386 for <[e-mail]>; Wed, 23 Apr 2003 16:22:11 +0200 (MEST)
Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [10.170.12.38]) by heron.verisign.com (8.12.9/8.12.9) with ESMTP id h3NEJsaj000796; Wed, 23 Apr 2003 10:19:54 -0400 (EDT)
Received: by vsvapostalgw1.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <JL3X3JDM>; Wed, 23 Apr 2003 10:16:53 -0400
Message-ID: <5BEA6CDB196A4241B8BE129D309AA4AF10E6E8@vsvapostal8>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Edward Lewis'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: [ietf-provreg] Proposed Text for Contact Mapping Disclosure E lements
Date: Wed, 23 Apr 2003 10:16:53 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

> At 11:32 -0400 4/21/03, Hollenbeck, Scott wrote:
> >If you're not, you don't.  So do I need to add a sentence in 
> the <info>
> >description that describes the primacy of authorization?
> 
> Given (my) experience with other IETF specs, yeah.

Looking at the current specs I see that this means that I really need to add
an optional authInfo element to the contact <info> command, too.  Here's the
text that I'll suggest we add to the earlier text to address authorization
and in-band disclosure:

"Client identification features provided by the EPP <login> command and
contact authorization information are used to determine if a client is
authorized to perform contact information query commands.  These features
also determine if a client is authorized to receive data in a query response
that is otherwise marked for non-disclosure."

Does this work?

-Scott-


Return-Path: <[e-mail]>
Received: from sina.com.tw (TC218-187-131-64.adsl.pl.apol.com.tw [218.187.131.64]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3N1u6RN016290 for <[e-mail]>; Wed, 23 Apr 2003 03:56:07 +0200 (MEST)
Message-Id: <[e-mail]>
From: [e-mail]
Subject: ¥u§i¶D§Úªº((³Â¦N))³á
Reply-To: [e-mail]
Date: 23 Apr 2003 09:52:44 +0800
Organization: Foobar Inc.
X-Mailer: Gammadyne Mailer
x-delete-me: 1 (this tells Gammadyne's server to delete the message)
MIME-Version: 1.0
Content-Type: text/html
Content-Transfer-Encoding: 8bit

<html>

<head>
<meta http-equiv="Content-Language" content="zh-tw">
<meta http-equiv="Content-Type" content="text/html; charset=big5">
<meta name="GENERATOR" content="Microsoft FrontPage 5.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<title>§A©Î³\·|»¡</title>
</head>

<body>

<p><a href="http://home.kimo.com.tw/vivian85582002/index2.htm">
<img border="0" src="http://www.3yes.com.tw/ads/gif/e-shop-1-1.gif" width="468" height="60"></a>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </p>  

<p>¼W¥[¦¬¤Jªº³Ì¨Î¿ï¾Ü!!</p> 
<p>µLÃö©Ê§O ¾Ç¾ú&nbsp; ¡ã¡ã¡ã¥u­n§AÄ@·N</p> 
<p>¤@ÂIÂIªº¹s¸H®É¶¡¦¨´N§Aªº¥¼¨Ó</p> 
<p>ÄÝ©ó¥­¤Z¤Hªº¤£¤Z¨Æ·~!!</p> 
<p><a href="http://www.3yes.com.tw/cgi-bin/8558/shop.cgi">
¤@®a¤W¬[¸U®a»ô½æ¡A«e©Ò¥¼¦³¹êÅéºô¸ô©±¾Q¥¿¦¡»P±z±µÄ²</a></p> 
<p><font color="#FF0000">©Ò¦³«eºÝ¸ê°T»P«áºÝ¸ê·½·½¬u§K¶O´£¨Ñ!!</font></p> 
<p><font color="#FF0000">ÁÙ¦bµS¿Ý¤°»ò!!!</font></p> 
<p><font color="#FF0000">¿ù¹L³o¤@¦¸¡ã¡ã¡ã¡ã¦Aµ¥¤@¦Ê¦~</font></p> 
<p><a href="http://www.3yes.com.tw/cgi-bin/8558/shop.cgi">
¶W±j¦æ°Ê°Ó°È¨t²Î¾÷¨î-30¤ÀÄÁ¶}³q! §K¶O¸Õ¥ÎÅwªï¥[·ù!! </a></p> 
<p><a href="http://home.kimo.com.tw/vivian85582002/index2.htm">
<img border="0" src="http://tw.yimg.com/a/tw/k_lea/249896_n_0331.gif" width="468" height="60"></a></p>
<p>¡@</p>

</body>

</html>



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3LGbJRN025884 for <[e-mail]>; Mon, 21 Apr 2003 18:37:19 +0200 (MEST)
Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h3LGbJvK025883 for ietf-provreg-outgoing; Mon, 21 Apr 2003 18:37:19 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3LGbIRN025878 for <[e-mail]>; Mon, 21 Apr 2003 18:37:18 +0200 (MEST)
Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.9/8.12.9) with ESMTP id h3LGRpZj023623; Mon, 21 Apr 2003 12:27:51 -0400 (EDT)
Message-Id: <[e-mail]>
To: Edward Lewis <[e-mail]>
cc: Eric Brunner-Williams in Portland Maine <[e-mail]>, [e-mail], [e-mail]
Subject: Re: [ietf-provreg] consensus on privacy 
In-Reply-To: Your message of "Mon, 21 Apr 2003 11:29:28 EDT." <a05111b13bac9be86f0a1@[192.149.252.108]> 
Date: Mon, 21 Apr 2003 12:27:51 -0400
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Ed,

As I drove in to work I was thinking about the implementation details,
how one implementation could signal that it was able to toggle between
a boolean type, and another type.

I wrote more, only two paras, honest, but cut it.

If an extension exists, implementors can use it. If it doesn't, then
implementors can find an alternate mechanism, if they choose to.

Eric


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3LFnaRN025378 for <[e-mail]>; Mon, 21 Apr 2003 17:49:36 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h3LFna9L025377 for ietf-provreg-outgoing; Mon, 21 Apr 2003 17:49:36 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from smtp2.arin.net (smtp2.arin.net [192.149.252.32]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3LFnZRN025372 for <[e-mail]>; Mon, 21 Apr 2003 17:49:35 +0200 (MEST)
Received: by smtp2.arin.net (Postfix, from userid 5003) id C6BDE378; Mon, 21 Apr 2003 11:49:34 -0400 (EDT)
Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id 5987D368; Mon, 21 Apr 2003 11:49:34 -0400 (EDT)
Received: from [192.136.136.46] (HELO [192.149.252.108]) by arin.net (CommuniGate Pro SMTP 4.0.6) with ESMTP id 192370; Mon, 21 Apr 2003 11:39:42 -0400
Mime-Version: 1.0
X-Sender: edlewis@mta
Message-Id: <a05111b17bac9c2fbfd54@[192.149.252.108]>
In-Reply-To: <5BEA6CDB196A4241B8BE129D309AA4AF10E6D9@vsvapostal8>
References: <5BEA6CDB196A4241B8BE129D309AA4AF10E6D9@vsvapostal8>
Date: Mon, 21 Apr 2003 11:49:28 -0400
To: "Hollenbeck, Scott" <[e-mail]>
From: Edward Lewis <[e-mail]>
Subject: RE: [ietf-provreg] Proposed Text for Contact Mapping Disclosure E lements
Cc: "'Edward Lewis'" <[e-mail]>, "Hollenbeck, Scott" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Status: No, hits=-2.6 required=5.0 tests=AWL,IN_REP_TO,REFERENCES,SIGNATURE_SHORT_SPARSE, SPAM_PHRASE_02_03 version=2.43-arin1
X-Spam-Level: 
Sender: [e-mail]
Precedence: bulk

Generic 'ok', 'cept for:

At 11:32 -0400 4/21/03, Hollenbeck, Scott wrote:
>If you're not, you don't.  So do I need to add a sentence in the <info>
>description that describes the primacy of authorization?

Given (my) experience with other IETF specs, yeah.

>What impact, other than in a <create>?  The description of the <create>
>command will be modified to describe how the information can be set
>initially.  This change is what I meant by my "consistency" statement at the
>end of the proposal.

The other's are answered by other comments (primacy of authorization).

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            [phone]
ARIN Research Engineer

"I'm sorry, sir, your flight is delayed for maintenance.  We are
pounding out the dents from the last landing."


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3LFbGRN025264 for <[e-mail]>; Mon, 21 Apr 2003 17:37:16 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h3LFbGpR025263 for ietf-provreg-outgoing; Mon, 21 Apr 2003 17:37:16 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.237.102]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3LFbFRN025258 for <[e-mail]>; Mon, 21 Apr 2003 17:37:15 +0200 (MEST)
Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [10.170.12.38]) by heron.verisign.com (8.12.9/8.12.9) with ESMTP id h3LFYuaj014273; Mon, 21 Apr 2003 11:34:56 -0400 (EDT)
Received: by vsvapostalgw1.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <JL3XMBX6>; Mon, 21 Apr 2003 11:32:00 -0400
Message-ID: <5BEA6CDB196A4241B8BE129D309AA4AF10E6D9@vsvapostal8>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Edward Lewis'" <[e-mail]>, "Hollenbeck, Scott" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: [ietf-provreg] Proposed Text for Contact Mapping Disclosure E lements
Date: Mon, 21 Apr 2003 11:32:00 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

> I've found that we have consensus to leave dcp as mandatory, not 
> distinguish between personal and corporate data, and in general have 
> no concerns about the words included below from Scott.  BUT, in going 
> back through relevant threads and what was verbally discussed in SF I 
> have a couple of items that need to be addressed.
> 
> There were questions from Joe Abley in
>        http://www.cafax.se/ietf-provreg/maillist/2002-12/msg00101.html
> that seem to be unaddressed by this proposal.

No one else had any issues or inputs, so I let them go.  Since you've
brought them up again I'll address them now.

> Particularly:
> 
> "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>.

I disagree with the basic premise.  We already have a situation in the
protocol where fields might not be disclosed if the querying client fails to
provide authorization information.  If you're authorized, you see it all.
If you're not, you don't.  So do I need to add a sentence in the <info>
description that describes the primacy of authorization?

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

The <check> command doesn't disclose attribute information.  The object
being checked isn't marked with dnd="true", so <check> behavior should
remain as currently specified.

> The proposed text here does not specify the impact of a private flag 
> on the server's "write" functions.  I think that this can be fixed by 
> merely specifying the protocol actions in these cases.

What impact, other than in a <create>?  The description of the <create>
command will be modified to describe how the information can be set
initially.  This change is what I meant by my "consistency" statement at the
end of the proposal.

> Adjunct to that discussion, the following needs to also be addressed: 
> how can the setter of the privacy data check the privacy setting? 
> How can it be changed?  (I recall asking this in SF.)  The closest 
> that you come here is the text near the lower-case "should."  (Which 
> in itself is a no-no. ;))

The description of the <info> command will be modified to describe how the
information can be viewed.  The description of the <update> command will be
modified to describe how the information can be changed.  That's again what
I meant by my "consistency" statement at the end of the proposal.

> PS - could you also make sure we haven't introduced other lower case 
> RFC 2119 words in the documents.  There are a few that have popped in 
> (outside of the boilerplate) in recent edits.

I only see one "should", but I'll check for others.

-Scott-


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3LFWLRN025199 for <[e-mail]>; Mon, 21 Apr 2003 17:32:21 +0200 (MEST)
Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h3LFWKgq025198 for ietf-provreg-outgoing; Mon, 21 Apr 2003 17:32:20 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from smtp2.arin.net (smtp2.arin.net [192.149.252.32]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3LFWKRN025193 for <[e-mail]>; Mon, 21 Apr 2003 17:32:20 +0200 (MEST)
Received: by smtp2.arin.net (Postfix, from userid 5003) id A62992D5; Mon, 21 Apr 2003 11:32:19 -0400 (EDT)
Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id 3BFFD2D3; Mon, 21 Apr 2003 11:32:19 -0400 (EDT)
Received: from [192.136.136.46] (HELO [192.149.252.108]) by arin.net (CommuniGate Pro SMTP 4.0.6) with ESMTP id 192342; Mon, 21 Apr 2003 11:22:27 -0400
Mime-Version: 1.0
X-Sender: edlewis@mta
Message-Id: <a05111b13bac9be86f0a1@[192.149.252.108]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Mon, 21 Apr 2003 11:29:28 -0400
To: Eric Brunner-Williams in Portland Maine <[e-mail]>
From: Edward Lewis <[e-mail]>
Subject: Re: [ietf-provreg] consensus on privacy
Cc: Edward Lewis <[e-mail]>, [e-mail], [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Status: No, hits=-2.6 required=5.0 tests=AWL,IN_REP_TO,REFERENCES,SIGNATURE_SHORT_SPARSE, SPAM_PHRASE_00_01 version=2.43-arin1
X-Spam-Level: 
Sender: [e-mail]
Precedence: bulk

As the policy-based distinction differs from one environment to 
another, is it possible and more appropriate to make the distinction 
between personal and corporate in an extension?

At 11:13 -0400 4/21/03, Eric Brunner-Williams in Portland Maine wrote:
>>  ... and the distinction is definitely a
>>  policy issue.
>
>It is a choice to allow, or disallow, mechanisms that distinguish one datum
>from another.
>
>Because the operation of such mechanism(s) is an operational issue, hence
>one of local policy, it does not follow that the existance, or impossibility
>of such mechanism(s), is a policy issue.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            [phone]
ARIN Research Engineer

"I'm sorry, sir, your flight is delayed for maintenance.  We are
pounding out the dents from the last landing."


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3LFNORN025099 for <[e-mail]>; Mon, 21 Apr 2003 17:23:24 +0200 (MEST)
Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h3LFNOix025098 for ietf-provreg-outgoing; Mon, 21 Apr 2003 17:23:24 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3LFNMRN025092 for <[e-mail]>; Mon, 21 Apr 2003 17:23:23 +0200 (MEST)
Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.9/8.12.9) with ESMTP id h3LFDjZj023297; Mon, 21 Apr 2003 11:13:45 -0400 (EDT)
Message-Id: <[e-mail]>
To: Edward Lewis <[e-mail]>
cc: [e-mail], [e-mail]
Subject: Re: [ietf-provreg] consensus on privacy 
In-Reply-To: Your message of "Mon, 21 Apr 2003 10:48:50 EDT." <a05111b0dbac9b547c5d1@[192.149.252.108]> 
Date: Mon, 21 Apr 2003 11:13:45 -0400
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

> ... and the distinction is definitely a 
> policy issue.

It is a choice to allow, or disallow, mechanisms that distinguish one datum
from another.

Because the operation of such mechanism(s) is an operational issue, hence
one of local policy, it does not follow that the existance, or impossibility
of such mechanism(s), is a policy issue.


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3LFLWRN025054 for <[e-mail]>; Mon, 21 Apr 2003 17:21:32 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h3LFLWZK025053 for ietf-provreg-outgoing; Mon, 21 Apr 2003 17:21:32 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from smtp2.arin.net (smtp2.arin.net [192.149.252.32]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3LFLURN025048 for <[e-mail]>; Mon, 21 Apr 2003 17:21:31 +0200 (MEST)
Received: by smtp2.arin.net (Postfix, from userid 5003) id 530DD2D5; Mon, 21 Apr 2003 11:21:30 -0400 (EDT)
Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id 8BAC62D3; Mon, 21 Apr 2003 11:21:29 -0400 (EDT)
Received: from [192.136.136.46] (HELO [192.149.252.108]) by arin.net (CommuniGate Pro SMTP 4.0.6) with ESMTP id 192330; Mon, 21 Apr 2003 11:11:37 -0400
Mime-Version: 1.0
X-Sender: edlewis@mta
Message-Id: <a05111b11bac9ba15e60b@[192.149.252.108]>
In-Reply-To: <5BEA6CDB196A4241B8BE129D309AA4AF10E698@vsvapostal8>
References: <5BEA6CDB196A4241B8BE129D309AA4AF10E698@vsvapostal8>
X-Priority: 1 (Highest)
Date: Mon, 21 Apr 2003 11:21:29 -0400
To: "Hollenbeck, Scott" <[e-mail]>
From: Edward Lewis <[e-mail]>
Subject: Re: [ietf-provreg] Proposed Text for Contact Mapping Disclosure Elements
Cc: "'[e-mail]'" <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,IN_REP_TO,PRIORITY_NO_NAME,REFERENCES, SIGNATURE_SHORT_SPARSE,SPAM_PHRASE_02_03,X_PRIORITY_HIGH version=2.43-arin1
X-Spam-Level: 
Sender: [e-mail]
Precedence: bulk

I've found that we have consensus to leave dcp as mandatory, not 
distinguish between personal and corporate data, and in general have 
no concerns about the words included below from Scott.  BUT, in going 
back through relevant threads and what was verbally discussed in SF I 
have a couple of items that need to be addressed.

There were questions from Joe Abley in
       http://www.cafax.se/ietf-provreg/maillist/2002-12/msg00101.html
that seem to be unaddressed by this proposal.

Particularly:

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

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

The proposed text here does not specify the impact of a private flag 
on the server's "write" functions.  I think that this can be fixed by 
merely specifying the protocol actions in these cases.

Adjunct to that discussion, the following needs to also be addressed: 
how can the setter of the privacy data check the privacy setting? 
How can it be changed?  (I recall asking this in SF.)  The closest 
that you come here is the text near the lower-case "should."  (Which 
in itself is a no-no. ;))

PS - could you also make sure we haven't introduced other lower case 
RFC 2119 words in the documents.  There are a few that have popped in 
(outside of the boilerplate) in recent edits.

At 15:41 -0400 4/15/03, Hollenbeck, Scott wrote:
>I'd like to propose adding the following text to section 2 of the contact
>mapping document to move forward with the element privacy approach described
>here:
>
>http://www.cafax.se/ietf-provreg/maillist/2003-03/msg00134.html
>
>I am assuming that we are past the point of discussing whether or not the
>direction described in this new text is one we need to follow.  Specific
>replacement text would be _most_ helpful if you see something that you don't
>like.
>
>"2.9 Disclosure of Data Elements and Attributes
>
>The EPP core protocol requires a server operator to announce data collection
>policies to clients; see section 2.4 of [EPP].  In conjunction with this
>disclosure requirement, this mapping includes data elements that allow a
>client to identify elements that require exceptional server operator
>handling to allow or restrict disclosure to third parties.
>
>A server operator announces a default disclosure policy when establishing a
>session with a client.  When an object is created or updated, the client can
>specify contact attributes that require exceptional disclosure handling
>using an OPTIONAL <contact:disclose> element.  A server operator MAY reject
>any transaction that requests disclosure practices that do not conform to
>the announced data collection policy.  Once set, disclosure preferences can
>be reviewed using a standard contact information query.
>
>If present, the <contact:disclose> element MUST contain a "flag" attribute.
>The "flag" attribute contains an XML Schema boolean value.  A value of
>"true" or "1" (decimal one) notes a client preference to allow disclosure of
>the specified elements as an exception to the stated data collection policy.
>A value of "false" or "0" (decimal zero) notes a client preference to not
>allow disclosure of the specified elements as an exception to the stated
>data collection policy.
>
>The <contact:disclose> element MUST contain at least one of the following
>child elements:
>
><contact:name type="int">
><contact:name type="loc">
><contact:org type="int">
><contact:org type="loc">
><contact:addr type="int">
><contact:addr type="loc">
><contact:voice>
><contact:fax>
><contact:email>
>
>Example <contact:disclose> element, flag="0":
>
><contact:disclose flag="0">
>   <contact:email>
>   <contact:voice>
></contact:disclose>
>
>In this example, the contact email address and voice telephone number should
>not be disclosed.  All other elements are subject to disclosure in
>accordance with the server's data collection policy.
>
>Example <contact:disclose> element, flag="1":
>
><contact:disclose flag="1">
>   <contact:name type="int">
>   <contact:org type="int">
>   <contact:addr type="int">
></contact:disclose>
>
>In this example, the internationalized contact name, organization, and
>address information can be disclosed.  All other elements are subject to
>disclosure in accordance with the server's data collection policy."
>
>Well, that's the proposed text, with appropriate changes required elsewhere
>in the document to maintain consistency.  Fire away.
>
>-Scott-

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            [phone]
ARIN Research Engineer

"I'm sorry, sir, your flight is delayed for maintenance.  We are
pounding out the dents from the last landing."


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3LEmqRN024798 for <[e-mail]>; Mon, 21 Apr 2003 16:48:52 +0200 (MEST)
Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h3LEmqm7024797 for ietf-provreg-outgoing; Mon, 21 Apr 2003 16:48:52 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from smtp2.arin.net (smtp2.arin.net [192.149.252.32]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3LEmpRN024792 for <[e-mail]>; Mon, 21 Apr 2003 16:48:51 +0200 (MEST)
Received: by smtp2.arin.net (Postfix, from userid 5003) id CE09E3A4; Mon, 21 Apr 2003 10:48:50 -0400 (EDT)
Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id 614752E5 for <[e-mail]>; Mon, 21 Apr 2003 10:48:50 -0400 (EDT)
Received: from [192.136.136.46] (HELO [192.149.252.108]) by arin.net (CommuniGate Pro SMTP 4.0.6) with ESMTP id 192300; Mon, 21 Apr 2003 10:38:58 -0400
Mime-Version: 1.0
X-Sender: edlewis@mta
Message-Id: <a05111b0dbac9b547c5d1@[192.149.252.108]>
Date: Mon, 21 Apr 2003 10:48:50 -0400
To: [e-mail]
From: Edward Lewis <[e-mail]>
Subject: [ietf-provreg] consensus on privacy
Cc: Edward Lewis <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,SIGNATURE_SHORT_SPARSE,SPAM_PHRASE_00_01 version=2.43-arin1
X-Spam-Level: 
Sender: [e-mail]
Precedence: bulk

(I was asked to repost this.)

Just to let the group know, I think we've definitely achieved a 
consensus on privacy.  I will go back over the list and check a few 
things before making a summary - my schedule today has me tied up in 
the early going - but what I will be looking at saying something just 
like the words Scott posted on April 15.  (Maybe just URL to the 
archive.)

As far as enumerated-binary issue, it looks certain that binary is 
the way to go, e.g. no personal v. corporate distinction.  The 
rationale is based on two things - such a distinction is not in the 
requirements as adopted post-SF and the distinction is definitely a 
policy issue.

While I'm proceeding to write up a summary, folks are free (as usual) 
to voice opinions.  But to warn you - to stop me from declaring a 
consensus, it has to be clearly convincing.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            [phone]
ARIN Research Engineer

"I'm sorry, sir, your flight is delayed for maintenance.  We are
pounding out the dents from the last landing."


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3LDtiRN024411 for <[e-mail]>; Mon, 21 Apr 2003 15:55:44 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h3LDtiio024410 for ietf-provreg-outgoing; Mon, 21 Apr 2003 15:55:44 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from smtp2.arin.net (smtp2.arin.net [192.149.252.32]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3LDthRN024405 for <[e-mail]>; Mon, 21 Apr 2003 15:55:43 +0200 (MEST)
Received: by smtp2.arin.net (Postfix, from userid 5003) id 4B1273E2; Mon, 21 Apr 2003 09:55:42 -0400 (EDT)
Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id D0BF13F2 for <[e-mail]>; Mon, 21 Apr 2003 09:55:41 -0400 (EDT)
Received: from [192.136.136.46] (HELO [192.149.252.108]) by arin.net (CommuniGate Pro SMTP 4.0.6) with ESMTP id 192251; Mon, 21 Apr 2003 09:45:50 -0400
Mime-Version: 1.0
X-Sender: edlewis@mta
Message-Id: <a05111b0abac9a71872be@[192.149.252.108]>
Date: Mon, 21 Apr 2003 09:55:28 -0400
To: [e-mail]
From: Edward Lewis <[e-mail]>
Subject: [ietf-provreg] consensus on privacy
Cc: Edward Lewis <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,SIGNATURE_SHORT_SPARSE,SPAM_PHRASE_00_01 version=2.43-arin1
X-Spam-Level: 
Sender: [e-mail]
Precedence: bulk

Just to let the group know, I think we've definitely achieved a 
consensus on privacy.  I will go back over the list and check a few 
things before making a summary - my schedule today has me tied up in 
the early going - but what I will be looking at saying something just 
like the words Scott posted on April 15.  (Maybe just URL to the 
archive.)

As far as enumerated-binary issue, it looks certain that binary is 
the way to go, e.g. no personal v. corporate distinction.  The 
rationale is based on two things - such a distinction is not in the 
requirements as adopted post-SF and the distinction is definitely a 
policy issue.

While I'm proceeding to write up a summary, folks are free (as usual) 
to voice opinions.  But to warn you - to stop me from declaring a 
consensus, it has to be clearly convincing.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            [phone]
ARIN Research Engineer

"I'm sorry, sir, your flight is delayed for maintenance.  We are
pounding out the dents from the last landing."


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3IK2vRN002065 for <[e-mail]>; Fri, 18 Apr 2003 22:02:57 +0200 (MEST)
Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h3IK2vLK002064 for ietf-provreg-outgoing; Fri, 18 Apr 2003 22:02:57 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3IK2uRN002059 for <[e-mail]>; Fri, 18 Apr 2003 22:02:56 +0200 (MEST)
Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.9/8.12.9) with ESMTP id h3IJs6Zj012224; Fri, 18 Apr 2003 15:54:06 -0400 (EDT)
Message-Id: <[e-mail]>
To: Eric Brunner-Williams in Portland Maine <[e-mail]>
cc: Edward Lewis <[e-mail]>, "Hollenbeck, Scott" <[e-mail]>, [e-mail], [e-mail]
Subject: Re: [ietf-provreg] legal entity vs individual person 
In-Reply-To: Your message of "Fri, 18 Apr 2003 14:52:13 EDT." <[e-mail]> 
Date: Fri, 18 Apr 2003 15:54:06 -0400
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

> All Andy's solved is flag is usefully valued in the range {0, 1, 2}. That

Oops. That lasted all of ... (15:30:23 -0400) - (17:32:04 -0400), 22 hours,
minus a minute or so. Oh well.

Eric


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3IJDgRN001691 for <[e-mail]>; Fri, 18 Apr 2003 21:13:42 +0200 (MEST)
Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h3IJDg5o001690 for ietf-provreg-outgoing; Fri, 18 Apr 2003 21:13:42 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from zak.ecotroph.net ([216.93.164.123]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3IJDfRN001685 for <[e-mail]>; Fri, 18 Apr 2003 21:13:41 +0200 (MEST)
Received: from ecotroph.net (h87.s239.netsol.com [::ffff:216.168.239.87]) (AUTH: LOGIN anewton) by zak.ecotroph.net with esmtp; Fri, 18 Apr 2003 15:13:39 -0400
Message-ID: <[e-mail]>
Date: Fri, 18 Apr 2003 15:30:23 -0400
From: Andrew Newton <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2) Gecko/20021202
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Hollenbeck, Scott" <[e-mail]>
CC: "'Edward Lewis'" <[e-mail]>, [e-mail]
Subject: Re: [ietf-provreg] Boolean vs. Enumerated
References: <5BEA6CDB196A4241B8BE129D309AA4AF10E6CF@vsvapostal8>
In-Reply-To: <5BEA6CDB196A4241B8BE129D309AA4AF10E6CF@vsvapostal8>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Hollenbeck, Scott wrote:
> I'm not sure I understand the practical difference between "do not disclose"
> and "do not disclose because this is personal data".  Why does the "because
> this is personal data" matter to the server operator once I have the "do not
> disclose" part?  If there is no difference we're back to two values that are
> essentially boolean.

In today's world, I'm not sure there are any practical differences.  I 
think most people would treat both equally for right now.

-andy



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3IJ13RN001618 for <[e-mail]>; Fri, 18 Apr 2003 21:01:03 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h3IJ13hV001617 for ietf-provreg-outgoing; Fri, 18 Apr 2003 21:01:03 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3IJ12RN001612 for <[e-mail]>; Fri, 18 Apr 2003 21:01:02 +0200 (MEST)
Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.9/8.12.9) with ESMTP id h3IIqDZj012052; Fri, 18 Apr 2003 14:52:13 -0400 (EDT)
Message-Id: <[e-mail]>
To: Edward Lewis <[e-mail]>
cc: Eric Brunner-Williams in Portland Maine <[e-mail]>, "Hollenbeck, Scott" <[e-mail]>, [e-mail], [e-mail]
Subject: Re: [ietf-provreg] legal entity vs individual person 
In-Reply-To: Your message of "Fri, 18 Apr 2003 14:12:46 EDT." <a05111b13bac5eadb21f7@[192.149.252.108]> 
Date: Fri, 18 Apr 2003 14:52:13 -0400
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Ed,

I don't know how to compare one of these:

	<contact:disclose flag=N><t1><t2>...<tn></contact:disclose>

and one of these:

	<greeting>...<dcp><T1><T2>...<TN></dcp></greeting>

If not both can exist at any time, I don't care that I don't know how
to compare little-t thingees and BIG-T thingees.

All Andy's solved is flag is usefully valued in the range {0, 1, 2}. That
gets personal and impersonal data client-side policed distinctly, it does
not make the reconcilliation with the server-side policy any easier.

> Insinuating that the text doesn't work, as you do above, is not 
> helping anyone at all.  Showing how the text doesn't work *is* 
> helpful - if that is done, we can fix it.  We can't fix unhappiness, 
> we can fix text.

Can I make it any clearer? I don't know the answer, and my preferred
solution, since this doesn't bother a soul other than myself, is to
treat the client-side stuff as broken by definition, and vastly too
expensive to fix.

Someone that cares can fix it. Or not.

Eric


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3IJ01RN001593 for <[e-mail]>; Fri, 18 Apr 2003 21:00:01 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h3IJ005o001580 for ietf-provreg-outgoing; Fri, 18 Apr 2003 21:00:00 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from bean.ar.com (bean.ar.com [66.123.187.68]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3IIxxRN001575 for <[e-mail]>; Fri, 18 Apr 2003 21:00:00 +0200 (MEST)
Received: from flash.ar.com (wessorh@flash [66.123.187.80]) by bean.ar.com (8.12.6/8.12.6) with ESMTP id h3IIu6dX011048; Fri, 18 Apr 2003 11:56:06 -0700 (PDT)
Date: Fri, 18 Apr 2003 11:56:09 -0700 (PDT)
From: Rick Wesson <[e-mail]>
To: "Hollenbeck, Scott" <[e-mail]>
cc: "'Edward Lewis'" <[e-mail]>, <[e-mail]>
Subject: Re: [ietf-provreg] Boolean vs. Enumerated
In-Reply-To: <5BEA6CDB196A4241B8BE129D309AA4AF10E6CF@vsvapostal8>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

the reason for non-disclosure is not in the IESG requirements as discussed
in SF and I do not believe we need to acknolege why its ns not disclosed in
the protocol.

-rick



On Fri, 18 Apr 2003, Hollenbeck, Scott wrote:

> > So, from the chair's view, it seems like we have a proposal that is
> > generally accepted plus a modification to placate the outstanding
> > issue.
>
> If that's the case, can we focus on discussing the issue of a boolean flag
> vs. a set of enumerated values and the set of values that Andy listed?
>
> I'm not sure I understand the practical difference between "do not disclose"
> and "do not disclose because this is personal data".  Why does the "because
> this is personal data" matter to the server operator once I have the "do not
> disclose" part?  If there is no difference we're back to two values that are
> essentially boolean.
>
> -Scott-
>



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3IItsRN001547 for <[e-mail]>; Fri, 18 Apr 2003 20:55:54 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h3IItsxo001546 for ietf-provreg-outgoing; Fri, 18 Apr 2003 20:55:54 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from bartok.sidn.nl (bartok.sidn.nl [193.176.144.164]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3IItrRN001541 for <[e-mail]>; Fri, 18 Apr 2003 20:55:53 +0200 (MEST)
Received: from bartok.sidn.nl (localhost.sidn.nl [IPv6:::1]) by bartok.sidn.nl (8.12.9/8.12.9) with ESMTP id h3IItqbd046611 for <[e-mail]>; Fri, 18 Apr 2003 20:55:52 +0200 (CEST) (envelope-from [e-mail])
Received: (from jaap@localhost) by bartok.sidn.nl (8.12.9/8.12.6/Submit) id h3IItqbL046610 for [e-mail]; Fri, 18 Apr 2003 20:55:52 +0200 (CEST)
Received: from nohope.patoche.org (nohope.patoche.org [80.67.173.199]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3IEAsRN029216 for <[e-mail]>; Fri, 18 Apr 2003 16:10:54 +0200 (MEST)
Received: from nohope.patoche.org (localhost.gandi.net [127.0.0.1]) by nohope.patoche.org (8.12.3/8.12.3/Debian-6.3) with ESMTP id h3IEAqnL010895 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <[e-mail]>; Fri, 18 Apr 2003 16:10:52 +0200
Received: (from patrick@localhost) by nohope.patoche.org (8.12.3/8.12.3/Debian-6.3) id h3IEAqh0010893 for [e-mail]; Fri, 18 Apr 2003 16:10:52 +0200
Date: Fri, 18 Apr 2003 16:10:51 +0200
From: Patrick <[e-mail]>
To: [e-mail]
Subject: [ietf-provreg] Implementation of EPP (& RRP) in Perl
Message-ID: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.28i
X-PGP-KeyID: A241FB6B
X-PGP-Fingerprint: 9DA9 5054 7A5D 03FC A9AD  9AFF 1371 9F06 A241 FB6B
X-Request-PGP: http://www.keyserver.net:11371/pks/lookup?op=vindex&search=0xA241FB6B
Sender: [e-mail]
Precedence: bulk

As promised a long time ago[1], a new implementation of EPP is
available under the GPL at http://open.gandi.net/download/IRI/

It is based on earlier drafts of EPP, but is in fact more of an
abstraction layer over Registries, hiding transport, protocol and
policy from the application, thus it implements 5 Registries (3 first
new gTLD, and those for .CNO), 2 protocols (RRP & 3 versions of EPP),
and 2 transports (TCP & TLS), in a way that calling application do
not have to bother with details.

It is done in an OO manner with Perl. It is not perfect, but works in
production for a Registrar handling 400000 domain names under
.CNOBIN.

Please forward all questions/discussion to the dedicated
mailing-list.
Details at http://open.gandi.net/#list


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

-- 
Patrick.
``The difference between genius and stupidity is that genius has its limits.''



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3IIl7RN001465 for <[e-mail]>; Fri, 18 Apr 2003 20:47:07 +0200 (MEST)
Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h3IIl78j001464 for ietf-provreg-outgoing; Fri, 18 Apr 2003 20:47:07 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.237.102]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3IIl6RN001459 for <[e-mail]>; Fri, 18 Apr 2003 20:47:07 +0200 (MEST)
Received: from vsvapostalgw3.prod.netsol.com (vsvapostalgw3.prod.netsol.com [10.170.12.61]) by heron.verisign.com (8.12.9/8.12.9) with ESMTP id h3IIimaj000630; Fri, 18 Apr 2003 14:44:48 -0400 (EDT)
Received: by vsvapostalgw3.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <J1JWCR5Y>; Fri, 18 Apr 2003 14:43:24 -0400
Message-ID: <5BEA6CDB196A4241B8BE129D309AA4AF10E6CF@vsvapostal8>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Edward Lewis'" <[e-mail]>
Cc: [e-mail]
Subject: [ietf-provreg] Boolean vs. Enumerated
Date: Fri, 18 Apr 2003 14:43:26 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

> So, from the chair's view, it seems like we have a proposal that is 
> generally accepted plus a modification to placate the outstanding 
> issue.

If that's the case, can we focus on discussing the issue of a boolean flag
vs. a set of enumerated values and the set of values that Andy listed?

I'm not sure I understand the practical difference between "do not disclose"
and "do not disclose because this is personal data".  Why does the "because
this is personal data" matter to the server operator once I have the "do not
disclose" part?  If there is no difference we're back to two values that are
essentially boolean.

-Scott-


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3IIaZRN001390 for <[e-mail]>; Fri, 18 Apr 2003 20:36:35 +0200 (MEST)
Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h3IIaZGn001389 for ietf-provreg-outgoing; Fri, 18 Apr 2003 20:36:35 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from smtp2.arin.net (smtp2.arin.net [192.149.252.32]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3IIaYRN001384 for <[e-mail]>; Fri, 18 Apr 2003 20:36:34 +0200 (MEST)
Received: by smtp2.arin.net (Postfix, from userid 5003) id 99304333; Fri, 18 Apr 2003 14:36:29 -0400 (EDT)
Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id B1F2D321; Fri, 18 Apr 2003 14:36:28 -0400 (EDT)
Received: from [192.136.136.61] (HELO [192.149.252.108]) by arin.net (CommuniGate Pro SMTP 4.0.6) with ESMTP id 190010; Fri, 18 Apr 2003 14:26:46 -0400
Mime-Version: 1.0
X-Sender: edlewis@mta
Message-Id: <a05111b13bac5eadb21f7@[192.149.252.108]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Fri, 18 Apr 2003 14:12:46 -0400
To: Eric Brunner-Williams in Portland Maine <[e-mail]>
From: Edward Lewis <[e-mail]>
Subject: Re: [ietf-provreg] legal entity vs individual person
Cc: "Hollenbeck, Scott" <[e-mail]>, "'Eric Brunner-Williams in Portland Maine'" <[e-mail]>, [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Status: No, hits=-3.2 required=5.0 tests=AWL,EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES, SIGNATURE_SHORT_SPARSE,SPAM_PHRASE_00_01 version=2.43-arin1
X-Spam-Level: 
Sender: [e-mail]
Precedence: bulk

At 13:17 -0400 4/18/03, Eric Brunner-Williams in Portland Maine wrote:

>The proponants of client-side should provide the editor text that works.

As a process point, that has happened.

The words in 
http://www.cafax.se/ietf-provreg/maillist/2003-04/msg00058.html are 
even a melding of comments from various members of the group, they 
are not solely the first offerings of only the editor.  In addition 
to that, Andy proposed a modification once it was more clear what 
your beef was.

So, from the chair's view, it seems like we have a proposal that is 
generally accepted plus a modification to placate the outstanding 
issue.

Insinuating that the text doesn't work, as you do above, is not 
helping anyone at all.  Showing how the text doesn't work *is* 
helpful - if that is done, we can fix it.  We can't fix unhappiness, 
we can fix text.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            [phone]
ARIN Research Engineer

"I'm sorry, sir, your flight is delayed for maintenance.  We are
pounding out the dents from the last landing."


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3IIQLRN001331 for <[e-mail]>; Fri, 18 Apr 2003 20:26:21 +0200 (MEST)
Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h3IIQLKt001330 for ietf-provreg-outgoing; Fri, 18 Apr 2003 20:26:21 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3IIQJRN001325 for <[e-mail]>; Fri, 18 Apr 2003 20:26:20 +0200 (MEST)
Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.9/8.12.9) with ESMTP id h3IIIlZj011952; Fri, 18 Apr 2003 14:18:47 -0400 (EDT)
Message-Id: <[e-mail]>
To: "Hollenbeck, Scott" <[e-mail]>
cc: "'Eric Brunner-Williams in Portland Maine'" <[e-mail]>, [e-mail], [e-mail]
Subject: Re: [ietf-provreg] legal entity vs individual person 
In-Reply-To: Your message of "Fri, 18 Apr 2003 13:39:03 EDT." <5BEA6CDB196A4241B8BE129D309AA4AF10E6CE@vsvapostal8> 
Date: Fri, 18 Apr 2003 14:18:47 -0400
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Scott,

I didn't drink the koolaide that was passed around at San Francisco.

I didn't propose client-side.

I didn't propose the following flawed ideas:
	"privacy" is binary valued
	"privacy" is "the same" for individuals and non-individuals
But I have spent some time on them, for very little public results.

I don't like the _theory_ of client-side. I wouldn't like it if some
QoS edge-yokle claimed that an edge-node could force arbitrary policy
on a bandwidth provisioning registry, break-da-net-but-gimme-my-MTV.

I don't like the turning away from the possibility that social data
can be usefully managed within some frameworks, whether public law or
private.

The degree of goofiness has diminished over time, it began with arbitrary
pervasive binary toggles, and has moved into something less crazy, but
it isn't yet obvious to me that it is trivial to fix, to reconcile two
mechanisms, the <dcp> and the <c:d f=N> elements.

If no one provides the editor with useful text, you have some latitude
over changes that are purely editorial in nature.

If there is consensus to approve what resembles the IESG's fiat, I do
not mind. It is optional to deploy, so it really doesn't matter if the
client-side bits can't work with the server-side bits, and after all,
the IESG might not be bright enough to detect "gundecking" (new paint
over rusty metal).

In my opinion, this hasn't been the best use of my time, or yours, or
anyone's. I was happy as a clam at high tide when we just had a <dcp>,
I wasn't even bothered that most implementors would not implement it,
or that some operators would find the whole idea foreign.

I'm going to muck with a portmaster, some switches and some routers,
and think about something else. Have a nice weekend, find some eggs.

Eric




Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3IHd5RN000979 for <[e-mail]>; Fri, 18 Apr 2003 19:39:05 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h3IHd5ig000978 for ietf-provreg-outgoing; Fri, 18 Apr 2003 19:39:05 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.237.102]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3IHd4RN000973 for <[e-mail]>; Fri, 18 Apr 2003 19:39:04 +0200 (MEST)
Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [10.170.12.38]) by heron.verisign.com (8.12.9/8.12.9) with ESMTP id h3IHePaj028467; Fri, 18 Apr 2003 13:40:25 -0400 (EDT)
Received: by vsvapostalgw1.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <J1LGS8VN>; Fri, 18 Apr 2003 13:39:02 -0400
Message-ID: <5BEA6CDB196A4241B8BE129D309AA4AF10E6CE@vsvapostal8>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Eric Brunner-Williams in Portland Maine'" <[e-mail]>
Cc: [e-mail]
Subject: RE: [ietf-provreg] legal entity vs individual person 
Date: Fri, 18 Apr 2003 13:39:03 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

> The client-side proposal is not my proposal.
> 
> The proponants of client-side should provide the editor text 
> that works.

Proposed text is already on the list for discussion.  If you're arguing that
the text is inadequate, I've requested text from the WG to address whatever
anyone feels is inadequate.  If you're arguing that the whole approach is
inadequate I'll ask for one of two things:

1. A new, clear, concise alternative, or

2. A consensus call so we can get past this issue once and for all.

We've talked about this for months and no one has produced anything that
resembles #1.  It's (past) time to make a decision.

-Scott-


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3IHOeRN000856 for <[e-mail]>; Fri, 18 Apr 2003 19:24:40 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h3IHOexK000855 for ietf-provreg-outgoing; Fri, 18 Apr 2003 19:24:40 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3IHOcRN000850 for <[e-mail]>; Fri, 18 Apr 2003 19:24:39 +0200 (MEST)
Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.9/8.12.9) with ESMTP id h3IHH7Zj011770; Fri, 18 Apr 2003 13:17:07 -0400 (EDT)
Message-Id: <[e-mail]>
To: "Hollenbeck, Scott" <[e-mail]>
cc: "'Eric Brunner-Williams in Portland Maine'" <[e-mail]>, [e-mail], [e-mail]
Subject: Re: [ietf-provreg] legal entity vs individual person 
In-Reply-To: Your message of "Fri, 18 Apr 2003 13:08:56 EDT." <5BEA6CDB196A4241B8BE129D309AA4AF10E6CD@vsvapostal8> 
Date: Fri, 18 Apr 2003 13:17:07 -0400
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Scott,

The client-side proposal is not my proposal.

The proponants of client-side should provide the editor text that works.

Eric


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3IHAWRN000714 for <[e-mail]>; Fri, 18 Apr 2003 19:10:32 +0200 (MEST)
Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h3IHAWxB000713 for ietf-provreg-outgoing; Fri, 18 Apr 2003 19:10:32 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3IHAURN000706 for <[e-mail]>; Fri, 18 Apr 2003 19:10:31 +0200 (MEST)
Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.9/8.12.9) with ESMTP id h3IH2xZj011736 for <[e-mail]>; Fri, 18 Apr 2003 13:02:59 -0400 (EDT)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: [ietf-provreg] legal entity vs individual person
Date: Fri, 18 Apr 2003 13:02:59 -0400
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

It's been suggested that I move this from off-list commentary about what we
are discussing, to on-list. Here is the suggest-you-do-publish (pun) bit:


>The technical questions of the moment here, client-side <dnp> assumed are:
>	1. is a mechanism for distingishing personal data from non-personal
>	   data present in the specification,
>	2. is there an IESG draft "best practices" (worst IMHO) document
>	   that depricates mechanisms which distingish personal data from
>	   non-personal data in any specification.



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3IH8wRN000674 for <[e-mail]>; Fri, 18 Apr 2003 19:08:58 +0200 (MEST)
Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h3IH8wPs000673 for ietf-provreg-outgoing; Fri, 18 Apr 2003 19:08:58 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.237.102]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3IH8vRN000668 for <[e-mail]>; Fri, 18 Apr 2003 19:08:58 +0200 (MEST)
Received: from vsvapostalgw3.prod.netsol.com (vsvapostalgw3.prod.netsol.com [10.170.12.61]) by heron.verisign.com (8.12.9/8.12.9) with ESMTP id h3IHAJaj027630; Fri, 18 Apr 2003 13:10:19 -0400 (EDT)
Received: by vsvapostalgw3.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <J1JWCP0L>; Fri, 18 Apr 2003 13:08:54 -0400
Message-ID: <5BEA6CDB196A4241B8BE129D309AA4AF10E6CD@vsvapostal8>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Eric Brunner-Williams in Portland Maine'" <[e-mail]>
Cc: [e-mail]
Subject: RE: [ietf-provreg] legal entity vs individual person 
Date: Fri, 18 Apr 2003 13:08:56 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

> Scott wrote:
> > Well, that's the proposed text, with appropriate changes 
> required elsewhere
> > in the document to maintain consistency.  Fire away.
> 
> OK. I hope this helps. Of course, hopes and effects are 
> rarely coincident.

It doesn't help me.  Given the amount of time we've spent on this topic over
the last several months, I need specific suggestions that address the text
that I sent to he list earlier this week.

-Scott-


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3IGTpRN000394 for <[e-mail]>; Fri, 18 Apr 2003 18:29:51 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h3IGToDb000393 for ietf-provreg-outgoing; Fri, 18 Apr 2003 18:29:50 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3IGTnRN000388 for <[e-mail]>; Fri, 18 Apr 2003 18:29:49 +0200 (MEST)
Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.9/8.12.9) with ESMTP id h3IGL0Zj011603; Fri, 18 Apr 2003 12:21:00 -0400 (EDT)
Message-Id: <[e-mail]>
To: Edward Lewis <[e-mail]>
cc: Eric Brunner-Williams in Portland Maine <[e-mail]>, Ted Hardie <[e-mail]>, [e-mail], [e-mail]
Subject: Re: [ietf-provreg] legal entity vs individual person 
In-Reply-To: Your message of "Thu, 17 Apr 2003 22:08:25 EDT." <a05111b00bac509286fe5@[192.149.252.108]> 
Date: Fri, 18 Apr 2003 12:21:00 -0400
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Suppose a non-null <dcp> is contained in <greeting>.

Suppose the reply (to <greeting>) is <login>

Suppose a subsequent <contact:create> element containes a <contact:disclose>
element.

  An EPP error response MUST be returned if a <create> command can not  
  be processed for any reason.

  2308    "Data management policy violation"

We don't actually know the following:

	1. how to compare the comparable (if any) child elements of the
	   server-side <dcp> and the client-side <c:d>.

It is possible that dcpRecipientType=="ours" means the same thing as the
<contact:disclose flag="0">, but so far this is unspecified.

	2. if 1 (above) were answered, and the evaluation of the two blobs
	   of syntax returned a result other than "equal", which of the two
	   blobs would take precident.

It is possible that inequality (unspecified) could be totally, or partially
ordered (also unspecified), and some evaluations result in a 2308, and some
not.

  A server MAY end a session due to client inactivity or excessive
  client session longevity.  The parameters for determining excessive
  client inactivity or session longevity are a matter of server policy
  and are not specified by this protocol.

	3. if 2 (above) were answered, and some evaluation could result in
	   2308, and servers MAY terminate sessions for reasons not specified,
	   which of the two, 2308 or sever-side session termination, takes
	   precident.

It is possible that a server could "drop" sessions that would result in an
2308 error, and establish a new session with an "improved" <dcp> that would
not cause a 2308 error.

	4. if 3 (above) were answered, and a server "tunes" its <dcp> to not
	   generate a 2308 for a specific <contact:disclose>, what changes
	   to the <dcp> that are not strictly required to avoid a 2308 are
	   allowed. (I know this can be restated better.)

It is possible that a server could "abandon" its <dcp> upon discovery of a
<contact:disclose>, and restate its <dcp> as the offered :disclose only.
A non-null <contact:disclose> could remove any restriction on the collection
policy, without detection by a client.

Well, I've got to take care of some real-life stuff. I see evaluation as a
non-trivial problem. In simple terms, Randy tells GoDaddy to <dnp> him out
of whois:43, GoDaddy says "Yup", and flogs a <c:d f=0> at VGRS, which had
a EU-friendly <dcp> in its greeting, with "strong protection" (burn before
reading, no body gets anything, etc.). VGRS sees the GoDaddy <c:d f=0>, and
flickers the session, now with a DoubleClick-friendly <dcp>, which has Randy
opt-in to arbitrary repurpose, infinite data retention, and infrequent baths.
Randy isn't in whois:43. Is he happy?

Scott wrote:
> Well, that's the proposed text, with appropriate changes required elsewhere
> in the document to maintain consistency.  Fire away.

OK. I hope this helps. Of course, hopes and effects are rarely coincident.

Appologies to GoDaddy and VGRS, I simply needed some real names to (ab)use.

Eric


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3IEvlRN029613 for <[e-mail]>; Fri, 18 Apr 2003 16:57:47 +0200 (MEST)
Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h3IEvk3d029612 for ietf-provreg-outgoing; Fri, 18 Apr 2003 16:57:46 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from smtp2.arin.net (smtp2.arin.net [192.149.252.32]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3IEvjRN029607 for <[e-mail]>; Fri, 18 Apr 2003 16:57:46 +0200 (MEST)
Received: by smtp2.arin.net (Postfix, from userid 5003) id B5C003C1; Fri, 18 Apr 2003 10:57:45 -0400 (EDT)
Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id 45C713AC; Fri, 18 Apr 2003 10:57:45 -0400 (EDT)
Received: from [192.136.136.61] (HELO [192.149.252.108]) by arin.net (CommuniGate Pro SMTP 4.0.6) with ESMTP id 189771; Fri, 18 Apr 2003 10:47:56 -0400
Mime-Version: 1.0
X-Sender: edlewis@mta
Message-Id: <a05111b0bbac5c21c9540@[192.149.252.108]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Fri, 18 Apr 2003 10:57:29 -0400
To: Eric Brunner-Williams in Portland Maine <[e-mail]>
From: Edward Lewis <[e-mail]>
Subject: Re: [ietf-provreg] legal entity vs individual person
Cc: Edward Lewis <[e-mail]>, Eric Brunner-Williams in Portland Maine <[e-mail]>, Ted Hardie <[e-mail]>, [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Status: No, hits=-3.2 required=5.0 tests=AWL,EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES, SIGNATURE_SHORT_SPARSE,SPAM_PHRASE_00_01 version=2.43-arin1
X-Spam-Level: 
Sender: [e-mail]
Precedence: bulk

At 10:40 -0400 4/18/03, Eric Brunner-Williams in Portland Maine wrote:

Ah.

>I want "business privacy" NOT AT ALL, but if it must exist (same modulo
>as above), as a DISTINCT part of the core, or as a DISTINCT extension.
>
>I don't want "it". If "it" exists, I want "it" to come in separate units
>of syntax (or a three valued type, as Andrew suggested, which has the
>same semantic result).

Okay, let's get some group comment on Andy's suggestion.

Calendar note: today is a holiday for quite a few, so I'll be patient...

>Now the IETF fiat (or mazda) is that <mumble> be in the core. I suppose

Interesting.  Andy and I both drive Mazdas.  My plates are IP6ARPA.  Really. ;)

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            [phone]
ARIN Research Engineer

"I'm sorry, sir, your flight is delayed for maintenance.  We are
pounding out the dents from the last landing."


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3IEonRN029531 for <[e-mail]>; Fri, 18 Apr 2003 16:50:49 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h3IEondG029530 for ietf-provreg-outgoing; Fri, 18 Apr 2003 16:50:49 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from zak.ecotroph.net ([216.93.164.123]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3IEolRN029525 for <[e-mail]>; Fri, 18 Apr 2003 16:50:48 +0200 (MEST)
Received: from ecotroph.net (h87.s239.netsol.com [::ffff:216.168.239.87]) (AUTH: LOGIN anewton) by zak.ecotroph.net with esmtp; Fri, 18 Apr 2003 10:50:45 -0400
Message-ID: <[e-mail]>
Date: Fri, 18 Apr 2003 11:07:27 -0400
From: Andrew Newton <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2) Gecko/20021202
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Ed Allen Smith <[e-mail]>
CC: [e-mail]
Subject: Re: [ietf-provreg] legal entity vs individual person
References: <[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Ed Allen Smith wrote:
>>Instead of flag being true or false, it is an enumerated type with the 
>>following allowable values:
>>  ok to disclose
>>  do not disclose
>>  do not disclose because this is personal data
> 
> 
> Should attempting to use the last for a DNS server's IP address (at least
> for IPv4) be considered a syntax error? And what's the default state (I
> suggest _one_ of the above be the default for _all_, to remove disputes over
> "should this default on or off" and people _forgetting_ in programming,
> etcetera whether things default on or off...)?

Scott's wording said this was about contact attributes (if I've got this 
wrong Scott, please correct me).  So I would think applying any of this 
to an IP address is a syntax error.

I also made the assumption that the <contact:disclose> element would 
only be sent when the value of the 'flag' attribute would be something 
other than the default disclosure policy.  Regardless of the number of 
states, this might need to be clearer.

-andy



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3IEneRN029483 for <[e-mail]>; Fri, 18 Apr 2003 16:49:40 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h3IEneZx029482 for ietf-provreg-outgoing; Fri, 18 Apr 2003 16:49:40 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3IEndRN029477 for <[e-mail]>; Fri, 18 Apr 2003 16:49:39 +0200 (MEST)
Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.9/8.12.9) with ESMTP id h3IEenZj011315; Fri, 18 Apr 2003 10:40:49 -0400 (EDT)
Message-Id: <[e-mail]>
To: Edward Lewis <[e-mail]>
cc: Eric Brunner-Williams in Portland Maine <[e-mail]>, Ted Hardie <[e-mail]>, [e-mail], [e-mail]
Subject: Re: [ietf-provreg] legal entity vs individual person 
In-Reply-To: Your message of "Fri, 18 Apr 2003 10:29:33 EDT." <a05111b07bac5baf1e6e1@[192.149.252.108]> 
Date: Fri, 18 Apr 2003 10:40:49 -0400
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

> >If it isn't too difficult, in which message?
> 
> http://www.cafax.se/ietf-provreg/maillist/2003-04/msg00069.html
> 
> >Date: Wed, 16 Apr 2003 08:25:38 -0400
> >Sounds extentional. I can see some operators putting "business privacy" on
> >the same level as "human privacy", and some not.
> 
> That one.  When you said that, my interpretation was that you see 
> this as a policy issue, not a protocol issue, hence EPP ought not 
> distinguish.

OK. Easy enough mistake.

I want "human privacy", in the client-side <mumble> (modulo I don't want
the client side <mumble>, and I don't think "privacy" should just mean
the recipient, but accepting these defects -- IMHO -- as the consensus of
this WG), as either part of the core, or as an extension.

I want "business privacy" NOT AT ALL, but if it must exist (same modulo
as above), as a DISTINCT part of the core, or as a DISTINCT extension.

I don't want "it". If "it" exists, I want "it" to come in separate units
of syntax (or a three valued type, as Andrew suggested, which has the
same semantic result).

Now the IETF fiat (or mazda) is that <mumble> be in the core. I suppose
this would apply to both "human privacy" and "business privacy", since
their best contribution on the subject is that the two are, or should be,
indistinguishable.

Thanks for the quick turn-around!
Eric


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3IEThRN029360 for <[e-mail]>; Fri, 18 Apr 2003 16:29:43 +0200 (MEST)
Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h3IEThPI029359 for ietf-provreg-outgoing; Fri, 18 Apr 2003 16:29:43 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from smtp2.arin.net (smtp2.arin.net [192.149.252.32]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3IETgRN029354 for <[e-mail]>; Fri, 18 Apr 2003 16:29:42 +0200 (MEST)
Received: by smtp2.arin.net (Postfix, from userid 5003) id D2BF8324; Fri, 18 Apr 2003 10:29:41 -0400 (EDT)
Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id 5EA2A30E; Fri, 18 Apr 2003 10:29:41 -0400 (EDT)
Received: from [192.136.136.61] (HELO [192.149.252.108]) by arin.net (CommuniGate Pro SMTP 4.0.6) with ESMTP id 189739; Fri, 18 Apr 2003 10:19:59 -0400
Mime-Version: 1.0
X-Sender: edlewis@mta
Message-Id: <a05111b07bac5baf1e6e1@[192.149.252.108]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Fri, 18 Apr 2003 10:29:33 -0400
To: Eric Brunner-Williams in Portland Maine <[e-mail]>
From: Edward Lewis <[e-mail]>
Subject: Re: [ietf-provreg] legal entity vs individual person
Cc: Edward Lewis <[e-mail]>, Eric Brunner-Williams in Portland Maine <[e-mail]>, Ted Hardie <[e-mail]>, [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_SPARSE,SPAM_PHRASE_05_08 version=2.43-arin1
X-Spam-Level: 
Sender: [e-mail]
Precedence: bulk

At 10:10 -0400 4/18/03, Eric Brunner-Williams in Portland Maine wrote:
>>  As far as your input, it seems that in one message you did not want
>>  to make a distinction between personal and corporate.
>
>If it isn't too difficult, in which message?

http://www.cafax.se/ietf-provreg/maillist/2003-04/msg00069.html

>Date: Wed, 16 Apr 2003 08:25:38 -0400
>Sounds extentional. I can see some operators putting "business privacy" on
>the same level as "human privacy", and some not.

That one.  When you said that, my interpretation was that you see 
this as a policy issue, not a protocol issue, hence EPP ought not 
distinguish.

Using the word "extentional" (which Merriam-Webster has no definition 
for) I assumed that you were urging that the distinction be shoved 
into a policy specific extension, reinforcing the notion that the 
protocol not make the distinction.

Based on my read of this, I saw that all contributors felt that the 
protocol not distinguish.  With no other comments on the text at 
hand, it certainly looked like consensus was reached.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            [phone]
ARIN Research Engineer

"I'm sorry, sir, your flight is delayed for maintenance.  We are
pounding out the dents from the last landing."


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3IEJARN029280 for <[e-mail]>; Fri, 18 Apr 2003 16:19:10 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h3IEJAB9029279 for ietf-provreg-outgoing; Fri, 18 Apr 2003 16:19:10 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3IEJ9RN029274 for <[e-mail]>; Fri, 18 Apr 2003 16:19:09 +0200 (MEST)
Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.9/8.12.9) with ESMTP id h3IEANZj011212; Fri, 18 Apr 2003 10:10:23 -0400 (EDT)
Message-Id: <[e-mail]>
To: Edward Lewis <[e-mail]>
cc: Eric Brunner-Williams in Portland Maine <[e-mail]>, Ted Hardie <[e-mail]>, [e-mail], [e-mail]
Subject: Re: [ietf-provreg] legal entity vs individual person 
In-Reply-To: Your message of "Thu, 17 Apr 2003 22:08:25 EDT." <a05111b00bac509286fe5@[192.149.252.108]> 
Date: Fri, 18 Apr 2003 10:10:23 -0400
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

> As far as your input, it seems that in one message you did not want 
> to make a distinction between personal and corporate.

If it isn't too difficult, in which message?

Date: Tue, 15 Apr 2003 17:00:59 -0400
Putting org in is a mistake. People have "privacy", non-people don't.

Date: Tue, 15 Apr 2003 18:52:11 -0400
I don't mind a mechanism existing for "secrecy", but I do mind calling it
"privacy".
...
So, if a mechanism to partition the read-access on a repository is desired,
and general, that part that meets the policy meta-requirement for "privacy"
(and data protection) can be packaged as "privacy" (and dcp). That part that
meets other policy reqiurements can be packaged as "other".

Date: Tue, 15 Apr 2003 20:36:47 -0400
non-disclosure by a legal entity (not an individual person).

Date: Wed, 16 Apr 2003 08:25:38 -0400
Sounds extentional. I can see some operators putting "business privacy" on
the same level as "human privacy", and some not.

Date: Wed, 16 Apr 2003 09:39:36 -0400
Data that may identify individual persons is identified and policied.
See <mumble>.

Date: Wed, 16 Apr 2003 19:15:03 -0400
I think such an assertion is fundamentally unlearned.

Date: Wed, 16 Apr 2003 21:24:29 -0400
It is possible to have both a sensible individual "privacy", and a sensible
non-individual "secrecy", but not by asserting that the two are utterly
indistinguishable.

God am I tired of this.
Eric


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3ID9TRN028647 for <[e-mail]>; Fri, 18 Apr 2003 15:09:29 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h3ID9Tj2028646 for ietf-provreg-outgoing; Fri, 18 Apr 2003 15:09:29 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from smtp2.arin.net (smtp2.arin.net [192.149.252.32]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3ID9SRN028641 for <[e-mail]>; Fri, 18 Apr 2003 15:09:28 +0200 (MEST)
Received: by smtp2.arin.net (Postfix, from userid 5003) id 99C1B332; Fri, 18 Apr 2003 09:09:25 -0400 (EDT)
Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id F331A322; Fri, 18 Apr 2003 09:09:24 -0400 (EDT)
Received: from [192.136.136.61] (HELO [192.149.252.108]) by arin.net (CommuniGate Pro SMTP 4.0.6) with ESMTP id 189640; Fri, 18 Apr 2003 08:59:42 -0400
Mime-Version: 1.0
X-Sender: edlewis@mta (Unverified)
Message-Id: <a05111b00bac509286fe5@[192.149.252.108]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Thu, 17 Apr 2003 22:08:25 -0400
To: Eric Brunner-Williams in Portland Maine <[e-mail]>
From: Edward Lewis <[e-mail]>
Subject: Re: [ietf-provreg] legal entity vs individual person
Cc: Edward Lewis <[e-mail]>, Eric Brunner-Williams in Portland Maine <[e-mail]>, Ted Hardie <[e-mail]>, [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,DATE_IN_PAST_06_12,IN_REP_TO,REFERENCES, SIGNATURE_SHORT_SPARSE,SPAM_PHRASE_03_05 version=2.43-arin1
X-Spam-Level: 
Sender: [e-mail]
Precedence: bulk

At 18:10 -0400 4/17/03, Eric Brunner-Williams in Portland Maine wrote:
>You got consensus on this in two days. Kwel!

I'd have to say that, yes, we've managed to come to a consensus on 
this.  Again refusing to put hard metrics on what this means, we did 
have a fair spread of participants contributing comments that appear 
to be in agreement.

As far as your input, it seems that in one message you did not want 
to make a distinction between personal and corporate.   Now it seems 
you do.  Whether or not you changed your mind - which I might add is 
perfectly fine - when it came time for me to make a call on 
consensus, I figured that you agreed.

I mention that you participated to say that this is something that 
happened with you involved.  I mentioned two days to point out that 
this was a fairly fresh discussion.

>Would things go faster if the discussion period were shortened?

I assume you are insinuating that we are rushing this through.

Baring any comments to the contrary, why hold up an idea that seems 
to be met with only supporting comments?  In this case, there was one 
issue raised, but then is seemed to be washed over.  Looking deeper 
at the issue, as a chair I felt that trying to make the distinction 
was too much effort given our goal.

>Maybe we could simply dispense with discussion altogether.

Keep in mind that the words that Scott put on to the list did not 
appear out of thin air.  The words he sent on last Tuesday afternoon 
(US-EDT) are based on a older proposal as described in a message he 
sent at Mon, 31 Mar 2003 08:27:51 -0500.  (I am off-net as I write, 
so I don't have access to the URLs).

The point is that the proposal has been out there for quite a while - 
December of last year - so there's reason for a co-chair to expect a 
quickly achieved consensus.

>I know this is politically charged, and many people would like to ...
>gore someone else's ox, but crapy mail from infantile uber-experts,
>first Randy, now Ted, and playing fast-and-loose with process is just
>unnecessary.

This is rather impolite.

In the balance of fast and slow, fast is better.  Too fast isn't 
good, but as fast as safely possible is best.  Instead of throwing 
words like this out - and in so doing more harm than good - why not 
state a reason that would make us give pause to stop and think?

It's possible you have something.  It's possible that the group might 
clear up  the issue for you.

E.g., Andy's suggestion.  That's something constructive to work from.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            [phone]
ARIN Research Engineer

"I'm sorry, sir, your flight is delayed for maintenance.  We are
pounding out the dents from the last landing."


Return-Path: <[e-mail]>
Received: from hotmail.com (61-221-208-55.HINET-IP.hinet.net [61.221.208.55]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3I2IdRN024895 for <[e-mail]>; Fri, 18 Apr 2003 04:18:40 +0200 (MEST)
Message-Id: <[e-mail]>
From: [e-mail]
To: This, is, an, example, To:
Subject: ·Q¸ò§A»¡..§Ú­Ì¤@°_¨Ó§a
Reply-To: [e-mail]
Date: 18 Apr 2003 10:18:39 +0800
Organization: Foobar Inc.
X-Mailer: Gammadyne Mailer
x-delete-me: 1 (this tells Gammadyne's server to delete the message)
MIME-Version: 1.0
Content-Type: text/html
Content-Transfer-Encoding: 8bit

<html>

<head>
<meta http-equiv="Content-Language" content="zh-tw">
<meta http-equiv="Content-Type" content="text/html; charset=big5">
<meta name="GENERATOR" content="Microsoft FrontPage 5.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<title>§A©Î³\·|»¡</title>
</head>

<body>

<p><a href="http://home.kimo.com.tw/vivian661115/index2.htm">
<img border="0" src="http://www.enterbiz.com.tw/678.gif" width="468" height="57"></a>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </p>  

<p>¬°¤°»ò¤@ª½¸ò¦Û¤v¹L¤£¥h©O</p>   
<p>¤£¬O¾á¤ß§ä¤£¨ì¤u§@&nbsp; </p>   
<p>´N¬O¾á¤ß´º®ð¤£¦n¤U¤@­Óµô­û¦³¨S¦³¥i¯à¬O§A</p>   
<p>¤£¾á¤ßµô­û´N«è¦¬¤J¤£¦n</p>   
<p>¤Ï¥¿¶V§V¤O¦ÑÁ󨮤l¶V¤j&nbsp; </p>   
<p>¶V§V¤O&nbsp;&nbsp;&nbsp; ¦ÑÁó©Ð¤l¶V¤j</p>   
<p>­þ­Ó®É­Ô§â¦Û¤vªº»ù­È¯dµ¹¦Û¤v©O</p>   
<p><font size="3" color="#FF0000"><b>¤H¥Íªºªø«×©Î³\§Ú­Ì¤£¯à±±¨î&nbsp;&nbsp;&nbsp;&nbsp;    
¦ý¼e«×§Ú­Ì¥i¥H¦Û¤v´x´¤&nbsp; ¿ï¾ÜÅý¤H¥ÍÅܪººëªö</b></font></p>   
<p>¡@</p> 
<p><a href="http://home.kimo.com.tw/vivian661115/index2.htm">
<img border="0" src="http://tw.yimg.com/a/tw/k_lea/249896_n_0331.gif" width="468" height="60"></a></p>
<p>¡@</p>

</body>

</html>



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3HMhORN022623 for <[e-mail]>; Fri, 18 Apr 2003 00:43:24 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h3HMhODI022622 for ietf-provreg-outgoing; Fri, 18 Apr 2003 00:43:24 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from dogberry.rutgers.edu (dogberry.rutgers.edu [165.230.209.227]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3HMhNRN022617 for <[e-mail]>; Fri, 18 Apr 2003 00:43:23 +0200 (MEST)
Received: from cesario.rutgers.edu ([e-mail] [165.230.209.239]) by dogberry.rutgers.edu (8.12.8p1/8.12.8) with ESMTP id h3HMhpRv011613; Thu, 17 Apr 2003 18:43:51 -0400 (EDT)
Received: (from easmith@localhost) by cesario.rutgers.edu (8.12.8/8.12.8/Submit) id h3HMhoOg015130; Thu, 17 Apr 2003 18:43:50 -0400 (EDT)
Message-Id: <[e-mail]>
From: Ed Allen Smith <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: Thu, 17 Apr 2003 18:43:50 -0400
Cc: [e-mail]
To: [e-mail]
Subject: Re: [ietf-provreg] legal entity vs individual person
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
X-Mailer: VM 7.07 under 21.4 (patch 9) "Informed Management" XEmacs Lucid
Sender: [e-mail]
Precedence: bulk

In message <[e-mail]> (on 17 April 2003 17:32:04 -0400),
[e-mail] (Andrew Newton) wrote:
>Eric Brunner-Williams in Portland Maine wrote:
>> 
>> please check one box, within the scope of a client-side <dnp> oerator,
>> 
>> 	[] there is no such thing as "personal data" semantics
>> 	[] there is such a thing as "personal data"semantics
>> 
>> That is what is the present issue, get consensus on it, and there is
>> nothing left in it to consider.
>
>Would the following work for you?
>
>Instead of flag being true or false, it is an enumerated type with the 
>following allowable values:
>   ok to disclose
>   do not disclose
>   do not disclose because this is personal data

Should attempting to use the last for a DNS server's IP address (at least
for IPv4) be considered a syntax error? And what's the default state (I
suggest _one_ of the above be the default for _all_, to remove disputes over
"should this default on or off" and people _forgetting_ in programming,
etcetera whether things default on or off...)?

	   -Allen

-- 
Allen Smith                       http://cesario.rutgers.edu/easmith/
February 1, 2003                               Space Shuttle Columbia
Ad Astra Per Aspera                     To The Stars Through Asperity


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3HMP6RN022501 for <[e-mail]>; Fri, 18 Apr 2003 00:25:06 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h3HMP63Z022500 for ietf-provreg-outgoing; Fri, 18 Apr 2003 00:25:06 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3HMP5RN022495 for <[e-mail]>; Fri, 18 Apr 2003 00:25:05 +0200 (MEST)
Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.9/8.12.9) with ESMTP id h3HMGSZj008467; Thu, 17 Apr 2003 18:16:28 -0400 (EDT)
Message-Id: <[e-mail]>
To: Andrew Newton <[e-mail]>
cc: Eric Brunner-Williams in Portland Maine <[e-mail]>, Edward Lewis <[e-mail]>, Ted Hardie <[e-mail]>, "'[e-mail]'" <[e-mail]>, [e-mail], [e-mail]
Subject: Re: [ietf-provreg] legal entity vs individual person 
In-Reply-To: Your message of "Thu, 17 Apr 2003 17:32:04 EDT." <[e-mail]> 
Date: Thu, 17 Apr 2003 18:16:28 -0400
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

> Would the following work for you?

Well, it isn't "me", but

>   do not disclose because this is personal data

Look! the raison d'etre for all of this covert 954 work-around, personal data.
Labeled, or meta-labeled, so someone can do something with it, or make damn
sure they don't.

Yes.

THANK YOU ANDREW!

NB, it could still be a binary type, if the silly enclosing glob been where
the de-mux of personal from non-personal was located, <glob-p> and <glob-notp>,
but it amounts to three distinct states, so a finite enum works.

Eric


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3HMIvRN022418 for <[e-mail]>; Fri, 18 Apr 2003 00:18:57 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h3HMIvHJ022417 for ietf-provreg-outgoing; Fri, 18 Apr 2003 00:18:57 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3HMItRN022412 for <[e-mail]>; Fri, 18 Apr 2003 00:18:56 +0200 (MEST)
Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.9/8.12.9) with ESMTP id h3HMAJZj008440; Thu, 17 Apr 2003 18:10:19 -0400 (EDT)
Message-Id: <[e-mail]>
To: Edward Lewis <[e-mail]>
cc: Eric Brunner-Williams in Portland Maine <[e-mail]>, Ted Hardie <[e-mail]>, [e-mail], [e-mail]
Subject: Re: [ietf-provreg] legal entity vs individual person 
In-Reply-To: Your message of "Thu, 17 Apr 2003 17:27:13 EDT." <a05111b06bac4c65ca0e8@[192.149.252.108]> 
Date: Thu, 17 Apr 2003 18:10:19 -0400
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

> This was two days ago, and you participated in this.

You got consensus on this in two days. Kwel!

Would things go faster if the discussion period were shortened? 

Maybe we could simply dispense with discussion altogether.

I know this is politically charged, and many people would like to ...
gore someone else's ox, but crapy mail from infantile uber-experts,
first Randy, now Ted, and playing fast-and-loose with process is just
unnecessary.



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3HLRORN021963 for <[e-mail]>; Thu, 17 Apr 2003 23:27:24 +0200 (MEST)
Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h3HLRNQ0021962 for ietf-provreg-outgoing; Thu, 17 Apr 2003 23:27:23 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from smtp2.arin.net (smtp2.arin.net [192.149.252.32]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3HLRMRN021957 for <[e-mail]>; Thu, 17 Apr 2003 23:27:22 +0200 (MEST)
Received: by smtp2.arin.net (Postfix, from userid 5003) id C0AD138B; Thu, 17 Apr 2003 17:27:21 -0400 (EDT)
Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id 452D5389; Thu, 17 Apr 2003 17:27:21 -0400 (EDT)
Received: from [192.136.136.31] (HELO [192.149.252.108]) by arin.net (CommuniGate Pro SMTP 4.0.6) with ESMTP id 189105; Thu, 17 Apr 2003 17:17:42 -0400
Mime-Version: 1.0
X-Sender: edlewis@mta
Message-Id: <a05111b06bac4c65ca0e8@[192.149.252.108]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Thu, 17 Apr 2003 17:27:13 -0400
To: Eric Brunner-Williams in Portland Maine <[e-mail]>
From: Edward Lewis <[e-mail]>
Subject: Re: [ietf-provreg] legal entity vs individual person
Cc: Ted Hardie <[e-mail]>, <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,IN_REP_TO,REFERENCES,SIGNATURE_SHORT_SPARSE, SPAM_PHRASE_01_02 version=2.43-arin1
X-Spam-Level: 
Sender: [e-mail]
Precedence: bulk

At 16:37 -0400 4/17/03, Eric Brunner-Williams in Portland Maine wrote:
>You need to ask for consensus on the following:
>
>please check one box, within the scope of a client-side <dnp> oerator,
>
>	[] there is no such thing as "personal data" semantics
>	[] there is such a thing as "personal data"semantics
>
>That is what is the present issue, get consensus on it, and there is
>nothing left in it to consider.

I'm pretty darned certain that that has been done too.

Look at the follow ups to:
         http://www.cafax.se/ietf-provreg/maillist/2003-04/msg00058.html

This was two days ago, and you participated in this.

These are voices against making a distinction/or leaving this to policy.

http://www.cafax.se/ietf-provreg/maillist/2003-04/msg00065.html
http://www.cafax.se/ietf-provreg/maillist/2003-04/msg00063.html
http://www.cafax.se/ietf-provreg/maillist/2003-04/msg00068.html
http://www.cafax.se/ietf-provreg/maillist/2003-04/msg00070.html

Your last message:

http://www.cafax.se/ietf-provreg/maillist/2003-04/msg00069.html

makes it sound like you agree too:

     "I can see some operators putting 'business privacy' on
      the same level as 'human privacy', and some not."

Are we to "there is nothing left in it to consider" yet, or am I mistaken?
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            [phone]
ARIN Research Engineer

"I'm sorry, sir, your flight is delayed for maintenance.  We are
pounding out the dents from the last landing."


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3HLFURN021851 for <[e-mail]>; Thu, 17 Apr 2003 23:15:30 +0200 (MEST)
Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h3HLFUnY021850 for ietf-provreg-outgoing; Thu, 17 Apr 2003 23:15:30 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from zak.ecotroph.net ([216.93.164.123]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3HLFTRN021845 for <[e-mail]>; Thu, 17 Apr 2003 23:15:29 +0200 (MEST)
Received: from ecotroph.net (h87.s239.netsol.com [::ffff:216.168.239.87]) (AUTH: LOGIN anewton) by zak.ecotroph.net with esmtp; Thu, 17 Apr 2003 17:15:27 -0400
Message-ID: <[e-mail]>
Date: Thu, 17 Apr 2003 17:32:04 -0400
From: Andrew Newton <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2) Gecko/20021202
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Eric Brunner-Williams in Portland Maine <[e-mail]>
CC: Edward Lewis <[e-mail]>, Ted Hardie <[e-mail]>, "'[e-mail]'" <[e-mail]>, [e-mail]
Subject: Re: [ietf-provreg] legal entity vs individual person
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Eric Brunner-Williams in Portland Maine wrote:
> 
> please check one box, within the scope of a client-side <dnp> oerator,
> 
> 	[] there is no such thing as "personal data" semantics
> 	[] there is such a thing as "personal data"semantics
> 
> That is what is the present issue, get consensus on it, and there is
> nothing left in it to consider.
> 
> Eric

Would the following work for you?

Instead of flag being true or false, it is an enumerated type with the 
following allowable values:
   ok to disclose
   do not disclose
   do not disclose because this is personal data

-andy



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3HKkHRN021518 for <[e-mail]>; Thu, 17 Apr 2003 22:46:17 +0200 (MEST)
Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h3HKkHWc021517 for ietf-provreg-outgoing; Thu, 17 Apr 2003 22:46:17 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3HKkFRN021512 for <[e-mail]>; Thu, 17 Apr 2003 22:46:16 +0200 (MEST)
Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.9/8.12.9) with ESMTP id h3HKbZZj008182; Thu, 17 Apr 2003 16:37:35 -0400 (EDT)
Message-Id: <[e-mail]>
To: Edward Lewis <[e-mail]>
cc: Eric Brunner-Williams in Portland Maine <[e-mail]>, Ted Hardie <[e-mail]>, "'[e-mail]'" <[e-mail]>, [e-mail], [e-mail]
Subject: Re: [ietf-provreg] legal entity vs individual person 
In-Reply-To: Your message of "Thu, 17 Apr 2003 15:47:49 EDT." <a05111b01bac4adfeeaf7@[192.149.252.108]> 
Date: Thu, 17 Apr 2003 16:37:35 -0400
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

1. On the issue of when there was a consensus call, and for what.


http://www.cafax.se/ietf-provreg/maillist/2003-03/msg00104.html
http://www.cafax.se/ietf-provreg/maillist/2003-03/msg00105.html
and
http://www.cafax.se/ietf-provreg/maillist/2003-03/msg00128.html

OK. Thats done. That is consensus to specify a client-side operation.

However, this little dance has assumed a client-side operation.

You need to ask for consensus on the following:

please check one box, within the scope of a client-side <dnp> oerator,

	[] there is no such thing as "personal data" semantics
	[] there is such a thing as "personal data"semantics

That is what is the present issue, get consensus on it, and there is
nothing left in it to consider.

Eric


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3HJm1RN020833 for <[e-mail]>; Thu, 17 Apr 2003 21:48:01 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h3HJm1ad020832 for ietf-provreg-outgoing; Thu, 17 Apr 2003 21:48:01 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from smtp2.arin.net (smtp2.arin.net [192.149.252.32]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3HJm0RN020827 for <[e-mail]>; Thu, 17 Apr 2003 21:48:00 +0200 (MEST)
Received: by smtp2.arin.net (Postfix, from userid 5003) id E3551382; Thu, 17 Apr 2003 15:47:59 -0400 (EDT)
Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id 0BE453C7; Thu, 17 Apr 2003 15:47:59 -0400 (EDT)
Received: from [192.136.136.31] (HELO [192.149.252.108]) by arin.net (CommuniGate Pro SMTP 4.0.6) with ESMTP id 188998; Thu, 17 Apr 2003 15:38:20 -0400
Mime-Version: 1.0
X-Sender: edlewis@mta
Message-Id: <a05111b01bac4adfeeaf7@[192.149.252.108]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Thu, 17 Apr 2003 15:47:49 -0400
To: Eric Brunner-Williams in Portland Maine <[e-mail]>
From: Edward Lewis <[e-mail]>
Subject: Re: [ietf-provreg] legal entity vs individual person
Cc: Edward Lewis <[e-mail]>, Eric Brunner-Williams in Portland Maine <[e-mail]>, Ted Hardie <[e-mail]>, "'[e-mail]'" <[e-mail]>, [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,IN_REP_TO,REFERENCES,SIGNATURE_SHORT_SPARSE, SPAM_PHRASE_01_02 version=2.43-arin1
X-Spam-Level: 
Sender: [e-mail]
Precedence: bulk

At 14:04 -0400 4/17/03, Eric Brunner-Williams in Portland Maine wrote:
>Ed,
>
>At Pittsburg Fred said from the podium that his side of the table (the IESG)
>did not have all the clue. Here we have assertion without justification for
>novel functional requirements -- which is different from the prior IESG dicta
>on manditory mechanisms, e.g., congestion control.

It appears that I have failed to relate all of the story from the 
meeting in SF.  During the face to face meeting, Randy Bush proceeded 
to explain the basis of his comment in such a way that it became 
clear to those of us in attendance that there was an operational 
consideration here.  I submitted the notes from the meeting based on 
the Jabber log, without having the scribe notes.  Here are what lines 
I see as relevant (editing to save space here, the message was on the 
list recently):

# now on to privacy
# ted: addressing privacy brought up by randy bush
# ted: describing registry/registrar/registrant use case
# ted: dcp tells the registrar from registry about privacy
# ted: if registrant has privacy parameters, the registrar checks against
#       the registry and rejects the registration
# ted: in this model, the registrar is handling the intersection between
#       the registrant and registry
# ted: what randy has asked for is a case where the registry handles this.
# ted: in this case, randy wants a mechanism where this is possible.
# ted: mechanism allows registrar to give registrants parameters to registry
# ted: randy wants it at the per element granularity on social data
...
# ed: this is the first time I've heard this argument clear enough to
#      understand the issue

The group then formulated a problems statement from this which was 
put on the mailing list the next week.

As far as I can tell, the comment started out from the IESG, got 
hammered out in a in-person meeting, and resulted in an additional 
requirement accepted by the WG (on the list).  In my opinion, this is 
a far more reaching (and formal) acceptance of the IESG comment than 
happened for the congestion control comment you mention.

>Now is it sensible?

If the ends justify the means. OTOH, given that it took 6 months from 
the handing down of the IESG comments until my statement above, I'd 
say the IESG:WG interface could have been smoother.

>Since London we seem to have been in agreement that some policy required a
>mechanism to disclose some operational practice -- "data protection", and
>"privacy" were the rationales.
>
>This week, these rationals seem to be abandoned. There is no "protection"
>no privacy, only a non-specific access mechanism.
>
>Mind, this is only for the client-side mechanism.

I suppose that you are unhappy that with server-side statement (dcp) 
the protocol is saying "the registry says how is works" and for the 
client-side statement (don't disclose) the protocol has the client 
saying "you figure it out" - as opposed to "the registrar says how it 
works."  Is that your issue?  Are you suggesting that there should be 
a requirement that either of the client and server declare their 
privacy policies?

Barring WG feedback, I don't think that such a suggestion (which are 
words I am putting in your keyboard) would pass. I don't think the 
issue is what policies are being followed, but rather what happens to 
the data sent to the registry - which means that the asymmetric 
"servers says policy or client says what" is appropriate.

>Still, did Randy want the same technical specification for his personal
>registration as Verisign has for its corporate registration? I don't know
>that he did. Maybe that is all he ever wanted.
>
>It concerns me, no it irks me, that IESG clowns blow in with personal opinions
>and fob them off as professional opinions. Yes, we must make less-than-best
>choices to actually have something multiply independently implemented, but it
>does not strictly follow that we must do what Fred would not dare -- assert
>that better knowledge is always on the IESG side of the table.

Reconsider this section of your message in the light of the WG's 
acceptance of the IESG statement.

>It is not sensible to assert the non-existance of "personal data". There is
>a set of references that specify, partially, incoherently, but not negatively,
>some semantic that attaches to datagram, circuit, postal, and other network
>endpoints, as well as to names, when associated with individual persons.
>
>Ed, where is the call for consensus on the IESG fiat?

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

The very next post is your answer to this.

The 'declaration' of consensus appears in:

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

>I still don't think chair-hats have interesting opinions on technical issues,
>ever.

My comments to you are based on focusing the solutions and discussion 
to stay within the bounds of the problem to be solved.

>This could have been so much easier if the drive-by shooters had stopped to
>find out if their aim was in fact perfect.

Maybe so, but in this case the drivers-by eventually stopped, backed 
up, reloaded and shot repeatedly until the problem statement was 
clearly something the WG could address.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            [phone]
ARIN Research Engineer

"I'm sorry, sir, your flight is delayed for maintenance.  We are
pounding out the dents from the last landing."


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3HICgRN019820 for <[e-mail]>; Thu, 17 Apr 2003 20:12:42 +0200 (MEST)
Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h3HICgge019819 for ietf-provreg-outgoing; Thu, 17 Apr 2003 20:12:42 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3HICfRN019814 for <[e-mail]>; Thu, 17 Apr 2003 20:12:41 +0200 (MEST)
Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.9/8.12.9) with ESMTP id h3HI46Zj007707; Thu, 17 Apr 2003 14:04:06 -0400 (EDT)
Message-Id: <[e-mail]>
To: Edward Lewis <[e-mail]>
cc: Eric Brunner-Williams in Portland Maine <[e-mail]>, Ted Hardie <[e-mail]>, "'[e-mail]'" <[e-mail]>, [e-mail], [e-mail]
Subject: Re: [ietf-provreg] legal entity vs individual person 
In-Reply-To: Your message of "Thu, 17 Apr 2003 13:29:31 EDT." <a05111b08bac4926254d1@[192.149.252.108]> 
Date: Thu, 17 Apr 2003 14:04:06 -0400
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Ed,

At Pittsburg Fred said from the podium that his side of the table (the IESG)
did not have all the clue. Here we have assertion without justification for
novel functional requirements -- which is different from the prior IESG dicta
on manditory mechanisms, e.g., congestion control.

Now is it sensible?

Since London we seem to have been in agreement that some policy required a
mechanism to disclose some operational practice -- "data protection", and
"privacy" were the rationals.

This week, these rationals seem to be abandoned. There is no "protection"
no privacy, only a non-specific access mechanism.

Mind, this is only for the client-side mechanism.

Still, did Randy want the same technical specification for his personal
registration as Verisign has for its corporate registration? I don't know
that he did. Maybe that is all he ever wanted.

It concerns me, no it irks me, that IESG clowns blow in with personal opinions
and fob them off as professional opinions. Yes, we must make less-than-best
choices to actually have something multiply independently implemented, but it
does not strictly follow that we must do what Fred would not dare -- assert
that better knowledge is always on the IESG side of the table.

It is not sensible to assert the non-existance of "personal data". There is
a set of references that specify, partially, incoherently, but not negatively,
some semantic that attaches to datagram, circuit, postal, and other network
endpoints, as well as to names, when associated with individual persons.

Ed, where is the call for consensus on the IESG fiat?

I still don't think chair-hats have interesting opinions on technical issues,
ever.

This could have been so much easier if the drive-by shooters had stopped to
find out if their aim was in fact perfect.

Eric


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3HHTiRN019211 for <[e-mail]>; Thu, 17 Apr 2003 19:29:44 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h3HHTi1u019210 for ietf-provreg-outgoing; Thu, 17 Apr 2003 19:29:44 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from smtp2.arin.net (smtp2.arin.net [192.149.252.32]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3HHThRN019205 for <[e-mail]>; Thu, 17 Apr 2003 19:29:43 +0200 (MEST)
Received: by smtp2.arin.net (Postfix, from userid 5003) id 14C1D398; Thu, 17 Apr 2003 13:29:41 -0400 (EDT)
Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id 93D9443D; Thu, 17 Apr 2003 13:29:40 -0400 (EDT)
Received: from [192.136.136.64] (HELO [192.149.252.108]) by arin.net (CommuniGate Pro SMTP 4.0.6) with ESMTP id 188842; Thu, 17 Apr 2003 13:20:02 -0400
Mime-Version: 1.0
X-Sender: edlewis@mta
Message-Id: <a05111b08bac4926254d1@[192.149.252.108]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Thu, 17 Apr 2003 13:29:31 -0400
To: Eric Brunner-Williams in Portland Maine <[e-mail]>
From: Edward Lewis <[e-mail]>
Subject: Re: [ietf-provreg] legal entity vs individual person
Cc: Edward Lewis <[e-mail]>, Eric Brunner-Williams in Portland Maine <[e-mail]>, Ted Hardie <[e-mail]>, "'[e-mail]'" <[e-mail]>, [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Status: No, hits=-2.8 required=5.0 tests=AWL,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_SPARSE,SPAM_PHRASE_02_03 version=2.43-arin1
X-Spam-Level: 
Sender: [e-mail]
Precedence: bulk

Yes, certainly in some cases.

I don't want to go out on a limb and state guidelines for the IETF in 
this regard, but I will address my comments and why I stated them as 
the chair here.

When a discussion on a topic threatens to derail the process of 
defining a protocol from meeting the stated objectives, I think it is 
time to step in.  In our case, we have RFC 3375 plus a statement that 
you have labelled 'IESG fiat.'  Regarding the latter, the WG has 
adopted (a consensus) that the statement, with refinements, is a 
requirement in a recent thread.  Therefore, the 'fiat' has become a 
requirement too, albeit not included in RFC 3375.  (I suspect that 
there won't be an effort to update 3375 just for that.)

Also, it should be noted that my statements are directed at focusing 
the effort to achieve just the depth we need and not more.  I did not 
make any feature requests or edits to the requirements.

At 11:54 -0400 4/17/03, Eric Brunner-Williams in Portland Maine wrote:
>>  As a co-chair, my thought is that the protocol should not ...
>
>is this a sentence anyone should complete?

Perhaps a more precise wording is "the discussion over the protocol" 
and not "the protocol"
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            [phone]
ARIN Research Engineer

"I'm sorry, sir, your flight is delayed for maintenance.  We are
pounding out the dents from the last landing."


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3HG2lRN018319 for <[e-mail]>; Thu, 17 Apr 2003 18:02:47 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h3HG2ltU018318 for ietf-provreg-outgoing; Thu, 17 Apr 2003 18:02:47 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3HG2jRN018313 for <[e-mail]>; Thu, 17 Apr 2003 18:02:46 +0200 (MEST)
Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.9/8.12.9) with ESMTP id h3HFsAZj007270; Thu, 17 Apr 2003 11:54:10 -0400 (EDT)
Message-Id: <[e-mail]>
To: Edward Lewis <[e-mail]>
cc: Eric Brunner-Williams in Portland Maine <[e-mail]>, Ted Hardie <[e-mail]>, "'[e-mail]'" <[e-mail]>, [e-mail], [e-mail]
Subject: Re: [ietf-provreg] legal entity vs individual person 
In-Reply-To: Your message of "Thu, 17 Apr 2003 10:04:25 EDT." <a05111b03bac46167da02@[192.149.252.108]> 
Date: Thu, 17 Apr 2003 11:54:10 -0400
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

> As a co-chair, my thought is that the protocol should not ...

is this a sentence anyone should complete?

eric


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3HE9vRN017034 for <[e-mail]>; Thu, 17 Apr 2003 16:09:57 +0200 (MEST)
Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h3HE9ujx017033 for ietf-provreg-outgoing; Thu, 17 Apr 2003 16:09:56 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from smtp2.arin.net (smtp2.arin.net [192.149.252.32]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3HE9sRN017028 for <[e-mail]>; Thu, 17 Apr 2003 16:09:55 +0200 (MEST)
Received: by smtp2.arin.net (Postfix, from userid 5003) id BDE3B366; Thu, 17 Apr 2003 10:09:50 -0400 (EDT)
Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id 4CDA7343; Thu, 17 Apr 2003 10:09:50 -0400 (EDT)
Received: from [192.136.136.64] (HELO [192.149.252.108]) by arin.net (CommuniGate Pro SMTP 4.0.6) with ESMTP id 188061; Thu, 17 Apr 2003 10:00:12 -0400
Mime-Version: 1.0
X-Sender: edlewis@mta
Message-Id: <a05111b03bac46167da02@[192.149.252.108]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Thu, 17 Apr 2003 10:04:25 -0400
To: Eric Brunner-Williams in Portland Maine <[e-mail]>
From: Edward Lewis <[e-mail]>
Subject: Re: [ietf-provreg] legal entity vs individual person
Cc: Ted Hardie <[e-mail]>, "'[e-mail]'" <[e-mail]>, [e-mail], Edward Lewis <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,IN_REP_TO,REFERENCES,SIGNATURE_SHORT_SPARSE, SPAM_PHRASE_00_01 version=2.43-arin1
X-Spam-Level: 
Sender: [e-mail]
Precedence: bulk

As a co-chair, my thought is that the protocol should not be making a 
distinction between individuals and organizations.  I don't have any 
novel reasons (with respect to what's been expressed on the list). 
The strongest reason to me is that such a distinction (e.g., is the 
postal address that of a one-person consultant firm or of that 
person) is a policy issue.

I.e., for the WG, and just to simplify, "individual == corporation" 
here.  I can't see why the protocol ought to worry over the 
distinction.  We're talking the communication of the data here, not 
the policy over the data.

I applaud EBW's attempts to enlighten us all on privacy, however, it 
seems that it's getting to be more like teaching pigs to sing, and I 
for one would rather oink and wallow in that mud pile over here by 
now.  Yes, I'm being sarcastic, but seriously folks, I think the time 
has come to define what we have, document it, and see what the real 
world (that one with lawyers, contracts, and farmers) think.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            [phone]
ARIN Research Engineer

"I'm sorry, sir, your flight is delayed for maintenance.  We are
pounding out the dents from the last landing."


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3H1VgRN011668 for <[e-mail]>; Thu, 17 Apr 2003 03:31:42 +0200 (MEST)
Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h3H1VgEP011667 for ietf-provreg-outgoing; Thu, 17 Apr 2003 03:31:42 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3H1VdRN011662 for <[e-mail]>; Thu, 17 Apr 2003 03:31:40 +0200 (MEST)
Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.9/8.12.9) with ESMTP id h3H1OTZj004428; Wed, 16 Apr 2003 21:24:29 -0400 (EDT)
Message-Id: <[e-mail]>
To: Ted Hardie <[e-mail]>
cc: Eric Brunner-Williams in Portland Maine <[e-mail]>, "'[e-mail]'" <[e-mail]>, [e-mail]
Subject: Re: [ietf-provreg] legal entity vs individual person 
In-Reply-To: Your message of "Wed, 16 Apr 2003 17:08:34 PDT." <[e-mail]> 
Date: Wed, 16 Apr 2003 21:24:29 -0400
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

> ... information of the same class ...

And that is the error. We stopped work on defining "social" data when we
stopped progressing Ross' draft. If we were still progressing it, I'd be
attempting to make it clear that data that identifies individual persons
has a distinct requirement associated with it, for some of the eventual
EPP universe, than data that identifies things that aren't individual persons,
which is the point of this discussion.

To claim there is a single, undifferentiated "social" class of data is as
uncareful as insisting that somewhere in 1034/35 et seq you are guaranteed
a bind master file format.

> Again, I didn't say that the same information was associated with each
> of the three. 

The data can be "the same" (modulo one tends to identify an individual and
one doesn't), but it (addresses, phone numbers) means different things, on
just that "modulo" difference.

> I think that quote elides a critical verb:

Which? "To expect that" or "such as Do not distribute"?

> Do you mean that the mechanism Scott has proposed contains no mechanism
> for distinguishing among different types of data along some axis

There is no need to distinguish, if dnd applies only to individuals, and
not to non-individuals (dogs, rocks, sea shells, shell-corporations, etc.).

As soon as one adds commercial confidential, extends the dnd to entities
other than individuals, there is no need to try and find the individual,
or pretend that this was just "privacy", or in a non-FTC jurisdiction,
that there is "data protection". 

We started with a narrow "privacy" reqirement, and risk ending up with a  
commercial secrecy scheme instead of "privacy".

It is possible to have both a sensible individual "privacy", and a sensible
non-individual "secrecy", but not by asserting that the two are utterly
indistinguishable.



> Glad to have lifted the rock for you.

I don't know how we managed to get along without you. If you are serious
about on-line and off-line data correlation, and mechanisms to identify
data collection linkage, then you'll be interested in the P3P Spec WG's
archives. DoubleClick and someone else worked really, really hard to get
linkage onto cookies, in the Nov. '99 (or '00) face-to-face. We didn't
let them, but the outcome isn't as important as a good understanding of
the mechanisms and the operational practices that could have been adopted.

Eric


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3H08hRN010275 for <[e-mail]>; Thu, 17 Apr 2003 02:08:43 +0200 (MEST)
Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h3H08gVR010274 for ietf-provreg-outgoing; Thu, 17 Apr 2003 02:08:42 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3H08fRN010269 for <[e-mail]>; Thu, 17 Apr 2003 02:08:41 +0200 (MEST)
Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h3H08cJo010232; Wed, 16 Apr 2003 17:08:38 -0700 (PDT)
Received: from qualcomm.com (carbuncle.qualcomm.com [129.46.227.161]) by neophyte.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h3H08ajp007507; Wed, 16 Apr 2003 17:08:37 -0700 (PDT)
Date: Wed, 16 Apr 2003 17:08:34 -0700
Subject: Re: [ietf-provreg] legal entity vs individual person 
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v552)
Cc: "'[e-mail]'" <[e-mail]>
To: Eric Brunner-Williams in Portland Maine <[e-mail]>
From: Ted Hardie <[e-mail]>
In-Reply-To: <[e-mail]>
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.552)
Sender: [e-mail]
Precedence: bulk

On Wednesday, April 16, 2003, at 04:15 PM, Eric Brunner-Williams in 
Portland Maine wrote:
>
> Oh, you're clear enough.
>
> "Registrants include individuals, organizations, and corporations."
> A line from 3375, three buckets.
>
> "Social information associated with registrants may thus be associated
> with human, corporations, and organizations."
> A line from Hardie, same water in each bucket. This ignores the minor
> problem that we don't know what "social information" is. It originally
> ment anything that didn't get into a zone file -- billing data, ICANN
> cruft, garbage.

You misread me here.  I didn't say that the same information
is associated with each of the three; I said that information
of the same class (social information) may be. I think this
follows from the existing documents (both 3375, and, to
some extent, the charter).

> What this bald assertion misses is the possibility of the existance of
> properties of data that are not uniform across all three buckets.
> I think such an assertion is fundamentally unlearned.

Again, I didn't say that the same information was associated with each
of the three.  That the information is all of the same class also 
doesn't
say that its other properties are uniform.


> "... a mechanism (dnd) applies only to a single registrant type is to
> presume something about local policy."

I think that quote elides a critical verb:

>   To expect that
>  a mechanism (such as Do not distribute) applies only to a
> single registrant type is to presume something about local
> policy.



> A line from Hardie, no mechanism distinguishing non-uniformity of data
> is general.
> As I said, clear enough.

I'm afraid this is not clear to me.  Do you mean that the mechanism 
Scott has proposed contains
no mechanism for distinguishing among different types of data along some
axis?  Or that my statement did not describe the mechanism (true, but 
not surprising,
since it was about the expectation, not the mechanism)?  Or something 
else?

>> I thought it was moderately obvious; sorry.  The second order threat 
>> is
>> that
>> public data associated with an address could be correlated with other
>> public
>> data to re-create the data distribution problem.
>
> No. We missed "correlation with other public data" (on-line or 
> off-line)
> when drafting 3375.

Glad to have lifted the rock for you.
							regards,
									Ted Hardie



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3GNMDRN009926 for <[e-mail]>; Thu, 17 Apr 2003 01:22:13 +0200 (MEST)
Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h3GNMD9B009925 for ietf-provreg-outgoing; Thu, 17 Apr 2003 01:22:13 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3GNMBRN009920 for <[e-mail]>; Thu, 17 Apr 2003 01:22:12 +0200 (MEST)
Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.9/8.12.9) with ESMTP id h3GNF3Zj004058; Wed, 16 Apr 2003 19:15:03 -0400 (EDT)
Message-Id: <[e-mail]>
To: Ted Hardie <[e-mail]>
cc: Eric Brunner-Williams in Portland Maine <[e-mail]>, "'[e-mail]'" <[e-mail]>, [e-mail]
Subject: Re: [ietf-provreg] legal entity vs individual person 
In-Reply-To: Your message of "Wed, 16 Apr 2003 15:35:39 PDT." <[e-mail]> 
Date: Wed, 16 Apr 2003 19:15:03 -0400
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Oh, you're clear enough. 

"Registrants include individuals, organizations, and corporations."
A line from 3375, three buckets.

"Social information associated with registrants may thus be associated
with human, corporations, and organizations."
A line from Hardie, same water in each bucket. This ignores the minor
problem that we don't know what "social information" is. It originally
ment anything that didn't get into a zone file -- billing data, ICANN
cruft, garbage.

What this bald assertion misses is the possibility of the existance of
properties of data that are not uniform across all three buckets.

I think such an assertion is fundamentally unlearned.

"... a mechanism (dnd) applies only to a single registrant type is to
presume something about local policy."
A line from Hardie, no mechanism distinguishing non-uniformity of data
is general.

As I said, clear enough.

> I thought it was moderately obvious; sorry.  The second order threat is 
> that
> public data associated with an address could be correlated with other 
> public
> data to re-create the data distribution problem.

No. We missed "correlation with other public data" (on-line or off-line)
when drafting 3375. We missed sun spots, legal intercept, and avian
transport. We're not a fun lot.

In a day of exchanges I've found you have a firm opinion. I've no idea
how you arived at it. I know that after working on cookies, profile
transport, p3p-classic, p3p-on-cookies, p3p-beyond-the-wireline, IM,
and domains, in EU, OEDC, and the US, my initial data is not my current
data.

Eric


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3GMZmRN009651 for <[e-mail]>; Thu, 17 Apr 2003 00:35:48 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h3GMZmWI009650 for ietf-provreg-outgoing; Thu, 17 Apr 2003 00:35:48 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3GMZkRN009645 for <[e-mail]>; Thu, 17 Apr 2003 00:35:47 +0200 (MEST)
Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h3GMZi7t014657 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 16 Apr 2003 15:35:44 -0700 (PDT)
Received: from qualcomm.com (carbuncle.qualcomm.com [129.46.227.161]) by magus.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h3GMZehf023332; Wed, 16 Apr 2003 15:35:41 -0700 (PDT)
Date: Wed, 16 Apr 2003 15:35:39 -0700
Subject: Re: [ietf-provreg] legal entity vs individual person 
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v552)
Cc: "'[e-mail]'" <[e-mail]>
To: Eric Brunner-Williams in Portland Maine <[e-mail]>
From: Ted Hardie <[e-mail]>
In-Reply-To: <[e-mail]>
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.552)
Sender: [e-mail]
Precedence: bulk

On Wednesday, April 16, 2003, at 02:58 PM, Eric Brunner-Williams in 
Portland Maine wrote:
> We worked on the postal question. We considered the question of postal
> address conventions where there are little that is "conventional".

Very true.  In a little town near me, for example, the residents have
explicitly voted against home delivery because they did not
want to do away with what they saw as their addresses---really
names like "Heart's rest" etc.

As I said, however, the main point is this one:

>> main point is that how a legal entity and humans are treated for
>> purposes of data disclosure is a matter of local policy.
>
> Really?
>
> So there is no architectural principle present, something that arises
> in our requirements, hence in our choices of mechanisms, that causes
> us to attempt to distinguish between a person and a non-person.

Perhaps my terms didn't match 3375 sufficiently for my point to be
clear.  As it states, registrants may be humans, corporations, and
organizations.  Social information associated with registrants
(as per 3.4.3) may thus be associated with human, corporations,
and organizations.  There may be local policy which applies to
all registrants or which defines them by type.  To expect that
  a mechanism (such as Do not distribute) applies only to a
single registrant type is to presume something about local
policy.


> If, instead of personally identifying information, EPP provisioned a
> SRS with the GPS data for mountain tops, or the ranges for Spring Tides
> at select points on the coast of Maine, the "treat[ment] for purposes
> of data disclosure" would be indistinguishable from what we were close
> to agreement was necessary and sufficient.

If you find a registrar willing to treat a mountain top or spring tide
range as a registrant, I suggest you short their stock.


> I don't want to leave this stone unturned, so here it is again.
>
>> Assumes an infrastructure not uniformly present, and assumes that
>> use of that infrastructure does not carry second order threats.
>
> We've already done postal. It is in the archives.
>
> So there is your "second order threats". What are they?
>

I thought it was moderately obvious; sorry.  The second order threat is 
that
public data associated with an address could be correlated with other 
public
data to re-create the data distribution problem.



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3GM5kRN009444 for <[e-mail]>; Thu, 17 Apr 2003 00:05:46 +0200 (MEST)
Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h3GM5kHu009441 for ietf-provreg-outgoing; Thu, 17 Apr 2003 00:05:46 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3GM5iRN009433 for <[e-mail]>; Thu, 17 Apr 2003 00:05:44 +0200 (MEST)
Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.9/8.12.9) with ESMTP id h3GLwaZj003843; Wed, 16 Apr 2003 17:58:36 -0400 (EDT)
Message-Id: <[e-mail]>
To: Ted Hardie <[e-mail]>
cc: Eric Brunner-Williams in Portland Maine <[e-mail]>, "'[e-mail]'" <[e-mail]>, [e-mail]
Subject: Re: [ietf-provreg] legal entity vs individual person 
In-Reply-To: Your message of "Wed, 16 Apr 2003 14:36:36 PDT." <[e-mail]> 
Date: Wed, 16 Apr 2003 17:58:36 -0400
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

> Taking them together:  there is no street address equivalent to a roll 
> mailbox
> commonly available, and the "use a pobox" answer is not available 
> everywhere
> as a substitute for street addresses.

We worked on the postal question. We considered the question of postal
address conventions where there are little that is "conventional".

> main point is that how a legal entity and humans are treated for
> purposes of data disclosure is a matter of local policy.

Really?

So there is no architectural principle present, something that arises
in our requirements, hence in our choices of mechanisms, that causes
us to attempt to distinguish between a person and a non-person.

If, instead of personally identifying information, EPP provisioned a
SRS with the GPS data for mountain tops, or the ranges for Spring Tides
at select points on the coast of Maine, the "treat[ment] for purposes
of data disclosure" would be indistinguishable from what we were close
to agreement was necessary and sufficient.

I don't want to leave this stone unturned, so here it is again.

> Assumes an infrastructure not uniformly present, and assumes that
> use of that infrastructure does not carry second order threats.

We've already done postal. It is in the archives.

So there is your "second order threats". What are they?

Eric


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3GLamRN009247 for <[e-mail]>; Wed, 16 Apr 2003 23:36:48 +0200 (MEST)
Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h3GLamT4009246 for ietf-provreg-outgoing; Wed, 16 Apr 2003 23:36:48 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3GLakRN009240 for <[e-mail]>; Wed, 16 Apr 2003 23:36:47 +0200 (MEST)
Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h3GLae7t011335 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 16 Apr 2003 14:36:40 -0700 (PDT)
Received: from qualcomm.com (carbuncle.qualcomm.com [129.46.227.161]) by magus.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h3GLabhf013160; Wed, 16 Apr 2003 14:36:38 -0700 (PDT)
Date: Wed, 16 Apr 2003 14:36:36 -0700
Subject: Re: [ietf-provreg] legal entity vs individual person 
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v552)
Cc: "'[e-mail]'" <[e-mail]>
To: Eric Brunner-Williams in Portland Maine <[e-mail]>
From: Ted Hardie <[e-mail]>
In-Reply-To: <[e-mail]>
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.552)
Sender: [e-mail]
Precedence: bulk

On Wednesday, April 16, 2003, at 12:14 PM, Eric Brunner-Williams in 
Portland Maine wrote:

>> the same thing as there some forms of contact for which
>> roles are not available.
>
> Please be specific.
>> Assumes an infrastructure not uniformly present, and assumes that
>> use of that infrastructure does not carry second order threats.
>
> Could you explain this please.


Taking them together:  there is no street address equivalent to a roll 
mailbox
commonly available, and the "use a pobox" answer is not available 
everywhere
as a substitute for street addresses.

I'm sure that we could dig down into various examples for some time, 
but the
main point is that how a legal entity and humans are treated for
purposes of data disclosure is a matter of local policy.



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3GJL9RN007934 for <[e-mail]>; Wed, 16 Apr 2003 21:21:09 +0200 (MEST)
Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h3GJL9Fu007933 for ietf-provreg-outgoing; Wed, 16 Apr 2003 21:21:09 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3GJL7RN007928 for <[e-mail]>; Wed, 16 Apr 2003 21:21:08 +0200 (MEST)
Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.9/8.12.9) with ESMTP id h3GJE1Zj003356; Wed, 16 Apr 2003 15:14:01 -0400 (EDT)
Message-Id: <[e-mail]>
To: Ted Hardie <[e-mail]>
cc: Eric Brunner-Williams in Portland Maine <[e-mail]>, "'[e-mail]'" <[e-mail]>, [e-mail]
Subject: Re: [ietf-provreg] legal entity vs individual person 
In-Reply-To: Your message of "Wed, 16 Apr 2003 11:20:40 PDT." <[e-mail]> 
Date: Wed, 16 Apr 2003 15:14:01 -0400
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

> the same thing as there some forms of contact for which
> roles are not available.

Please be specific.

> Assumes an infrastructure not uniformly present, and assumes that
> use of that infrastructure does not carry second order threats.

Could you explain this please.

Eric


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3GILSRN007294 for <[e-mail]>; Wed, 16 Apr 2003 20:21:28 +0200 (MEST)
Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h3GILSUO007293 for ietf-provreg-outgoing; Wed, 16 Apr 2003 20:21:28 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3GILRRN007288 for <[e-mail]>; Wed, 16 Apr 2003 20:21:27 +0200 (MEST)
Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h3GIKr7t000464 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 16 Apr 2003 11:20:59 -0700 (PDT)
Received: from qualcomm.com (carbuncle.qualcomm.com [129.46.227.161]) by crowley.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h3GIKciF010761; Wed, 16 Apr 2003 11:20:47 -0700 (PDT)
Date: Wed, 16 Apr 2003 11:20:40 -0700
Subject: Re: [ietf-provreg] legal entity vs individual person 
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v552)
Cc: "'[e-mail]'" <[e-mail]>
To: Eric Brunner-Williams in Portland Maine <[e-mail]>
From: Ted Hardie <[e-mail]>
In-Reply-To: <[e-mail]>
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.552)
Sender: [e-mail]
Precedence: bulk

On Wednesday, April 16, 2003, at 10:37 AM, Eric Brunner-Williams in 
Portland Maine wrote:

>> One of the cases mentioned has been data for organizations
>> which implicitly identifies data about individual persons.  One of the
>
> solved by roles. [e-mail]
>
>> common cases would be the single-individual consulting shop;
>> in that case you might argue that revealing this information is
>> a cost of doing business as a legal entity rather than as an
>> individual.  The
>
> solved by roles. [e-mail]

Role contact information is a useful tool, but it does not achieve
the same thing as there some forms of contact for which
roles are not available.


>> hot-button cases, though, are those where revealing the information
>> has consequences for a third party.  The shelter example is the
>> one most commonly cited, where the decision to reveal information
>> about the shelter's business address or telephone number affects
>> those who seek its services.
>
> solved by pobox and hotline. see 
> http://www.cumberlandcounty.org/DAvr.html.

Assumes an infrastructure not uniformly present, and assumes that
use of that infrastructure does not carry second order threats.

>> Figuring out whether or not to support specific cases seems to me
>> a policy decision.   Having the hook for the different policies
>> seems reasonable enough; whether you cast it as "Privacy 
>> Considerations"
>> or "Client Data Control Considerations" doesn't really matter to me.
>
> I'm aware of that.
>
> Eric
>

						regards,
							Ted Hardie



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3GHiGRN006826 for <[e-mail]>; Wed, 16 Apr 2003 19:44:16 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h3GHiGbf006825 for ietf-provreg-outgoing; Wed, 16 Apr 2003 19:44:16 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3GHiFRN006820 for <[e-mail]>; Wed, 16 Apr 2003 19:44:15 +0200 (MEST)
Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.9/8.12.9) with ESMTP id h3GHb9Zj003014; Wed, 16 Apr 2003 13:37:09 -0400 (EDT)
Message-Id: <[e-mail]>
To: Ted Hardie <[e-mail]>
cc: Eric Brunner-Williams in Portland Maine <[e-mail]>, "'[e-mail]'" <[e-mail]>, [e-mail]
Subject: Re: [ietf-provreg] legal entity vs individual person 
In-Reply-To: Your message of "Wed, 16 Apr 2003 10:29:12 PDT." <[e-mail]> 
Date: Wed, 16 Apr 2003 13:37:09 -0400
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

> One of the cases mentioned has been data for organizations
> which implicitly identifies data about individual persons.  One of the

solved by roles. [e-mail]

> common cases would be the single-individual consulting shop;
> in that case you might argue that revealing this information is
> a cost of doing business as a legal entity rather than as an 
> individual.  The

solved by roles. [e-mail]

> hot-button cases, though, are those where revealing the information
> has consequences for a third party.  The shelter example is the
> one most commonly cited, where the decision to reveal information
> about the shelter's business address or telephone number affects
> those who seek its services.

solved by pobox and hotline. see http://www.cumberlandcounty.org/DAvr.html.

> Figuring out whether or not to support specific cases seems to me
> a policy decision.   Having the hook for the different policies
> seems reasonable enough; whether you cast it as "Privacy Considerations"
> or "Client Data Control Considerations" doesn't really matter to me.

I'm aware of that.

Eric


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3GHTMRN006609 for <[e-mail]>; Wed, 16 Apr 2003 19:29:22 +0200 (MEST)
Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h3GHTMO3006608 for ietf-provreg-outgoing; Wed, 16 Apr 2003 19:29:22 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3GHTKRN006603 for <[e-mail]>; Wed, 16 Apr 2003 19:29:20 +0200 (MEST)
Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h3GHTDJo018247; Wed, 16 Apr 2003 10:29:13 -0700 (PDT)
Received: from qualcomm.com (carbuncle.qualcomm.com [129.46.227.161]) by sabrina.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h3GHTANl029241; Wed, 16 Apr 2003 10:29:11 -0700 (PDT)
Date: Wed, 16 Apr 2003 10:29:12 -0700
Subject: Re: [ietf-provreg] legal entity vs individual person
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v552)
Cc: "'[e-mail]'" <[e-mail]>
To: Eric Brunner-Williams in Portland Maine <[e-mail]>
From: Ted Hardie <[e-mail]>
In-Reply-To: <[e-mail]>
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.552)
Sender: [e-mail]
Precedence: bulk

On Wednesday, April 16, 2003, at 06:39 AM, Eric Brunner-Williams in 
Portland Maine wrote:
<way big snip>
> I don't want this:
>
> X. Privacy Considerations
>
>    None.
>
> Y. Client Data Control Considerations
>
>    Redistribution of registrant contact data may be controlled by the
>    <mumble> element.
>
> I want this:
>
> X. Privacy Considerations
>
>    Data that may identify individual persons is identified and 
> policied.
>    See <mumble>.
>
> Eric

One of the cases mentioned has been data for organizations
which implicitly identifies data about individual persons.  One of the
common cases would be the single-individual consulting shop;
in that case you might argue that revealing this information is
a cost of doing business as a legal entity rather than as an 
individual.  The
hot-button cases, though, are those where revealing the information
has consequences for a third party.  The shelter example is the
one most commonly cited, where the decision to reveal information
about the shelter's business address or telephone number affects
those who seek its services.

Figuring out whether or not to support specific cases seems to me
a policy decision.   Having the hook for the different policies
seems reasonable enough; whether you cast it as "Privacy Considerations"
or "Client Data Control Considerations" doesn't really matter to me.

				regards,
					Ted Hardie



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3GDkfRN003883 for <[e-mail]>; Wed, 16 Apr 2003 15:46:41 +0200 (MEST)
Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h3GDkfYM003882 for ietf-provreg-outgoing; Wed, 16 Apr 2003 15:46:41 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3GDkdRN003877 for <[e-mail]>; Wed, 16 Apr 2003 15:46:39 +0200 (MEST)
Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.9/8.12.9) with ESMTP id h3GDdaZj002266 for <[e-mail]>; Wed, 16 Apr 2003 09:39:36 -0400 (EDT)
Message-Id: <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: [ietf-provreg] legal entity vs individual person
Date: Wed, 16 Apr 2003 09:39:36 -0400
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Off-list yesterday evening a provreg contributor wrote me the following:

>>	... is the distinction between entity and individual actually
>>	important?

I replied (also off-list):

> It is distinguishing the requirement. 95/46/ec has data protection arising
> out of a theory of human rights contained in the Treaty of Europe. In the
> US, the FTC has privacy arising out of a theory of private contract. From
> that, you know that ICANN contract is supreme in the US, and it isn't in
> Europe -- however, 95/46/ec applies only to people, not legal fictions.
> 
> If you say "privacy" in a 95/46/ec jurisdiction, as a North American, they
> will understand you to be trying to say 95/46/ec, and data protection. If
> you then say "for corporations", they'll be confused.
> 
> No corporation in the EU can go to the local data schutz and moan about
> their human rights and data, they have to moan differently. A person on
> the other hand can have the LDS moving to enforce national implementation
> of 95/46/ec, and the Treaty of Europe, and the Dignity of Human Rights by
> a simple complaint against a data collector.

I didn't discuss the OECD set of jurisdictions, which are somewhere between
these two, both in theory and practice. Life is complicated enough.

We had (rreq, now 3375, 8.4)

	The protocol MUST provide services to identify data collection
	policies.

To this we add (IESG fiat)

	The protocol MUST provide client binary 3rd-party disclosure labels.

Since the IESG mechanism is specific -- client control of data publication,
and covertly, via 954, et seq., not via 1034/35, by the server, this is not
a design choice made in a policy vacuum. This is about data that tends to
identify an individual person.

I don't want this:

X. Privacy Considerations

   None.

Y. Client Data Control Considerations

   Redistribution of registrant contact data may be controlled by the
   <mumble> element.

I want this:

X. Privacy Considerations

   Data that may identify individual persons is identified and policied.
   See <mumble>.

Eric


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3GCeHRN003075 for <[e-mail]>; Wed, 16 Apr 2003 14:40:17 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h3GCeHEl003074 for ietf-provreg-outgoing; Wed, 16 Apr 2003 14:40:17 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from neteka.com (www.namesbeyond.com [216.220.34.103]) by nic.cafax.se (8.12.9/8.12.9) with SMTP id h3GCeFRN003069 for <[e-mail]>; Wed, 16 Apr 2003 14:40:15 +0200 (MEST)
Message-ID: <0f6a01c30415$418056a0$[e-mail]>
From: "Edmon Chung" <[e-mail]>
To: "Hollenbeck, Scott" <[e-mail]>, "'Eric Brunner-Williams in Portland Maine'" <[e-mail]>
Cc: <[e-mail]>
References: <5BEA6CDB196A4241B8BE129D309AA4AF10E69A@vsvapostal8>
Subject: Re: [ietf-provreg] Proposed Text for Contact Mapping Disclosure Elements 
Date: Wed, 16 Apr 2003 08:39:41 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk

----- Original Message -----
From: "Hollenbeck, Scott" <[e-mail]>
> > Putting org in is a mistake. People have "privacy", non-people don't.
>
> I tend to disagree for reasons others have mentioned.  Instead of trying
to
> guess at the elements that I thought would be useful, I thought it best to
> make the feature available and let operators and others decide if it's
> useful or not.

I agree entirely.

Edmon



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3GCWhRN002999 for <[e-mail]>; Wed, 16 Apr 2003 14:32:43 +0200 (MEST)
Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h3GCWhe4002998 for ietf-provreg-outgoing; Wed, 16 Apr 2003 14:32:43 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3GCWfRN002993 for <[e-mail]>; Wed, 16 Apr 2003 14:32:42 +0200 (MEST)
Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.9/8.12.9) with ESMTP id h3GCPcZj001999; Wed, 16 Apr 2003 08:25:38 -0400 (EDT)
Message-Id: <[e-mail]>
To: "Hollenbeck, Scott" <[e-mail]>
cc: "'Eric Brunner-Williams in Portland Maine'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, [e-mail]
Subject: Re: [ietf-provreg] Proposed Text for Contact Mapping Disclosure E lements 
In-Reply-To: Your message of "Wed, 16 Apr 2003 07:14:27 EDT." <5BEA6CDB196A4241B8BE129D309AA4AF10E69A@vsvapostal8> 
Date: Wed, 16 Apr 2003 08:25:38 -0400
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

2308 is good. The example we have there is sensible. Please consider adding
an additional example covering this case.

> make the feature available and let operators [...] decide

Sounds extentional. I can see some operators putting "business privacy" on
the same level as "human privacy", and some not.

Eric


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3GBEURN002439 for <[e-mail]>; Wed, 16 Apr 2003 13:14:30 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h3GBEUsK002438 for ietf-provreg-outgoing; Wed, 16 Apr 2003 13:14:30 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.237.102]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3GBETRN002433 for <[e-mail]>; Wed, 16 Apr 2003 13:14:29 +0200 (MEST)
Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [10.170.12.38]) by heron.verisign.com (8.12.9/8.12.9) with ESMTP id h3GBFoaj029497; Wed, 16 Apr 2003 07:15:50 -0400 (EDT)
Received: by vsvapostalgw1.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <2SB7YPJG>; Wed, 16 Apr 2003 07:14:28 -0400
Message-ID: <5BEA6CDB196A4241B8BE129D309AA4AF10E69A@vsvapostal8>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Eric Brunner-Williams in Portland Maine'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: [ietf-provreg] Proposed Text for Contact Mapping Disclosure E lements 
Date: Wed, 16 Apr 2003 07:14:27 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

> > A server operator MAY reject
> > any transaction that requests disclosure practices ...
> 
> There is no in-band indicator of error. Why not?

There is -- a 2308 error response would be appropriate.

> "MUST reject" rather than "MAY reject", since "MAY reject" 
> will be translated
> into business English as "MAY silently modify requests."

I'm open to this if others agree.  Silent modification isn't a good
practice.

> > ... that do not conform to
> > the announced data collection policy.
> 
> What if there is no <dcp> (if <dcp> goes back to OPTIONAL)?

I'm not planning to make DCP optional again as part of this next round of
edits.  That's why the text notes it as a core requirement.

> Putting org in is a mistake. People have "privacy", non-people don't.

I tend to disagree for reasons others have mentioned.  Instead of trying to
guess at the elements that I thought would be useful, I thought it best to
make the feature available and let operators and others decide if it's
useful or not.

-Scott-


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3G0hiRN026674 for <[e-mail]>; Wed, 16 Apr 2003 02:43:44 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h3G0hixt026673 for ietf-provreg-outgoing; Wed, 16 Apr 2003 02:43:44 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3G0hgRN026668 for <[e-mail]>; Wed, 16 Apr 2003 02:43:43 +0200 (MEST)
Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.9/8.12.9) with ESMTP id h3G0alZj099638; Tue, 15 Apr 2003 20:36:47 -0400 (EDT)
Message-Id: <[e-mail]>
To: "Ross Wm. Rader" <[e-mail]>
cc: "Eric Brunner-Williams in Portland Maine" <[e-mail]>, [e-mail], [e-mail]
Subject: Re: [ietf-provreg] Proposed Text for Contact Mapping Disclosure Elements 
In-Reply-To: Your message of "Tue, 15 Apr 2003 20:15:36 EDT." <006701c303ad$4de90c10$6402a8c0@XP1> 
Date: Tue, 15 Apr 2003 20:36:47 -0400
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

> > I don't mind a mechanism existing for "secrecy", but I do mind calling it
> > "privacy".
> <snip>
> 
> I'd agree - "non-disclosure" sounds more appropriate.

non-disclosure by a legal entity (not an individual person).


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3G0FdRN026476 for <[e-mail]>; Wed, 16 Apr 2003 02:15:39 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h3G0FcDQ026475 for ietf-provreg-outgoing; Wed, 16 Apr 2003 02:15:38 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from tomts5-srv.bellnexxia.net (tomts5.bellnexxia.net [209.226.175.25]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3G0FbRN026470 for <[e-mail]>; Wed, 16 Apr 2003 02:15:37 +0200 (MEST)
Received: from XP1 ([64.229.99.197]) by tomts5-srv.bellnexxia.net (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with SMTP id <20030416001536.BAOE25164.tomts5-srv.bellnexxia.net@XP1>; Tue, 15 Apr 2003 20:15:36 -0400
Message-ID: <006701c303ad$4de90c10$6402a8c0@XP1>
From: "Ross Wm. Rader" <[e-mail]>
To: "Eric Brunner-Williams in Portland Maine" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: [ietf-provreg] Proposed Text for Contact Mapping Disclosure Elements 
Date: Tue, 15 Apr 2003 20:15:36 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk

> I don't mind a mechanism existing for "secrecy", but I do mind calling it
> "privacy".
<snip>

I'd agree - "non-disclosure" sounds more appropriate.


                     -rwr




Got Blog? http://www.byte.org

"People demand freedom of speech as a compensation for the freedom of
thought which they seldom use."
 - Soren Kierkegaard



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3FNV4RN026150 for <[e-mail]>; Wed, 16 Apr 2003 01:31:04 +0200 (MEST)
Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h3FNV4FF026149 for ietf-provreg-outgoing; Wed, 16 Apr 2003 01:31:04 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from zak.ecotroph.net ([216.93.164.123]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3FNV2RN026144 for <[e-mail]>; Wed, 16 Apr 2003 01:31:03 +0200 (MEST)
Received: from ecotroph.net (h87.s239.netsol.com [::ffff:216.168.239.87]) (AUTH: LOGIN anewton) by zak.ecotroph.net with esmtp; Tue, 15 Apr 2003 19:31:01 -0400
Message-ID: <[e-mail]>
Date: Tue, 15 Apr 2003 19:47:24 -0400
From: Andrew Newton <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2) Gecko/20021202
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Ed Allen Smith <[e-mail]>
CC: [e-mail], [e-mail]
Subject: Re: [ietf-provreg] Proposed Text for Contact Mapping Disclosure Elements
References: <[e-mail]>	<0ee001c30397$8fc2d000$[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Ed Allen Smith wrote:
> 
> And? Corporate entities have significantly higher requirements for public
> identity information being available than do people; this is generally
> considered a requirement for their being considered legal entities in the
> first place.

In the non-people legal entity realm, there are even distinctions 
between what may be made private and what must be public.  A large 
multinational corporation must make much more information public than 
does a one-man consulting shop, but they are both non-people legal entities.

And while there may be few or no jurisdictions making distinctions 
between the "privacy" or "secrecy" requirements of various sized, 
various functioned organizations, it doesn't mean there cannot be or 
never will be any.

So I agree with Ross.  Whether info about an org is non-public is a 
policy issue.

-andy



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3FMxARN025859 for <[e-mail]>; Wed, 16 Apr 2003 00:59:10 +0200 (MEST)
Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h3FMxAf7025858 for ietf-provreg-outgoing; Wed, 16 Apr 2003 00:59:10 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3FMx6RN025853 for <[e-mail]>; Wed, 16 Apr 2003 00:59:09 +0200 (MEST)
Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.9/8.12.9) with ESMTP id h3FMqBZj099357; Tue, 15 Apr 2003 18:52:11 -0400 (EDT)
Message-Id: <[e-mail]>
To: [e-mail]
cc: [e-mail], [e-mail]
Subject: Re: [ietf-provreg] Proposed Text for Contact Mapping Disclosure Elements 
In-Reply-To: Your message of "Tue, 15 Apr 2003 18:12:27 EDT." <00e701c3039c$195358e0$f80b000a@rraderxp> 
Date: Tue, 15 Apr 2003 18:52:11 -0400
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

I don't mind a mechanism existing for "secrecy", but I do mind calling it
"privacy".

Four years ago, when I started work in this area, not all of it in PROVREG,
some was in the presence-related WGs, some in HTTP, some in the W3C's P3P
Spec WG, and some in CPEx, every knee-jerk half-wit in the IESG said before
a regular-sized sombrero could hit the floor (falling from head-height in
normal gravity and an intellectual vaccum) that "privacy" was part of
"security" (and that if the data was encrypted, why that solved everything).

In the last year I haven't heard that sound-bite, so for all the dreck this
is, there is some progress -- the issue isn't just evesdropping, it is the
use and more that the intended recipients put to the data they acquire.

So, if a mechanism to partition the read-access on a repository is desired,
and general, that part that meets the policy meta-requirement for "privacy"
(and data protection) can be packaged as "privacy" (and dcp). That part that
meets other policy reqiurements can be packaged as "other".

Eric


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3FMCTRN025470 for <[e-mail]>; Wed, 16 Apr 2003 00:12:29 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h3FMCSLx025469 for ietf-provreg-outgoing; Wed, 16 Apr 2003 00:12:28 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from fr1.webmaillogin.com (fr1.webmaillogin.com [216.40.35.65]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3FMCRRN025464 for <[e-mail]>; Wed, 16 Apr 2003 00:12:28 +0200 (MEST)
Received: from [10.0.11.248] (HELO rraderxp) by fr1.webmaillogin.com (CommuniGate Pro SMTP 4.0.5) with ESMTP id 1691777 for [e-mail]; Tue, 15 Apr 2003 18:12:27 -0400
Reply-To: <[e-mail]>
From: "Ross Wm. Rader" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: [ietf-provreg] Proposed Text for Contact Mapping Disclosure Elements 
Date: Tue, 15 Apr 2003 18:12:27 -0400
Organization: Tucows Inc.
Message-ID: <00e701c3039c$195358e0$f80b000a@rraderxp>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <0ee001c30397$8fc2d000$[e-mail]>
Sender: [e-mail]
Precedence: bulk

[cc: trimmed - sorry if anyone on the line isn't on the list...]

> > Putting org in is a mistake. People have "privacy", 
> non-people don't.

I'd have to agree with Edmon's disagreement, but for different reasons.
There are very specific and very reasonable instances in which orgs
might desire some level of privacy, but this is usually called
"secrecy". Instinct tells me that the question of whether or not it is
appropriate is something that's better sorted out by local policy. 

So I think I'd like to see it left in...gotta keep local policy busy.

                       -rwr




"There's a fine line between fishing and standing on the shore like an
idiot."
- Steven Wright

Get Blog... http://www.byte.org/



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3FM3oRN025369 for <[e-mail]>; Wed, 16 Apr 2003 00:03:50 +0200 (MEST)
Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h3FM3oe1025368 for ietf-provreg-outgoing; Wed, 16 Apr 2003 00:03:50 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from dogberry.rutgers.edu (dogberry.rutgers.edu [165.230.209.227]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3FM3nRN025363 for <[e-mail]>; Wed, 16 Apr 2003 00:03:49 +0200 (MEST)
Received: from cesario.rutgers.edu ([e-mail] [165.230.209.239]) by dogberry.rutgers.edu (8.12.8p1/8.12.8) with ESMTP id h3FM45Bs077126; Tue, 15 Apr 2003 18:04:05 -0400 (EDT)
Received: (from easmith@localhost) by cesario.rutgers.edu (8.12.8/8.12.8/Submit) id h3FM45EE918628; Tue, 15 Apr 2003 18:04:05 -0400 (EDT)
Message-Id: <[e-mail]>
From: Ed Allen Smith <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: Tue, 15 Apr 2003 18:04:04 -0400
To: [e-mail]
Cc: [e-mail]
Subject: Re: [ietf-provreg] Proposed Text for Contact Mapping Disclosure Elements 
In-Reply-To: <0ee001c30397$8fc2d000$[e-mail]>
References: <[e-mail]> <0ee001c30397$8fc2d000$[e-mail]>
X-Mailer: VM 7.07 under 21.4 (patch 9) "Informed Management" XEmacs Lucid
Sender: [e-mail]
Precedence: bulk

In message <0ee001c30397$8fc2d000$[e-mail]> (on 15 April 2003 17:39:56 -0400), [e-mail] (Edmon Chung) wrote:
>
>----- Original Message ----- 
>From: "Eric Brunner-Williams in Portland Maine" <[e-mail]>
>>
>> Putting org in is a mistake. People have "privacy", non-people don't.
>>
>
>I disagree.
>Both are legal entities. 

And? Corporate entities have significantly higher requirements for public
identity information being available than do people; this is generally
considered a requirement for their being considered legal entities in the
first place.

     -Allen

-- 
Allen Smith                       http://cesario.rutgers.edu/easmith/
February 1, 2003                               Space Shuttle Columbia
Ad Astra Per Aspera                     To The Stars Through Asperity


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3FLnvRN025169 for <[e-mail]>; Tue, 15 Apr 2003 23:49:57 +0200 (MEST)
Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h3FLnvC4025168 for ietf-provreg-outgoing; Tue, 15 Apr 2003 23:49:57 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3FLntRN025163 for <[e-mail]>; Tue, 15 Apr 2003 23:49:56 +0200 (MEST)
Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.9/8.12.9) with ESMTP id h3FLh1Zj099159; Tue, 15 Apr 2003 17:43:01 -0400 (EDT)
Message-Id: <[e-mail]>
To: "Edmon Chung" <[e-mail]>
cc: "Hollenbeck, Scott" <[e-mail]>, "Eric Brunner-Williams in Portland Maine" <[e-mail]>, [e-mail], [e-mail]
Subject: Re: [ietf-provreg] Proposed Text for Contact Mapping Disclosure Elements 
In-Reply-To: Your message of "Tue, 15 Apr 2003 17:39:56 EDT." <0ee001c30397$8fc2d000$[e-mail]> 
Date: Tue, 15 Apr 2003 17:43:01 -0400
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

> > Putting org in is a mistake. People have "privacy", non-people don't.
> >
> 
> I disagree.
> Both are legal entities. 

So is my dog. So is IBM. So is the United Nations. So is Antarctica.


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3FLeTRN025061 for <[e-mail]>; Tue, 15 Apr 2003 23:40:29 +0200 (MEST)
Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h3FLeTW1025060 for ietf-provreg-outgoing; Tue, 15 Apr 2003 23:40:29 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from neteka.com (www.namesbeyond.com [216.220.34.103]) by nic.cafax.se (8.12.9/8.12.9) with SMTP id h3FLeRRN025055 for <[e-mail]>; Tue, 15 Apr 2003 23:40:27 +0200 (MEST)
Message-ID: <0ee001c30397$8fc2d000$[e-mail]>
From: "Edmon Chung" <[e-mail]>
To: "Hollenbeck, Scott" <[e-mail]>, "Eric Brunner-Williams in Portland Maine" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: [ietf-provreg] Proposed Text for Contact Mapping Disclosure Elements 
Date: Tue, 15 Apr 2003 17:39:56 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk

----- Original Message ----- 
From: "Eric Brunner-Williams in Portland Maine" <[e-mail]>
>
> Putting org in is a mistake. People have "privacy", non-people don't.
>

I disagree.
Both are legal entities. 



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3FL7vRN024690 for <[e-mail]>; Tue, 15 Apr 2003 23:07:57 +0200 (MEST)
Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h3FL7vb3024689 for ietf-provreg-outgoing; Tue, 15 Apr 2003 23:07:57 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3FL7tRN024684 for <[e-mail]>; Tue, 15 Apr 2003 23:07:56 +0200 (MEST)
Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.9/8.12.9) with ESMTP id h3FL0xZj099054; Tue, 15 Apr 2003 17:00:59 -0400 (EDT)
Message-Id: <[e-mail]>
To: "Hollenbeck, Scott" <[e-mail]>
cc: "'[e-mail]'" <[e-mail]>, [e-mail]
Subject: Re: [ietf-provreg] Proposed Text for Contact Mapping Disclosure Elements 
In-Reply-To: Your message of "Tue, 15 Apr 2003 15:41:06 EDT." <5BEA6CDB196A4241B8BE129D309AA4AF10E698@vsvapostal8> 
Date: Tue, 15 Apr 2003 17:00:59 -0400
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Scott,

> A server operator MAY reject
> any transaction that requests disclosure practices ...

There is no in-band indicator of error. Why not?

"MUST reject" rather than "MAY reject", since "MAY reject" will be translated
into business English as "MAY silently modify requests."

> ... that do not conform to
> the announced data collection policy.

What if there is no <dcp> (if <dcp> goes back to OPTIONAL)?

Putting org in is a mistake. People have "privacy", non-people don't.


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3FJf9RN023664 for <[e-mail]>; Tue, 15 Apr 2003 21:41:09 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h3FJf9Mg023663 for ietf-provreg-outgoing; Tue, 15 Apr 2003 21:41:09 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.237.102]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3FJf7RN023658 for <[e-mail]>; Tue, 15 Apr 2003 21:41:08 +0200 (MEST)
Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [10.170.12.38]) by heron.verisign.com (8.12.9/8.12.9) with ESMTP id h3FJgSaj008810 for <[e-mail]>; Tue, 15 Apr 2003 15:42:29 -0400 (EDT)
Received: by vsvapostalgw1.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <2SB7X1DA>; Tue, 15 Apr 2003 15:41:06 -0400
Message-ID: <5BEA6CDB196A4241B8BE129D309AA4AF10E698@vsvapostal8>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: [ietf-provreg] Proposed Text for Contact Mapping Disclosure Elements
Date: Tue, 15 Apr 2003 15:41:06 -0400
Importance: high
X-Priority: 1
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

I'd like to propose adding the following text to section 2 of the contact
mapping document to move forward with the element privacy approach described
here:

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

I am assuming that we are past the point of discussing whether or not the
direction described in this new text is one we need to follow.  Specific
replacement text would be _most_ helpful if you see something that you don't
like.

"2.9 Disclosure of Data Elements and Attributes

The EPP core protocol requires a server operator to announce data collection
policies to clients; see section 2.4 of [EPP].  In conjunction with this
disclosure requirement, this mapping includes data elements that allow a
client to identify elements that require exceptional server operator
handling to allow or restrict disclosure to third parties.

A server operator announces a default disclosure policy when establishing a
session with a client.  When an object is created or updated, the client can
specify contact attributes that require exceptional disclosure handling
using an OPTIONAL <contact:disclose> element.  A server operator MAY reject
any transaction that requests disclosure practices that do not conform to
the announced data collection policy.  Once set, disclosure preferences can
be reviewed using a standard contact information query.

If present, the <contact:disclose> element MUST contain a "flag" attribute.
The "flag" attribute contains an XML Schema boolean value.  A value of
"true" or "1" (decimal one) notes a client preference to allow disclosure of
the specified elements as an exception to the stated data collection policy.
A value of "false" or "0" (decimal zero) notes a client preference to not
allow disclosure of the specified elements as an exception to the stated
data collection policy.

The <contact:disclose> element MUST contain at least one of the following
child elements:

<contact:name type="int">
<contact:name type="loc">
<contact:org type="int">
<contact:org type="loc">
<contact:addr type="int">
<contact:addr type="loc">
<contact:voice>
<contact:fax>
<contact:email>

Example <contact:disclose> element, flag="0":

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

In this example, the contact email address and voice telephone number should
not be disclosed.  All other elements are subject to disclosure in
accordance with the server's data collection policy.

Example <contact:disclose> element, flag="1":

<contact:disclose flag="1">
  <contact:name type="int">
  <contact:org type="int">
  <contact:addr type="int">
</contact:disclose>

In this example, the internationalized contact name, organization, and
address information can be disclosed.  All other elements are subject to
disclosure in accordance with the server's data collection policy."

Well, that's the proposed text, with appropriate changes required elsewhere
in the document to maintain consistency.  Fire away.

-Scott-


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3FFUwRN020742 for <[e-mail]>; Tue, 15 Apr 2003 17:30:58 +0200 (MEST)
Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h3FFUvDc020741 for ietf-provreg-outgoing; Tue, 15 Apr 2003 17:30:57 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.237.102]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3FFUuRN020736 for <[e-mail]>; Tue, 15 Apr 2003 17:30:56 +0200 (MEST)
Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [10.170.12.38]) by heron.verisign.com (8.12.9/8.12.9) with ESMTP id h3FFSaaj027793; Tue, 15 Apr 2003 11:28:36 -0400 (EDT)
Received: by vsvapostalgw1.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <2SB7W7M7>; Tue, 15 Apr 2003 11:27:14 -0400
Message-ID: <5BEA6CDB196A4241B8BE129D309AA4AF10E691@vsvapostal8>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Edward Lewis'" <[e-mail]>, [e-mail]
Subject: RE: [ietf-provreg] host attributes
Date: Tue, 15 Apr 2003 11:27:14 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

> The one change I request, in the name of remaining non-IPv4 specific 
> is to add to the example a IPv6 address example....

Sure, that's easy.

> The MX RR issue will be left to extensions for the time being. 
> Scott, could you add a paragraph to the document to summarize why 
> only address records appear as domain attributes.  My experience with 
> the DNS documents is that it is good to document the non-features too.

That's easy, too.

-Scott-


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3FEpxRN020164 for <[e-mail]>; Tue, 15 Apr 2003 16:51:59 +0200 (MEST)
Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h3FEpx0i020163 for ietf-provreg-outgoing; Tue, 15 Apr 2003 16:51:59 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from fr1.webmaillogin.com (fr1.webmaillogin.com [216.40.35.65]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3FEpvRN020158 for <[e-mail]>; Tue, 15 Apr 2003 16:51:58 +0200 (MEST)
Received: from [10.0.11.248] (HELO rraderxp) by fr1.webmaillogin.com (CommuniGate Pro SMTP 4.0.5) with ESMTP id 1682555; Tue, 15 Apr 2003 10:51:54 -0400
Reply-To: <[e-mail]>
From: "Ross Wm. Rader" <[e-mail]>
To: "'Eric Brunner-Williams in Portland Maine'" <[e-mail]>, "'Joseph Reagle'" <[e-mail]>
Cc: "'Hollenbeck, Scott'" <[e-mail]>, "'Edward Lewis'" <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: [ietf-provreg] [BH] P3P and Extensible Provisioning Protocol 
Date: Tue, 15 Apr 2003 10:51:54 -0400
Organization: Tucows Inc.
Message-ID: <005f01c3035e$8e493f40$f80b000a@rraderxp>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

> There is no in-band mechanism to distinguish 
> "registrar-generated-data" from 
> "entity-other-than-registrar-generated-data".
<snip>
> I don't even know if the registrar was the initial data 
> collector, or if the initial data collector was a reseller 
> and the registrar engaged in onward-transport. I don't know 
> how the data got to the registrar.

Perhaps this is overkill, but I can't underscore enough how "right" Eric
is with this observation - it is not uncommon that the chain looks like:

Registrant -> affiliate partner -> reseller -> reseller -> registrar ->
registry...

This is even more predominant in environments like .cn where every
non-domestic registrar is actually a reseller of Neulevel's.

The point that needs to be underscored is that, as Eric pointed out,
each link in the chain has the opportunity to add or change data to the
transaction as they see fit - and experience shows that it happens on a
regular basis.



                       -rwr




"There's a fine line between fishing and standing on the shore like an
idiot."
- Steven Wright

Get Blog... http://www.byte.org/



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3FEHNRN019729 for <[e-mail]>; Tue, 15 Apr 2003 16:17:23 +0200 (MEST)
Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h3FEHN8r019728 for ietf-provreg-outgoing; Tue, 15 Apr 2003 16:17:23 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3FEHLRN019723 for <[e-mail]>; Tue, 15 Apr 2003 16:17:22 +0200 (MEST)
Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.9/8.12.9) with ESMTP id h3FE98Zj097830; Tue, 15 Apr 2003 10:09:08 -0400 (EDT)
Message-Id: <[e-mail]>
To: Edward Lewis <[e-mail]>
cc: [e-mail], [e-mail], [e-mail]
Subject: Re: [ietf-provreg] provreg @ ietf56 
In-Reply-To: Your message of "Mon, 14 Apr 2003 14:00:08 EDT." <a05111b01bac0a65e7d94@[192.149.252.108]> 
Date: Tue, 15 Apr 2003 10:09:08 -0400
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

> Questions for all:
> 
>     What's wrong with "dnd"?  Do Not Disclose to anyone in anyway,
>     other than to sponsoring registrar.  "Existence of domain name?"

Several things:
	1. The existing specifications informational commands did not forsee
	   a non-uniform read access model,
	2. Limitations on recipient (aka "disclosure") do not extend to the
	   purpose, recall that registries and registrars routinely repurpose
	   registration for own-marketing (e.g., "buy all three" UCE that went
	   to CNO registrants two years ago), nor to retention, etc.
	3. SRS writer (registrar) acts independent of SRS store management
	   (registry) access policy obviate (remove the necessity, and even
	   the utility of) access mechanism(s).

>    What happens if the registry is legally coerced to disclose anyway?

Then the SRS store management (registry) acts independent of the SRS writer
(registrar) attempts to restrict the access model. Whether the "legal" comes
from an ICANN contract or a lawful seizure, is immaterial. The interesting
question, IMO, is where registry policy and practice absent lawful seizure
are not consistent. Without a <dcp>, this can't be discovered in-band.

Thanks for getting the meeting minutes out.

Eric


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3EMJpRN011104 for <[e-mail]>; Tue, 15 Apr 2003 00:19:51 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h3EMJp7j011103 for ietf-provreg-outgoing; Tue, 15 Apr 2003 00:19:51 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3EMJoRN011098 for <[e-mail]>; Tue, 15 Apr 2003 00:19:50 +0200 (MEST)
Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.9/8.12.9) with ESMTP id h3EMBrZj095014; Mon, 14 Apr 2003 18:11:53 -0400 (EDT)
Message-Id: <[e-mail]>
To: Joseph Reagle <[e-mail]>
cc: Eric Brunner-Williams in Portland Maine <[e-mail]>, "Hollenbeck, Scott" <[e-mail]>, Edward Lewis <[e-mail]>, [e-mail], [e-mail], [e-mail]
Subject: Re: [ietf-provreg] [BH] P3P and Extensible Provisioning Protocol 
In-Reply-To: Your message of "Mon, 14 Apr 2003 17:34:47 EDT." <[e-mail]> 
Date: Mon, 14 Apr 2003 18:11:53 -0400
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

> > > If the initial data collection had a particular policy (P3P)
> >
> > This may be a theory-of-foo bump, or it may be a slow moving armidillo,
> > but data originates at a registrar.
> > We (epp-hat==1) aren't designing the registrar's UI.
> 
> So is the information covered is not my data (my contact info I've placed 
> with the registrar) but the registrars information? I continue to fail to 
> understand exactly what information the practice applies to and governs. I 
> suspect a step-by-step scenario would be immensely useful.

We have some rules, things like delete-object-before-create-object returns
an error.

What we don't have rule about are where registrars go to get "data", they
could just be making it up.

There is no in-band mechanism to distinguish "registrar-generated-data"
from "entity-other-than-registrar-generated-data".

There is a data collection policy announcement from a data collector, which
is indifferent as to the originator of the data which it collects, and it is
possible that a registrar might use non-fictive data.

Did the registrar use P3P when collecting the data? I've no idea. I don't
even know if the registrar was the initial data collector, or if the initial
data collector was a reseller and the registrar engaged in onward-transport.
I don't know how the data got to the registrar.

What the <dcp> covers is _everything_ in a session. Since sessions exhaust,
for the time being, the semantics of state exchange between registrars and
registries, everything collected by a registry is policied. Note that any
registry may have a number other than one of applicable <dcp> statements,
with non-overlapping session-scope.

Eric


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3ELm6RN010800 for <[e-mail]>; Mon, 14 Apr 2003 23:48:06 +0200 (MEST)
Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h3ELm6ML010799 for ietf-provreg-outgoing; Mon, 14 Apr 2003 23:48:06 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3ELm4RN010794 for <[e-mail]>; Mon, 14 Apr 2003 23:48:04 +0200 (MEST)
Received: from localhost (IDENT:[e-mail] [18.29.0.27]) by tux.w3.org (8.12.9/8.12.9) with ESMTP id h3ELYmsi018102; Mon, 14 Apr 2003 17:34:49 -0400
From: Joseph Reagle <[e-mail]>
Organization: W3C
To: Eric Brunner-Williams in Portland Maine <[e-mail]>
Subject: Re: [ietf-provreg] [BH] P3P and Extensible Provisioning Protocol
Date: Mon, 14 Apr 2003 17:34:47 -0400
User-Agent: KMail/1.5.1
Cc: Eric Brunner-Williams in Portland Maine <[e-mail]>, "Hollenbeck, Scott" <[e-mail]>, Edward Lewis <[e-mail]>, [e-mail], [e-mail], [e-mail]
References: <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

On Friday 11 April 2003 06:20, Eric Brunner-Williams in Portland Maine 
wrote:
> > If the initial data collection had a particular policy (P3P)
>
> This may be a theory-of-foo bump, or it may be a slow moving armidillo,
> but data originates at a registrar.
> We (epp-hat==1) aren't designing the registrar's UI.

So is the information covered is not my data (my contact info I've placed 
with the registrar) but the registrars information? I continue to fail to 
understand exactly what information the practice applies to and governs. I 
suspect a step-by-step scenario would be immensely useful.




Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3EI2qRN008406 for <[e-mail]>; Mon, 14 Apr 2003 20:02:52 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h3EI2qRK008405 for ietf-provreg-outgoing; Mon, 14 Apr 2003 20:02:52 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from smtp2.arin.net (smtp2.arin.net [192.149.252.32]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3EI2oRN008400 for <[e-mail]>; Mon, 14 Apr 2003 20:02:50 +0200 (MEST)
Received: by smtp2.arin.net (Postfix, from userid 5003) id 53166426; Mon, 14 Apr 2003 14:02:47 -0400 (EDT)
Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id 52B81436; Mon, 14 Apr 2003 14:02:44 -0400 (EDT)
Received: from [192.136.136.46] (HELO [192.149.252.108]) by arin.net (CommuniGate Pro SMTP 4.0.6) with ESMTP id 184702; Mon, 14 Apr 2003 13:53:15 -0400
Mime-Version: 1.0
X-Sender: edlewis@mta
Message-Id: <a05111b01bac0a65e7d94@[192.149.252.108]>
Date: Mon, 14 Apr 2003 14:00:08 -0400
To: [e-mail]
From: Edward Lewis <[e-mail]>
Subject: [ietf-provreg] provreg @ ietf56
Cc: [e-mail], [e-mail], [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BALANCE_FOR_LONG_20K,SIGNATURE_SHORT_SPARSE, SPAM_PHRASE_01_02 version=2.43-arin1
X-Spam-Level: 
Sender: [e-mail]
Precedence: bulk

Overhead slides and jabber log for provreg meeting, IETF 56 in San Francisco,
California, US, March 2003.  (Note that these notes were not passed 
before the group before submission.  Apologies to speakers for 
misrecording of statements.)

Provisioning Registry Protocol (provreg)

0. Scribe: Kim Davies - thanks
    Jabber: Andrew Newton - thanks

1. Agenda Bashing - few minutes

2. State of the Group (where the docs are) - few minutes

3. Privacy "bull" session - until exhaustion

4. Extensions Document - few minutes

5. Host Objects - few minutes

6. Other obstacles to Proposed Standard - few minutes

Abstract: Group is struggling with one remaining issue.

When (if) we get resolution, only one document remains in the WG.

Proposed future - just solve this one problem, get to
Prop Std on base specs, and to Informational on remaining
document and shutdown this group.
(New group when needed to advance to Draft Std.)

Core Documents (proposed standard):
   Extensible Provisioning Protocol
   Extensible Provisioning Protocol Contact Mapping
   Extensible Provisioning Protocol Domain Name Mapping
   Extensible Provisioning Protocol Host Mapping
   Extensible Provisioning Protocol Transport Over TCP

Answers to IESG comments:
   http://www.cafax.se/ietf-provreg/maillist/2003-03/msg00067.html
   Comments?

Remaining Document (informational):
   Guidelines for Extending the Extensible Provisioning Protocol

Other documents:
   Individual submissions exist, not WG candidates now
   Nothing is stopping experimentation
   Why are docs being discouraged?  Track record is that no document
   has gathered general interest in some time.

Milestones (mail list, not on charter page):

MAR 03 Respond to the IESG Comments (for Proposed)
MAR 03 Submit Guidelines for Extending the EPP to IESG (Informational)
propose ---> APR 03
APR 03 Decision on Alternate Transports

Likely to drop these:
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)

Abstract: DISCUSS a compromise to the problem, PROPOSE this on the list.

Problem:

      We have a way for registry to tell registrar about privacy for a session

      We don't have a way for a registrar to tell registry about
      privacy concerns for pieces of data.

      IESG comment:
      > why do domain/contact/.. not have granular information about
      > privacy?

      So - we need to address domain and contact mapping (at least)

Questions to IESG:

      We don't have the privacy draft from Blaze, et.al., yet - will
      it hold up our documents?  I.e., should we be rushing if it will
      stall us anyway?

      Tough question: why engineer to legal requirements?  (Unlike way
      back when - IPsec.)  (This is a rat hole, but what's the justification?)

Questions for all:

      What's wrong with "dnd"?  Do Not Disclose to anyone in anyway,
      other than to sponsoring registrar.  "Existence of domain name?"

      What happens if the registry is legally coerced to disclose anyway?

no slides
Abstract: Murmurs in the hall: Folks not happy with host objects.

Complaint: EPP requires a series of actions by reg'r if reg'y does
not maintain hosts.

Proposal: alter Domain Mapping to let name servers be added instead
of reference.

Rebuttal: ?
Abstract: A few issues flare up

Discussion has not been sustained until closure

Fine, I can understand frustration w/slow process

But - now we are potentially to success - last time to speak

Jabber log of meeting...

Logs for [e-mail]
ed: agenda bashing
agenda 0 - Scribe Kim Davies Jabber Andrew Newton
agenda 1 - agenda basing - few minutes
agenda 2 - state of the group (where the docs are) - few minutes
agenda 3 - privacy "bull' session - until exhaustion
agenda 4 - extension document - few minutes
agenda 5 - host objects - few minutes
agenda 6 - other obstacles to proposed standard - few minutes
no objects to the agenda
ed: state of the group
ed: group has been stalled since Atlanta. One doc left in WG after this stall.
ed: discussing EPP documents
ed: proposed future - just solve this one problem, get to proposed std on
     base specs, and to informational on remaining docs and shutdown group
ed: IESG comments 
http:/www.cafax.se/ietf-provreg/maillist/2003-03/msg00067.html
ed: remaining doc is Extensions doc - to be informational
ed: other docs - individual submissions exist, not WG candidates now.  Nothing
     stops experimentation. Track record is that no doc has gathered interest.
ed: onto milestones
ed: mar 03 - respond to iesg - submit guidelines to extending epp
ed: apr 03 - decision on alternate transports
ed: likely to drop other milestones for going to draft standard
rick: it doesn't seem like we have no interest in doing extensions
ed: there doesn't seem interest in doing extensions
rick: there are no milestones for it. you are not allowing those questions
       to be asked
ed: yes, the track record so far as not been good
ed: why would the WG spend time discussing just one person's concerns?
     (In the sense that only one person cared.)
jaap: we have no seen drafts too
scott: my drafts are not of interest to this WG but to other WG's.
jaap: said something about extensions (i didn't get it)
rick: you can make us not talk about it
ed: not trying to squelch extensions, but nothing has come in for us to handle.
ed: we will have a better chance of doing our job with we have better focus
ed: we don't have a history of doing this
rick: only way an ext. gets documented is via individual submission?
ed: yes
andy: if it is info, can you just got to the rfc editor
ed: depends on whether iesg says it needs wg review
ed: we are not trying to stop experimentation, but we have not had a 
successful history of handling extensions.
jk: are you addressing i18n issues or are you assuming idna.
scott: what are the issues?
jk: is everything strictly idna and there are no i18n issues, or do 
you need to know character sets and other standard issues.
scott: we do the first case now.
scott: if it can be pointed out that the other cases need to be 
addressed, they would be candidates for an extension.
ed: time frame of two months

now on to privacy
ted: addressing privacy brought up by randy bush
ed: pulling up scott's message regarding issues with iesg
ted: the one remaining issue is the privacy issue raised by randy bush
scott: #8
ted: describing registry/registrar/registrant use case
ted: dcp tells the registrar from registry about privacy
ted: if registrant has privacy parameters, the registrar checks against
      the registry and rejects the registration
ted: in this model, the registrar is handling the intersection between
      the registrant and registry
ted: what randy has asked for is a case where the registry handles this.
ted: in this case, randy wants a mechanism where this is possible.
ted: mechanism allows registrar to give registrants parameters to registry
ted: randy wants it at the per element granularity on social data
ted: didn't need to imply the syntax, just semantics (attributes per element
      vs. blob)
ted: is that unclear
richard: everybody wants to do something likes this, but it is too
      complicated requiring rewrite of contracts between registries and
      registrars and ICANN.
richard: this is a protocol burden that may not be legally possible
ted: if their current agreement doesn't cover this, it does not need to
      be turned on.
ted: are you saying that just having this will cause something
ted: this is not a silly state item, you do one or the other.
richard: it is about implied contracts
ted: not dnp and other mechanism
ed: we are being asked to make the protocol general enough for this
randy: mandatory to implement, not to use
ricK: if this were used to today, it would violate our contracts with ICANN
randy: that is your contract problem
ricK: it should not be mandatory to use
richard: we are trying to do the right thing, but there are practical
          issues here.
richard: if a registry sends to a registrar these flags and the registry
          ignores that, it is a problem
randy: reject the data
jk: if ICANN changes the rules, you have to change the contracts.
jk: reject the registration if you don't agree with the flags.
jk: the important thing is that the protocol can be used when the policy
     changes
ed: this is the first time I've heard this argument clear enough to
     understand the issue
randy: it could be that the registrar/registry support a policy that the
     registrar doesn't offer.
jaap: some registrars may say they will not deal with opt-out policies
     because it is too much work.
ted: the critical thing is not to get into using both sets (mechanisms).
ted: either use dcp and not dnp
randy: there are many points in the protocol where if there is wrong
     data it gets thrown away.
rick: are they mutually exclusive
ted: is dcp mandatory if dnp is not used
randy: dcp is aggregated dnp
ted: you are ok with dcp not being mandatory in the presence of dnp
randy: no problem
ed: do not publish?
randy: blob vs attribute tag, doesn't matter
ed: per session?
ed: there are three levels of time interaction here.
rick: i do not like educated the AD's on these topics and then negotiating
       it in front of us
rick: i don't like doing this... the implementors and group members should
       have a say
rick: i would like dnp per object not per session
randy: i don't care
ed: how does this apply to social data or technical data... host mapping,
     domain mapping
rick: privacy is about social information
ed: just getting clarification
richard: yes, social info or person id info and nothing else
randy: or organizational
richard: same thing
richard: what is not clear about personal id info
randy: because it says "person"... need to include "org"
scott: paf says we can't narrow it down to contact info because that
        is a policy decision
randy: i don't find that interesting
randy: is there a gray area
scott: not that we can see
rick: this about ted's comments about silly states
rick: having dnp on hosts should generate errors
unknown: what level is the purpose for
rick: there is no purpose
randy: don't go there
randy: just a bit, how it applies to whois or whatever is about culture
        and contact
george: implement the feature and pursue the social policy issue later
richard: if the feature is implemented, whether it is used implies behavior
          in contracts
richard: this is a legal rat hole
jaap: law is not enforced by protocol
ed: are we trying to engineer  to legal requirements
randy: no
richard: disagrees
ed: we have been designing protocols for years without legal guidelines
ed: have process question
ed: we don't have the smarts to design the protocol with legal knowledge
richard: disagrees. we need to understand the protocol implications
          on the legality of the contracts
richard: lawyers will sue
ed: we don't know enough about the law in this room
rick: i agree with richard, but let's talk about the technical issue
rick: i like these bits/flags. would like to see proposal
rick: would like it on a per object basis
ted: you do not have to wait for the privacy draft from Blaze
ted: all other issues have been dealt with in the current doc
ed: was worrying if the blaze draft would have implications about this work
ted: no
george: the feeling of the group is that if we don't do this, then the
         IESG will not pass it on
richard: if it is mandatory to implement, the lawyers will use it
rick: what richard is saying is that just because it is there, we will
       be required to use it.
rick: we will all have to use it
randy: not all (referring to ccTLDs)
rick: but we need to suck it up and do this
ed: i hear one voice against this
rick: what is this?
richard: it is a good idea, I just want options
ed: does anybody else feel we shouldn't go here
rick: we have been told to go here
yan: among technical people on privacy, there is not much support for
      mandatory to implement. i saw support for dcp per session
unknown: does it have to be core or extension?
room: core
jan: there are a lot of marginal cases... i see no problem marginal cases in
      extensions
ed: what we are looking for is a basic of way doing it... extensions can
     be used for exotic cases
ed: this is up for proposed standard, if it turns out that nobody uses it,
     this feature will go away before draft
jan: implementors may pay lip service to core features, but will always use
      their own extensions
ed: our standardization process also for understanding when the features are
     not used before going to draft standard
jk: ignore the iesg policy, the likelihood of law against using this feature
     is near zero. the likelihood of the opposite is pretty high. therefore
     having them is the pragmatic option
richard: extensions
jk: no, you need it for interoperability purposes
jk: if you are doing business around the world, you will have to do
     extensions for each jurisdiction
jk: this is better for interoperability.
jk: if extensions are not standardized, it hurts everybody
richard: want standard core set of extensions
richard: mandatory to implement but optional to use is probably the best
          we can do. I object to the way the IESG has forced this on us.
ted: i want to make sure the room has a common understanding of the
      technical requirement
ted: do we agree on a mechanism for a registrar to registry do not
      publish or do not disclose on a per element basis?
george: we could do it per session
ted: registrar tell registry on per element basis which elements are
      dnp... does not mean syntactically on a per element basis
jan: this sounds like a particular syntax
ted: no
jan: i would like to see a requirement
ed: we are talking just about moving the enforcement point
jan: the requirement should say that the registrar should define to
      registry the privacy policy
jan: i disagree on this definition of privacy
ed: for this peace of information, you cannot disclose to anybody else
jan: but that has different meanings
ed: we don't want to spend time discussing what do not disclose means
jan: I want to know the real requirement... this is not a requirement, but
      a solution
jan: my impression is that a solution is being proposed as a requirement
george: but this might not be sufficient granularity
ed: I think you misinterpreted what I was saying
rick: we are not agreeing and have different needs, per object vs per
       session, registry enforced and registrar enforced. all of these
       options are valid and we need to find a solution that addresses all
       for of those.
ted: i am not trying to suggest a solution but a needed semantic, it is
      just difficult to do without discussing syntax.
ted: provide the basic binary functionality
ted: I agree with jk on going down the extensions path
ted: asks scott to write a mechanism to do this
scott: one was already proposed?
ed: I'd like to send to this list what we have discussed today.
ed: we also want to define something that is simple.
rick: I want to leave this room with the technical requirement in a
       few sentences
george: it would be a useful exercise on which elements it does not apply to
george: per elements mean on the set of elements it would apply to
jan: yes, and certain elements do not make sense based on the update
      command and the info command
unknown: we are not convinced that this cannot be achieved with extension
rick: yes
ed: procedurally it has problems with getting docs published
rick: we have been told by the IESG not to do extension
rick: we don't have a concrete problem statement
george: what you have on the screen can be made into the problem statement
ed: on prob. statement:
             1- granularity
             2-movement of enforcement
             3-mandatory to implement
             4-data unacceptable to registry
             4-setting method a or b is by receiver
             5 - not accepting data
             6- all data vs identifying info
rick: per session or per object?
scott: expresses concern that per session and per object could conflict
george: describes how he thinks about it for addresses
scott: what do you define a session
george: your session is my transaction
rick: are people backing off the per session issue?
room: silence
jan: per request not per session
rick: i think we agree
george: per element is only on those elements it would make sense to use
         on, not all elements in the protocol
rick: only social, not all
ed: per object/element/data facet
ed: do we want to try use an older archive proposal?
rick: can you solve that problem statement?
scott: looking in the archives
scott: pulling up message from archive
scott: describes blob solution
george: this would permit distinction between technical and abuse contacts
scott: yes
scott: at what level of granularity do we want
rick: i'm looking for clarification on how this works
scott: there was a friendly amendment to it... trying to pull it up
jan: wants disclose yes/no for an update
rick: this is for updates
scott: we need an update for this
scott: should the info command spit back the dnp preferences
rick: yes
scott: yes
unknown: what about getting back which elements you can disclose
ed: what would the registry refuse to let you change?
ed: does dcp do this?
scott: it doesn't have that granularity
ed: you want a failure code about not being able to set a dnp
scott & ed: multiple errors could be dealt with out of band
scott: agrees with this amendment
ed: we'll document this in one email
george: costs to implement should be documented
jan: I have made an argument for a simple syntax
jan: registry should have flexibility for default values
ted: dnd flag should be discussed to be yes for everything or no for everything
ed: we have discussed that before
ted: it should be done to be all uniform for the default
edmund: are we only talking about contact. what about domain.
ed: we are talking about domain and contact
edmund: domain is important across registries
edmund: they would use the same contact object
edmund: is there a per domain proposal for on/off on different elements
ed: I thought we were talking about any kind of object... no wait, just
     social data
scott: that would only be contact info
ed: this goes back to paf's statement. domain mapping?
ed: we'll make it clear in the list
ed: we will go to the list with proposal to see if it is agreed it will
     solve the IESG request

ed: on to extensions doc
ed: the ext doc exists to help people to figure out how to write epp
     extension documents
scott: new doc soon
ed: asks room to review the new doc

ed: on to host objects
ed: issues are coming up on the list, but we are not coming to closure on
     any of them.
ed: want to know epp is requiring host objects is causing issues with
     doing registrations?
ed: asks to see if anybody wants to volunteer info about this discussion
suzanne: we will implement what registries want
ed: I've heard this complaint from openReg. Would like the list of open steps.
frederico: what is the real reason for a host object?
frederico: is it because we need a way to change host names
scott: it was there originally for historical reason, but some do it
        differently.
scott: there are bulk operations where the object based models makes the
        process much more efficient... like address and name changes.
frederico: when you are talking about strictly needed for glue records
frederico: it could be handled in other parts of the protocol. host
            object only there for host name changes
frederico: has some security implications for registries with different models
frederico: how do you know that the people putting this info in you
            database are authoritative for it
frederico: enforcing this in the protocol is keeping a model that causes
            problems
scott: the issue of authority is addressed in either object or attribute models
frederico: but we have another mechanism for doing host checks
scott: why can't you use it?
scott: accepting the registration has nothing to do of whether it is an
        object or an attribute
frederico: it makes more sense to be attributes of the domain
joeng: we've had this discussion many times. the epp basic protocol
        and some kind of mappings
joeng: epp defines an environment to setup new mappings
joeng: a lot of ccTLD do not fit in the standard mappings and use extensions
joeng: you can define your own domain objects
rick: we made a decision on this.
rick: there is an issue where a domain can be deleted because of a host
       underneath it.
rick: there may be ways to get it to work if we go down this road
rick: there are trade-offs with both ways
rick: I think looking at this is reasonable and in scope for the group
rick: we made a choice, but we are now discovering a number of use cases
       where it causes issues
ed: we are now getting a wider range of review, and this is probably why
     we are seeing this issue now.
scott: that very proposal was discussed in the past
rick: but that proposal was either or
scott: no, it wasn't and the proposal was shot down
unknown: there has been a move to a uniform model since epp. we use to do
          non object method, but are now doing it.
frederico: has anguish over writing extensions for basic operations

ed: on to other flare up issues
ed: anyone here want to speak about roid or other issues.
ed: what about last verified? where did rick go?
rick: you said it was consensus, but only person said they wanted it that
       way (last verified as ext.)
ed: do you have anything to make us change our mind?
rick: no

ed: any other topics?
room: silence
ed: we are done

rick: what are the action items?
ed: take privacy problem to list.
scott: what is the mechanism to do that?
ed: I'll send out a summary
rick: can you simply state the problem in 3/4 sentences so that it sticks out.
ed: showing early discussion point on the projector
rick: I can help you word-smith it
ed: the problem and the approach are different things
ted: you sending both in the same message?
ed: separate messages.
ted: it is up to you, but the room seems to want the approach might help
      gel consensus.
ed: ok, that would provide more context
ed: action item 2: look at the old approach and ask if it is acceptable
ed: action item 3: send it to the IESG
ed: action item 4: ted buys us beer
ed: this will go out early next week
ed: a period of month... well before Vienna.
scott: what should I do with the 09 version of the core protocol.
rick: there are registries preparing to come out with implementations
       of the latest drafts.
scott: would rather hold of on real -9
ed: let's talk about that on the list
scott: but we know it doesn't answer the problems the IESG has
ed: let's ask it on the list
rick: I think we know now it will not meet that requirement, so we can say
       that now.
ed: you are right.
ted: you might want to hold off.
ed: are we done?
room: leaving

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            [phone]
ARIN Research Engineer

"I'm sorry, sir, your flight is delayed for maintenance.  We are
pounding out the dents from the last landing."


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3EEUvRN006017 for <[e-mail]>; Mon, 14 Apr 2003 16:30:57 +0200 (MEST)
Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h3EEUvU0006016 for ietf-provreg-outgoing; Mon, 14 Apr 2003 16:30:57 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from smtp2.arin.net (smtp2.arin.net [192.149.252.32]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3EEUtRN006011 for <[e-mail]>; Mon, 14 Apr 2003 16:30:56 +0200 (MEST)
Received: by smtp2.arin.net (Postfix, from userid 5003) id 0F8744CB; Mon, 14 Apr 2003 10:30:55 -0400 (EDT)
Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id 94DEA4C9 for <[e-mail]>; Mon, 14 Apr 2003 10:30:54 -0400 (EDT)
Received: from [192.136.136.71] (HELO [192.149.252.108]) by arin.net (CommuniGate Pro SMTP 4.0.6) with ESMTP id 183823; Mon, 14 Apr 2003 10:21:26 -0400
Mime-Version: 1.0
X-Sender: edlewis@ops
Message-Id: <a05111b02bac0725e4d7d@[192.149.252.108]>
Date: Mon, 14 Apr 2003 10:22:38 -0400
To: [e-mail]
From: Edward Lewis <[e-mail]>
Subject: [ietf-provreg] host attributes
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Status: No, hits=-1.3 required=5.0 tests=SIGNATURE_SHORT_SPARSE,SPAM_PHRASE_00_01 version=2.43-arin1
X-Spam-Level: 
Sender: [e-mail]
Precedence: bulk

I think we can safely declare consensus on the host attributes issue, 
with a chair-requested adjustment from the message Scott sent:

    http://www.cafax.se/ietf-provreg/maillist/2003-04/msg00028.html

(and the followup from Frederico: "Here there is a missing 
<domain:hostAttr> or I'm misunderstanding something ?", or course.)

The one change I request, in the name of remaining non-IPv4 specific 
is to add to the example a IPv6 address example....

# Example domain attributes that describe host machines:
#
...
#     <domain:hostAddr ip="v4">192.0.2.2</domain:hostAddr>
>      <domain:hostAddr ip="v6">fe80::1</domain:hostAddr>
...

The MX RR issue will be left to extensions for the time being. 
Scott, could you add a paragraph to the document to summarize why 
only address records appear as domain attributes.  My experience with 
the DNS documents is that it is good to document the non-features too.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            [phone]
ARIN Research Engineer

"I'm sorry, sir, your flight is delayed for maintenance.  We are
pounding out the dents from the last landing."


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3BNmtRN010109 for <[e-mail]>; Sat, 12 Apr 2003 01:48:55 +0200 (MEST)
Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h3BNmtMP010108 for ietf-provreg-outgoing; Sat, 12 Apr 2003 01:48:55 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3BNmpRN010103 for <[e-mail]>; Sat, 12 Apr 2003 01:48:54 +0200 (MEST)
Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.9/8.12.9) with ESMTP id h3BNfSZj024452; Fri, 11 Apr 2003 19:41:28 -0400 (EDT)
Message-Id: <[e-mail]>
To: Edward Lewis <[e-mail]>
cc: "Hollenbeck, Scott" <[e-mail]>, "'Joe Abley'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, [e-mail]
Subject: Re: [ietf-provreg] References for Today's Host Object Discussion 
In-Reply-To: Your message of "Thu, 10 Apr 2003 11:27:41 EDT." <a05111b04babb3a18bc67@[192.136.135.238]> 
Date: Fri, 11 Apr 2003 19:41:28 -0400
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

...
> Well, I was going to make other statements, but writing an ironclad 
> rule would be foolish. I was going to say something about only 
> including what is generic to all registry policies, but then the 
> client-provided "privacy" meta-data (with apologies to EBW) would 
> fail the test. 

Just for clarity, the <dcp> still is for a registry (server) mechanism for data collection
policy announcement, whether MANDITORY or OPTIONAL.

The directionality could be reversed, and a registrar (client) mechanism for data donor
policy  constructed, again, MANDITORY or OPTIONAL.

>             ... (Not all registries will want to deal with 
> client-provided data...)  

And not all registrars will want to deal with server policies either. Some will want the
current CNO rules (none, or ICANN).

>                       ... The difference between the 'privacy' (sorry 
> EBW) and the MX issue is that the umbrella issues are different. 

Actually "privacy" can't apply to an MX record under the 96/46/ec framework, and it is
hard to see how anything other than "non-disclosure" could apply in the US or OECD set
of frameworks. There is no "individual" in an MX record.

> 'Privacy' (sorry EBW) is further reaching through the realm of 
> registry operations (and registrar operations) than the use of the MX 
> record for the health of registrations.  (Not all 
> registries/registrars will perform such thorough testing, but all 
> will deal with, sorry EBW, privacy.)

This is a good point, regardless of the policies associated with "privacy" (sorry EL)
or MX records (and publication via 1034/35 generally), the mechanism that provisions
an MX record to a zone file (any format) is more narrowly constrained that the mechanism
that generally provisions data, some of which will end up in a zone file, or on the floor,
to a registry.

Imagine a registry that did not publish data via 1034/35, but only via 954. Solving for
MX does not solve for the whole problem. Yes, there are registries that only publish via
1034/35, and not by 954.

I don't think I've ever seen my initials so ... exhuberently frequent in a single piece
of mail. 

	...as rare as sushi at a forest service fire fighter's bar ... 

Cheers,
Eric


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3BGPcRN006581 for <[e-mail]>; Fri, 11 Apr 2003 18:25:38 +0200 (MEST)
Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h3BGPcnT006580 for ietf-provreg-outgoing; Fri, 11 Apr 2003 18:25:38 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3BGPYRN006571 for <[e-mail]>; Fri, 11 Apr 2003 18:25:34 +0200 (MEST)
Received: from [192.149.252.108] ([192.136.136.88]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id MAA11850; Fri, 11 Apr 2003 12:25:18 -0400 (EDT)
Mime-Version: 1.0
X-Sender: edlewis@ops
Message-Id: <a05111b11babc99636863@[192.149.252.108]>
In-Reply-To:  <[e-mail]>
References:  <[e-mail]>
Date: Fri, 11 Apr 2003 12:23:15 -0400
To: =?iso-8859-1?Q?=22J=F6rg_Bauer=2FDenic=22?=  <[e-mail]>
From: Edward Lewis <[e-mail]>
Subject: Re: [ietf-provreg] References for Today's Host Object Discussion
Cc: [e-mail]
Content-Type: text/plain; charset="iso-8859-1" ; format="flowed"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id h3BGPZRN006575
Sender: [e-mail]
Precedence: bulk

At 8:59 +0200 4/11/03, Jörg Bauer/Denic wrote:

>The idea behind it is that it doesn´t forbit you to just use NS and (glue)
>A Records, it´s up to the policy, but it also alows you to store other
>records into the zone.
>Just think about DS Records (for DNSSEC). Maybe it makes sence to get
>these records too.

Under the banner of getting the first job done first without 
squelching improvements...

DS RR's are still not defined in any archived document (e.g., RFC), 
they are not even experimental, much less standards track, so I'd 
hesitate to think that far ahead.  Yes, doing whatever is necessary 
to facilitate DNSSEC is something I've been pushing for for quite 
some time, but it's not appropriate to tie EPP (version 1.0) to that 
boat anchor at this time.

Scott Hollenbeck has written a non-WG draft describing how DNSSEC 
could be accommodated in EPP extensions.  Note that this is a live 
debate, but just not one being conducted in the working group.  Nor 
is the debate, although alive, progressing anywhere rapidly, so far 
as I know, it's just there.

>Of cause you can develop extensions for all this kind of stuff, but i see
>a BIG problem with interoperability if al lot of Registries are going to
>have their own extensions.

This is what we are trying to avoid.  But sometimes it is hard to 
anticipate what the greatest common denominator is before folks run 
off and do (hopefully prototypes of) non-interoperable things.

I understand the dilemma, but the IETF process is built on putting 
engineering before the realities of business needs to maintain a 
revenue stream.  I'm not saying that the IETF process is necessarily 
correct in this manner, just that there is a conflict here.  This is 
what makes the job of chairing a group like this, umm, so rewarding. 
;)

>I also see the  drawback of this approach: the records aren´t "well
>defined". You have a name, a type and all the rest. But to have some more
>level of flexibility inside the protocoll, i prefer also to have such kind
>of mapping.
>
>Maybe we can put two type of mapping inside:
>1. a pure DNS+Glue mapping
>2. a "whatever you want, put into DNS" mapping

Number 1 is a pretty clearly defined case.  Number 2 is not, and 
dealing with problems that are not clearly defined is a recipe for 
disaster when you are expecting to meet a deadline or a near-term 
goal of reaching a basic protocol.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            [phone]
ARIN Research Engineer

   ...as rare as a fire at a sushi bar...



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3BBchRN003928 for <[e-mail]>; Fri, 11 Apr 2003 13:38:43 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h3BBcgCr003927 for ietf-provreg-outgoing; Fri, 11 Apr 2003 13:38:42 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.237.102]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3BBcfRN003922 for <[e-mail]>; Fri, 11 Apr 2003 13:38:42 +0200 (MEST)
Received: from vsvapostalgw3.prod.netsol.com (vsvapostalgw3.prod.netsol.com [10.170.12.61]) by heron.verisign.com (8.12.9/8.12.9) with ESMTP id h3BBaNaj008271; Fri, 11 Apr 2003 07:36:23 -0400 (EDT)
Received: by vsvapostalgw3.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <2SCD66FJ>; Fri, 11 Apr 2003 07:34:59 -0400
Message-ID: <5BEA6CDB196A4241B8BE129D309AA4AF10E669@vsvapostal8>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Edward Lewis'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: [ietf-provreg] References for Today's Host Object Discussion
Date: Fri, 11 Apr 2003 07:35:00 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id h3BBcgRN003923
Sender: [e-mail]
Precedence: bulk

> I've got one question about the below, and I would like to hear Jörg 
> Bauer's thoughts on making the MX registration an extension as you 
> (Scott) suggest.
> 
> My question - do you want these to be MUSTs or SHOULDs?  I understand 
> the desire that a server (operator) be consistent, but is this vital 
> to the protocol?

I think the MUSTs make life more predictable from a client perspective.  If
host object support is announced, you use host objects to do domain
delegations.  If host object support isn't announced you use attributes.
There's no situation where the client is sending something that the server
doesn't explicitly support.

-Scott-

> As far as the MX RR issue, as a protocol person, I think that I can 
> see why you would limit the EPP core spec to doing just the A 
> records.  IMO, the A record - and I should point out that we have to 
> be IP version fair according to our requirements - or the AAAA or any 
> other experimental/future address record is a special case here. 
> Only address records are eligible to be glue in DNS, MX's and others 
> aren't.
> 
> Using MX records and others for registry debugging is fine, but it is 
> a registry policy to do so and therefore out of scope for the core of 
> EPP.
> 
> So, as a chair I'm urging the group to consider the issue Jörg raised 
> in the context of:
>      1) From a generic protocol design perspective, there is 
> a reason to
>         treat DNS data eligible to be glue (A RR) differently 
> from those
>         that are not (MX).
> Well, I was going to make other statements, but writing an ironclad 
> rule would be foolish. I was going to say something about only 
> including what is generic to all registry policies, but then the 
> client-provided "privacy" meta-data (with apologies to EBW) would 
> fail the test.  (Not all registries will want to deal with 
> client-provided data...)  The difference between the 'privacy' (sorry 
> EBW) and the MX issue is that the umbrella issues are different. 
> 'Privacy' (sorry EBW) is further reaching through the realm of 
> registry operations (and registrar operations) than the use of the MX 
> record for the health of registrations.  (Not all 
> registries/registrars will perform such thorough testing, but all 
> will deal with, sorry EBW, privacy.)
> 
> >Text:
> >
> >"Name server hosts for domain delegation can be specified as either
> >references to existing host objects or as domain attributes 
> that describe a
> >host machine.  A server operator MUST use one name server 
> specification form
> >consistently.  A server operator that announces support for 
> host objects
> >MUST NOT allow domain attributes to describe a name server 
> host machine.  A
> >server operator that does not announce support for host 
> objects MUST allow
> >domain attributes to describe a name server host machine."
> >
> >The idea here is that it's a bad idea to allow some domain 
> objects in a
> >repository to reference host objects and others to use 
> domain attributes
> >that describe a host machine.  Using one form consistently will make
> >implementation and server management easier.
> 
> -- 
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> -=-=-=-=-
> Edward Lewis                                            
> [phone]
> ARIN Research Engineer
> 
>    ...as rare as a fire at a sushi bar...
> 



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3BBNLRN003730 for <[e-mail]>; Fri, 11 Apr 2003 13:23:21 +0200 (MEST)
Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h3BBNKxE003729 for ietf-provreg-outgoing; Fri, 11 Apr 2003 13:23:20 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.237.102]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3BBNJRN003724 for <[e-mail]>; Fri, 11 Apr 2003 13:23:19 +0200 (MEST)
Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [10.170.12.38]) by heron.verisign.com (8.12.9/8.12.9) with ESMTP id h3BBL0aj007956; Fri, 11 Apr 2003 07:21:00 -0400 (EDT)
Received: by vsvapostalgw1.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <2SB7S49Y>; Fri, 11 Apr 2003 07:19:38 -0400
Message-ID: <5BEA6CDB196A4241B8BE129D309AA4AF10E668@vsvapostal8>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Edward Lewis'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: [ietf-provreg] References for Today's Host Object Discussion
Date: Fri, 11 Apr 2003 07:19:37 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

> In an attempt to focus the discussion, however, I'd lean towards 
> restricting ourselves towards concentrating on the NS & glue case and 
> not on the MX case.  (MX might not be the only one that could be 
> added.)  It's not that I want to suffocate new ideas in the WG, but 
> it is better to meet the original goal first before expanding the 
> mission.

I concur.  We already have a mechanism for general resource record
provisioning.  Adding another increases the risk of interoperability
incompatibility.

-Scott-


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3BASFRN003353 for <[e-mail]>; Fri, 11 Apr 2003 12:28:15 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h3BASFlE003352 for ietf-provreg-outgoing; Fri, 11 Apr 2003 12:28:15 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3BASDRN003325 for <[e-mail]>; Fri, 11 Apr 2003 12:28:13 +0200 (MEST)
Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.9/8.12.9) with ESMTP id h3BAKxZj022058; Fri, 11 Apr 2003 06:20:59 -0400 (EDT)
Message-Id: <[e-mail]>
To: Joseph Reagle <[e-mail]>
cc: Eric Brunner-Williams in Portland Maine <[e-mail]>, "Hollenbeck, Scott" <[e-mail]>, Edward Lewis <[e-mail]>, [e-mail], [e-mail], [e-mail]
Subject: Re: [ietf-provreg] [BH] P3P and Extensible Provisioning Protocol 
In-Reply-To: Your message of "Wed, 09 Apr 2003 17:09:13 EDT." <[e-mail]> 
Date: Fri, 11 Apr 2003 06:20:59 -0400
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

> If the initial data collection had a particular policy (P3P)

This may be a theory-of-foo bump, or it may be a slow moving armidillo, but
data originates at a registrar.

We (epp-hat==1) aren't designing the registrar's UI.

> ... wouldn't it be 
> best to pass on the initial P3P agreed to, with the data, when ...

This is an aside, but (you asked for it). A party interposes on the data
flow between source and sink, and edits the data. Is policy unaffected by
the transform? I gave this a lot of thought before, and after, the joint
WAPF/W3C meeting in Munich (Dec 1999), and concluded that proof of closure
was not trivial.

For the IETFers, take a look at any of the three cache BoF/WGs that came
out two years ago -- there was a reason why Mark Nottingham (co-chair, WEBI)
attended our f2f at IETF-51 (London), and it wasn't just because we were
then both contributors to the W3C's P3P Spec WG.

Of these, only Leslie's considered the possibility that cached content
was policied (in an IRTF-IDRM-esque fashion) before it was transformed
for edge device delivery.

For the P3Pers, consider a nice bit of html with a nice p3p statement in
the usual WKL. It is accessed via a WAP device, and transformed by some
WAP content management cache for "last mile" lower bandwidth link reasons,
and additional operator policy goals ("walled garden"). How does an user's
p3p evaluation engine evaluate the delivered p3p statement(s)?

Anyway, we don't know that there was a p3p statement when the data was
initially collected by the agent/reseller/registrar. What we do know is
that a registrar is surrendering, and possibly retaining, data, and a
registry is collecting, and possibly discarding, data.

> when it is distributed to those with the "same" policies?

But it isn't. There are several adminstrative or jurisdictional policies
that the registrar-collected data might be provisioned (onward-transported)
to, and the registries may be unable, under the distinct operational and/or
policy regimes they operate under, to accept some registrar-collected data,
regardless of the policy under which that data was collected.

...

> I didn't follow this bit.

Assume no one has any use for 95/46/ec, or the OECD Guidelines, or the FTC
rule-of-the-day (generally, policy on collectors), and only wants raw read
and write access on the registries, and a trap on read-requests by other,
to interpose a write (or its static equivalent, some sort of mask), for a
registrant (user), and/or his/her cluefull agency.

Now (epp-hat==1) and (p3p-hat==1) are very, very far apart. Sailing on
different currents altogether, and diverging too.

Fortunately, this [1] shows that the problem is minor. Also, the ICANN
Registrars may be limiting whois (both bulk and :43) more effectively
than we (PROVREG +/- IESG) are.

Cheers,
Eric

[1] http://www.cdt.org/speech/spam/030319spamreport.pdf


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3B6xnRN001549 for <[e-mail]>; Fri, 11 Apr 2003 08:59:49 +0200 (MEST)
Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h3B6xnFS001548 for ietf-provreg-outgoing; Fri, 11 Apr 2003 08:59:49 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from smtp.denic.de (smtp.denic.de [194.246.96.22]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3B6xmRN001543 for <[e-mail]>; Fri, 11 Apr 2003 08:59:48 +0200 (MEST)
Received: from notes.denic.de (denics15.denic.de [194.246.96.18]) by smtp.denic.de with esmtp  id 193sVo-0007PN-00; Fri, 11 Apr 2003 08:59:48 +0200
In-Reply-To: <a05111b06babb8d682bd7@[192.149.252.108]>
To: [e-mail]
Subject: Re: [ietf-provreg] References for Today's Host Object Discussion
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.0 September 26, 2002
From: "=?iso-8859-1?Q?J=F6rg_Bauer=2FDenic?=" <[e-mail]>
Message-ID: <[e-mail]>
Date: Fri, 11 Apr 2003 08:59:42 +0200
X-MIMETrack: Serialize by Router on notes/Denic(Release 5.0.11 |July 24, 2002) at 11.04.2003 08:59:46, Serialize complete at 11.04.2003 08:59:46
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id h3B6xmRN001544
Sender: [e-mail]
Precedence: bulk

[e-mail] wrote on 10.04.2003 23:17:07:

> 
> 
> I have been under the assumption that we were talking about 
> provisioning domain names, yes, provreg is chartered to be more 
> general but in the short term we've focused on domain names, hence 
> the only DNS records would be NS's and glue for the time being.
> 
> Would excluding MX's (et.al.) be too shortsighted for our 
> extensibility (E of EPP)?  Would only considering NS's and glue be 
> sufficient for EPP 1.0?

May be it was not clear:
I don´t talk of including MX RR into the protocol, i´m talkink of the 
possibility to put "whatever you want" into the protocol.

The idea behind it is that it doesn´t forbit you to just use NS and (glue) 
A Records, it´s up to the policy, but it also alows you to store other 
records into the zone.
Just think about DS Records (for DNSSEC). Maybe it makes sence to get 
these records too.

Of cause you can develop extensions for all this kind of stuff, but i see 
a BIG problem with interoperability if al lot of Registries are going to 
have their own extensions.

I also see the  drawback of this approach: the records aren´t "well 
defined". You have a name, a type and all the rest. But to have some more 
level of flexibility inside the protocoll, i prefer also to have such kind 
of mapping.

Maybe we can put two type of mapping inside:
1. a pure DNS+Glue mapping
2. a "whatever you want, put into DNS" mapping

> 




Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3ALQSRN026022 for <[e-mail]>; Thu, 10 Apr 2003 23:26:28 +0200 (MEST)
Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h3ALQSTh026021 for ietf-provreg-outgoing; Thu, 10 Apr 2003 23:26:28 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from buffoon.automagic.org (buffoon.automagic.org [208.185.30.208]) by nic.cafax.se (8.12.9/8.12.9) with SMTP id h3ALQMRN026015 for <[e-mail]>; Thu, 10 Apr 2003 23:26:24 +0200 (MEST)
Received: (qmail 96652 invoked by uid 0); 10 Apr 2003 21:26:17 -0000
Received: from localhost.automagic.org (HELO isc.org) (root@127.0.0.1) by localhost.automagic.org with SMTP; 10 Apr 2003 21:26:17 -0000
Date: Thu, 10 Apr 2003 17:26:16 -0400
Subject: Re: [ietf-provreg] References for Today's Host Object Discussion
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v552)
Cc: "Hollenbeck, Scott" <[e-mail]>, "'[e-mail]'" <[e-mail]>
To: Edward Lewis <[e-mail]>
From: Joe Abley <[e-mail]>
In-Reply-To: <a05111b06babb8d682bd7@[192.149.252.108]>
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.552)
Sender: [e-mail]
Precedence: bulk

On Thursday, Apr 10, 2003, at 17:17 Canada/Eastern, Edward Lewis wrote:

> Would excluding MX's (et.al.) be too shortsighted for our 
> extensibility (E of EPP)?

If we can add them using extensions, I would say that is plenty of 
support.

> Would only considering NS's and glue be sufficient for EPP 1.0?

I would say yes.

[My previous comment was really just a clarification of what it was I 
was talking about, and not any kind of opinion that RRs other than NS 
and glue should be supported in the base set of documents.]


Joe



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3ALJCRN025975 for <[e-mail]>; Thu, 10 Apr 2003 23:19:12 +0200 (MEST)
Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h3ALJCS7025974 for ietf-provreg-outgoing; Thu, 10 Apr 2003 23:19:12 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3ALJARN025967 for <[e-mail]>; Thu, 10 Apr 2003 23:19:11 +0200 (MEST)
Received: from [192.149.252.108] ([192.136.136.41]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id RAA11009; Thu, 10 Apr 2003 17:19:07 -0400 (EDT)
Mime-Version: 1.0
X-Sender: edlewis@ops
Message-Id: <a05111b06babb8d682bd7@[192.149.252.108]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Thu, 10 Apr 2003 17:17:07 -0400
To: Joe Abley <[e-mail]>
From: Edward Lewis <[e-mail]>
Subject: Re: [ietf-provreg] References for Today's Host Object Discussion
Cc: Edward Lewis <[e-mail]>, "Hollenbeck, Scott" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk

Speaking as co-chair -


Hmmm.


I have been under the assumption that we were talking about 
provisioning domain names, yes, provreg is chartered to be more 
general but in the short term we've focused on domain names, hence 
the only DNS records would be NS's and glue for the time being.

Would excluding MX's (et.al.) be too shortsighted for our 
extensibility (E of EPP)?  Would only considering NS's and glue be 
sufficient for EPP 1.0?

In an attempt to focus the discussion, however, I'd lean towards 
restricting ourselves towards concentrating on the NS & glue case and 
not on the MX case.  (MX might not be the only one that could be 
added.)  It's not that I want to suffocate new ideas in the WG, but 
it is better to meet the original goal first before expanding the 
mission.

At 16:50 -0400 4/10/03, Joe Abley wrote:
>I've seen more than one ccTLD zone that started off looking like that (indeed,
>that started off with NS records in the zone being a rarity, and A, MX and TXT
>records being much more common).

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            [phone]
ARIN Research Engineer

   ...as rare as a fire at a sushi bar...


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3AKoZRN025583 for <[e-mail]>; Thu, 10 Apr 2003 22:50:35 +0200 (MEST)
Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h3AKoZlE025582 for ietf-provreg-outgoing; Thu, 10 Apr 2003 22:50:35 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from buffoon.automagic.org (buffoon.automagic.org [208.185.30.208]) by nic.cafax.se (8.12.9/8.12.9) with SMTP id h3AKoWRN025577 for <[e-mail]>; Thu, 10 Apr 2003 22:50:33 +0200 (MEST)
Received: (qmail 94026 invoked by uid 0); 10 Apr 2003 20:50:29 -0000
Received: from localhost.automagic.org (HELO isc.org) (root@127.0.0.1) by localhost.automagic.org with SMTP; 10 Apr 2003 20:50:29 -0000
Date: Thu, 10 Apr 2003 16:50:28 -0400
Subject: Re: [ietf-provreg] References for Today's Host Object Discussion
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v552)
Cc: "Hollenbeck, Scott" <[e-mail]>, "'[e-mail]'" <[e-mail]>
To: Edward Lewis <[e-mail]>
From: Joe Abley <[e-mail]>
In-Reply-To: <a05111b05babb86d0a04c@[192.149.252.108]>
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.552)
Sender: [e-mail]
Precedence: bulk

On Thursday, Apr 10, 2003, at 16:45 Canada/Eastern, Edward Lewis wrote:

> Speaking as a DNS person - you don't need glue for MX's because you 
> get that from the A records sitting at the NS-named machines.  You 
> need NS glue because there's nowhere else to get the A records other 
> than NS-named machines.  (Speaking grossly.)
>
> In the example below, "smtp.example2 A" isn't glue, it's part of the 
> "something." zone.

Sure. But I thought the case we were talking about was that where the 
"something." zone contains bare MX records, and there *is* no 
delegation (hence no NS-named machines).

I agree they're not glue, though. The idea I was trying to convey was 
that they were records whose function was to make the MX records 
useful, in the same kind of way that glue records' function is to make 
NS records useful.

I've seen more than one ccTLD zone that started off looking like that 
(indeed, that started off with NS records in the zone being a rarity, 
and A, MX and TXT records being much more common).



Joe



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3AKkHRN025466 for <[e-mail]>; Thu, 10 Apr 2003 22:46:17 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h3AKkHaf025465 for ietf-provreg-outgoing; Thu, 10 Apr 2003 22:46:17 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3AKkFRN025460 for <[e-mail]>; Thu, 10 Apr 2003 22:46:16 +0200 (MEST)
Received: from [192.149.252.108] ([192.136.136.41]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id QAA06625; Thu, 10 Apr 2003 16:46:12 -0400 (EDT)
Mime-Version: 1.0
X-Sender: edlewis@ops
Message-Id: <a05111b05babb86d0a04c@[192.149.252.108]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Thu, 10 Apr 2003 16:45:22 -0400
To: Joe Abley <[e-mail]>
From: Edward Lewis <[e-mail]>
Subject: Re: [ietf-provreg] References for Today's Host Object Discussion
Cc: Edward Lewis <[e-mail]>, "Hollenbeck, Scott" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk

Speaking as a DNS person - you don't need glue for MX's because you 
get that from the A records sitting at the NS-named machines.  You 
need NS glue because there's nowhere else to get the A records other 
than NS-named machines.  (Speaking grossly.)

In the example below, "smtp.example2 A" isn't glue, it's part of the 
"something." zone.


At 16:33 -0400 4/10/03, Joe Abley wrote:
>On Thursday, Apr 10, 2003, at 11:27 Canada/Eastern, Edward Lewis wrote:
>
>>  As far as the MX RR issue, as a protocol person, I think that I can
>>  see why you would limit the EPP core spec to doing just the A
>>  records.  IMO, the A record - and I should point out that we have to
>>  be IP version fair according to our requirements - or the AAAA or any
>>  other experimental/future address record is a special case here.
>>  Only address records are eligible to be glue in DNS, MX's and others
>>  aren't.
>
>Some MX records might need glue just as some NS records need glue:
>
>$ORIGIN something.
>
>example1 NS ns1.example1
>example1 NS felix.automagic.org.
>
>ns1.example1 A 199.212.93.1
>
>example2 MX 10 smtp.example2
>example2 MX 20 felix.automagic.org.
>
>smtp.example2 A 199.212.92.1
>
>Is MX (and friends) vs. A really the comparison you should be 
>making? Or should it be MX (and friends) vs. NS?
>
>
>Joe

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            [phone]
ARIN Research Engineer

   ...as rare as a fire at a sushi bar...


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3AKeoRN025413 for <[e-mail]>; Thu, 10 Apr 2003 22:40:50 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h3AKeocP025412 for ietf-provreg-outgoing; Thu, 10 Apr 2003 22:40:50 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3AKemRN025407 for <[e-mail]>; Thu, 10 Apr 2003 22:40:48 +0200 (MEST)
Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.9/8.12.9) with ESMTP id h3AKXiZj019559; Thu, 10 Apr 2003 16:33:44 -0400 (EDT)
Message-Id: <[e-mail]>
To: Edward Lewis <[e-mail]>
cc: Joseph Reagle <[e-mail]>, Eric Brunner-Williams in Portland Maine <[e-mail]>, [e-mail], [e-mail], [e-mail]
Subject: Re: [ietf-provreg] [BH] P3P and Extensible Provisioning Protocol 
In-Reply-To: Your message of "Thu, 10 Apr 2003 12:33:04 EDT." <a05111b05babb3e66beaa@[192.136.135.238]> 
Date: Thu, 10 Apr 2003 16:33:44 -0400
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

> Sheesh, okay EBW, "no one suggested doing it - on our mailing list." ;) ;)

Granted, I had prior general knowledge, but it did leak into PROVREG, via its
principle implementor.

------- Forwarded Messages

Return-Path: [e-mail]
Delivery-Date: Sat Feb  1 13:37:27 2003
Return-Path: <[e-mail]>
Received: from nic.cafax.se (nic.cafax.se [192.71.228.17])
	by nic-naa.net (8.12.6/8.12.6) with ESMTP id h11IbQRS025784
	for <[e-mail]>; Sat, 1 Feb 2003 13:37:27 -0500 (EST)
	(envelope-from [e-mail])
Received: from nic.cafax.se (localhost [127.0.0.1])
	by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h11IQF9p008342
	for <[e-mail]>; Sat, 1 Feb 2003 19:26:15 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id h11IQFAo008341
	for ietf-provreg-outgoing; Sat, 1 Feb 2003 19:26:15 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from bartok.sidn.nl (bartok.sidn.nl [193.176.144.164])
	by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h11IQE9p008336
	for <[e-mail]>; Sat, 1 Feb 2003 19:26:14 +0100 (MET)
Received: from bartok.sidn.nl (localhost.sidn.nl [IPv6:::1])
	by bartok.sidn.nl (8.12.6/8.12.6) with ESMTP id h11IQEMH047050
	for <[e-mail]>; Sat, 1 Feb 2003 19:26:14 +0100 (CET)
	(envelope-from [e-mail])
Received: (from jaap@localhost)
	by bartok.sidn.nl (8.12.6/8.12.6/Submit) id h11IQDcX047049
	for [e-mail]; Sat, 1 Feb 2003 19:26:13 +0100 (CET)
Received: from eddie.Austria.EU.net (eddie.austria.eu.net [193.154.142.22])
	by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h11IJE9p008209
	for <[e-mail]>; Sat, 1 Feb 2003 19:19:14 +0100 (MET)
Received: from eddie.Austria.EU.net (localhost [127.0.0.1])
	by eddie.Austria.EU.net (8.12.3/8.12.3/Debian -4) with ESMTP id h11IJDs5012961
	for <[e-mail]>; Sat, 1 Feb 2003 19:19:13 +0100
Received: (from lendl@localhost)
	by eddie.Austria.EU.net (8.12.3/8.12.3/Debian -4) id h11IJDf9012960
	for [e-mail]; Sat, 1 Feb 2003 19:19:13 +0100
Date: Sat, 1 Feb 2003 19:19:13 +0100
From: Otmar Lendl <[e-mail]>
To: [e-mail]
Subject: [ietf-provreg] FYI: nic.at presentations from RIPE44
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.3.23i
Sender: [e-mail]
Precedence: bulk

On 2003/02/01 18:02, Jaap Akkerhuis <[e-mail]> wrote:
> At the DNR-forum at RIPE-44 last week, the polish registry presented
> their implementation of EPP.

On a related note: Our presentation from monday's Centr workshop
are online as well. You can get the .ppt files (and the latest source
code tarballs) from 
http://sourceforge.net/project/showfiles.php?group_id=66464 .

/ol


------- Message 2

Return-Path: [e-mail]
Delivery-Date: Sat Feb  1 14:03:03 2003
Return-Path: <[e-mail]>
Received: from nic.cafax.se (nic.cafax.se [192.71.228.17])
	by nic-naa.net (8.12.6/8.12.6) with ESMTP id h11J32RS025829
	for <[e-mail]>; Sat, 1 Feb 2003 14:03:03 -0500 (EST)
	(envelope-from [e-mail])
Received: from nic.cafax.se (localhost [127.0.0.1])
	by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h11Ipr9p008607
	for <[e-mail]>; Sat, 1 Feb 2003 19:51:53 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id h11IpruU008606
	for ietf-provreg-outgoing; Sat, 1 Feb 2003 19:51:53 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from bartok.sidn.nl (bartok.sidn.nl [193.176.144.164])
	by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h11Ipq9p008601
	for <[e-mail]>; Sat, 1 Feb 2003 19:51:53 +0100 (MET)
Received: from bartok.sidn.nl (localhost.sidn.nl [127.0.0.1])
	by bartok.sidn.nl (8.12.6/8.12.6) with ESMTP id h11IpqMH047140
	for <[e-mail]>; Sat, 1 Feb 2003 19:51:52 +0100 (CET)
	(envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: [ietf-provreg] FYI: nic.at presentations from RIPE44 
In-reply-to: Your message of Sat, 01 Feb 2003 19:19:13 +0100.
             <[e-mail]> 
Date: Sat, 01 Feb 2003 19:51:52 +0100
From: Jaap Akkerhuis <[e-mail]>
Sender: [e-mail]
Precedence: bulk


    On 2003/02/01 18:02, Jaap Akkerhuis <[e-mail]> wrote:
    > At the DNR-forum at RIPE-44 last week, the polish registry presented
    > their implementation of EPP.

    On a related note: Our presentation from monday's Centr workshop
    are online as well. You can get the .ppt files (and the latest
    source code tarballs) from
    http://sourceforge.net/project/showfiles.php?group_id=66464 .

Let me clarify a bit about this. At the first day of RIPE meetings
there is usually a CENTR technical meeting. This time, the afternoon
was devoted to EPP.  SInce the meeting is limited to CENTR members
and invitees (Scott Hollenbeck was there, among others) I don't
feel comfortable about quoting from that, although often the meeting
minutes are published on the CENTR website.

Anyway, Otmar Lendl on behalf of the Austrian registry, presented
at the centr-tech meeting an implementation of an EPP server as a
mod_epp Apache module.  It is nice to see that this is actually
public information. For details, see the URL he mentions.

	jaap

------- End of Forwarded Messages



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3AKXCRN025327 for <[e-mail]>; Thu, 10 Apr 2003 22:33:12 +0200 (MEST)
Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h3AKXCMT025326 for ietf-provreg-outgoing; Thu, 10 Apr 2003 22:33:12 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from buffoon.automagic.org (buffoon.automagic.org [208.185.30.208]) by nic.cafax.se (8.12.9/8.12.9) with SMTP id h3AKXARN025321 for <[e-mail]>; Thu, 10 Apr 2003 22:33:10 +0200 (MEST)
Received: (qmail 92747 invoked by uid 0); 10 Apr 2003 20:33:09 -0000
Received: from localhost.automagic.org (HELO isc.org) (root@127.0.0.1) by localhost.automagic.org with SMTP; 10 Apr 2003 20:33:09 -0000
Date: Thu, 10 Apr 2003 16:33:08 -0400
Subject: Re: [ietf-provreg] References for Today's Host Object Discussion
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v552)
Cc: "Hollenbeck, Scott" <[e-mail]>, "'[e-mail]'" <[e-mail]>
To: Edward Lewis <[e-mail]>
From: Joe Abley <[e-mail]>
In-Reply-To: <a05111b04babb3a18bc67@[192.136.135.238]>
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.552)
Sender: [e-mail]
Precedence: bulk

On Thursday, Apr 10, 2003, at 11:27 Canada/Eastern, Edward Lewis wrote:

> As far as the MX RR issue, as a protocol person, I think that I can
> see why you would limit the EPP core spec to doing just the A
> records.  IMO, the A record - and I should point out that we have to
> be IP version fair according to our requirements - or the AAAA or any
> other experimental/future address record is a special case here.
> Only address records are eligible to be glue in DNS, MX's and others
> aren't.

Some MX records might need glue just as some NS records need glue:

$ORIGIN something.

example1 NS ns1.example1
example1 NS felix.automagic.org.

ns1.example1 A 199.212.93.1

example2 MX 10 smtp.example2
example2 MX 20 felix.automagic.org.

smtp.example2 A 199.212.92.1

Is MX (and friends) vs. A really the comparison you should be making? 
Or should it be MX (and friends) vs. NS?


Joe



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3AKO6RN025192 for <[e-mail]>; Thu, 10 Apr 2003 22:24:06 +0200 (MEST)
Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h3AKO5Og025191 for ietf-provreg-outgoing; Thu, 10 Apr 2003 22:24:05 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3AKO4RN025186 for <[e-mail]>; Thu, 10 Apr 2003 22:24:05 +0200 (MEST)
Received: from [192.149.252.108] ([192.136.136.41]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id QAA03128; Thu, 10 Apr 2003 16:23:48 -0400 (EDT)
Mime-Version: 1.0
X-Sender: edlewis@ops
Message-Id: <a05111b05babb3e66beaa@[192.136.135.238]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Thu, 10 Apr 2003 12:33:04 -0400
To: Joseph Reagle <[e-mail]>, Eric Brunner-Williams in Portland Maine <[e-mail]>
From: Edward Lewis <[e-mail]>
Subject: Re: [ietf-provreg] [BH] P3P and Extensible Provisioning Protocol
Cc: [e-mail], [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk

At 20:27 -0400 4/7/03, Eric Brunner-Williams in Portland Maine wrote:
>Joseph,
>
>>  > It's not so much that HTTP was rejected, no one suggested doing it.
>>
>>  Understood.
>
>There is an implementation.

Sheesh, okay EBW, "no one suggested doing it - on our mailing list." ;) ;)

(I'm joking.  But, really, the implementation is news to me - it 
hasn't been mentioned in the group.)

As for the answer to most of the other points, the reason why you 
(now = Joesph Reagle) might not be seeing the expected detail is that 
we as a group are at a loss in defining what privacy means to us.

Given the scope of what we are accomplishing, a full determination of 
privacy is considered to be too much work within our venue.  We are 
settling on some mechanisms that we can only hope (at this time) will 
support a sufficiently large realm of interested parties.

I mention this because you ask about disputes, remedies, etc.  Those 
are things definitely beyond what we can afford to consider in our 
problem space.

PS - I should add that although a deeper discussion of privacy is 
somewhat beyond our (= IETF provreg WG) hopes given time and 
resources, questions on the topic are within scope.  It just might 
take some time to answer them.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            [phone]
ARIN Research Engineer

   ...as rare as a fire at a sushi bar...


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3AKNnRN025179 for <[e-mail]>; Thu, 10 Apr 2003 22:23:49 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h3AKNnTw025178 for ietf-provreg-outgoing; Thu, 10 Apr 2003 22:23:49 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3AKNlRN025171 for <[e-mail]>; Thu, 10 Apr 2003 22:23:47 +0200 (MEST)
Received: from [192.149.252.108] ([192.136.136.41]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id QAA03112; Thu, 10 Apr 2003 16:23:43 -0400 (EDT)
Mime-Version: 1.0
X-Sender: edlewis@ops
Message-Id: <a05111b04babb3a18bc67@[192.136.135.238]>
In-Reply-To: <5BEA6CDB196A4241B8BE129D309AA4AF10E635@vsvapostal8>
References: <5BEA6CDB196A4241B8BE129D309AA4AF10E635@vsvapostal8>
Date: Thu, 10 Apr 2003 11:27:41 -0400
To: "Hollenbeck, Scott" <[e-mail]>
From: Edward Lewis <[e-mail]>
Subject: RE: [ietf-provreg] References for Today's Host Object Discussion
Cc: "'Joe Abley'" <[e-mail]>, "'Edward Lewis'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Content-Type: text/plain; charset="iso-8859-1" ; format="flowed"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id h3AKNmRN025174
Sender: [e-mail]
Precedence: bulk

Apologies to the group - I was in a "ARIN member meeting black-out" 
for a few days...

At 13:56 -0400 4/8/03, Hollenbeck, Scott wrote:
>Ed: so when can we move forward with document edits for this and the privacy
>proposal?

I've got one question about the below, and I would like to hear Jörg 
Bauer's thoughts on making the MX registration an extension as you 
(Scott) suggest.

My question - do you want these to be MUSTs or SHOULDs?  I understand 
the desire that a server (operator) be consistent, but is this vital 
to the protocol?

As far as the MX RR issue, as a protocol person, I think that I can 
see why you would limit the EPP core spec to doing just the A 
records.  IMO, the A record - and I should point out that we have to 
be IP version fair according to our requirements - or the AAAA or any 
other experimental/future address record is a special case here. 
Only address records are eligible to be glue in DNS, MX's and others 
aren't.

Using MX records and others for registry debugging is fine, but it is 
a registry policy to do so and therefore out of scope for the core of 
EPP.

So, as a chair I'm urging the group to consider the issue Jörg raised 
in the context of:
     1) From a generic protocol design perspective, there is a reason to
        treat DNS data eligible to be glue (A RR) differently from those
        that are not (MX).
Well, I was going to make other statements, but writing an ironclad 
rule would be foolish. I was going to say something about only 
including what is generic to all registry policies, but then the 
client-provided "privacy" meta-data (with apologies to EBW) would 
fail the test.  (Not all registries will want to deal with 
client-provided data...)  The difference between the 'privacy' (sorry 
EBW) and the MX issue is that the umbrella issues are different. 
'Privacy' (sorry EBW) is further reaching through the realm of 
registry operations (and registrar operations) than the use of the MX 
record for the health of registrations.  (Not all 
registries/registrars will perform such thorough testing, but all 
will deal with, sorry EBW, privacy.)

>Text:
>
>"Name server hosts for domain delegation can be specified as either
>references to existing host objects or as domain attributes that describe a
>host machine.  A server operator MUST use one name server specification form
>consistently.  A server operator that announces support for host objects
>MUST NOT allow domain attributes to describe a name server host machine.  A
>server operator that does not announce support for host objects MUST allow
>domain attributes to describe a name server host machine."
>
>The idea here is that it's a bad idea to allow some domain objects in a
>repository to reference host objects and others to use domain attributes
>that describe a host machine.  Using one form consistently will make
>implementation and server management easier.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            [phone]
ARIN Research Engineer

   ...as rare as a fire at a sushi bar...



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3A8sORN017577 for <[e-mail]>; Thu, 10 Apr 2003 10:54:24 +0200 (MEST)
Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h3A8sNdV017576 for ietf-provreg-outgoing; Thu, 10 Apr 2003 10:54:23 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from bartok.sidn.nl (bartok.sidn.nl [193.176.144.164]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h3A8sMRN017571 for <[e-mail]>; Thu, 10 Apr 2003 10:54:22 +0200 (MEST)
Received: from bartok.sidn.nl (localhost.sidn.nl [IPv6:::1]) by bartok.sidn.nl (8.12.9/8.12.9) with ESMTP id h3A8sHuc060234 for <[e-mail]>; Thu, 10 Apr 2003 10:54:17 +0200 (CEST) (envelope-from [e-mail])
Received: (from jaap@localhost) by bartok.sidn.nl (8.12.9/8.12.6/Submit) id h3A8sFMa060233 for [e-mail]; Thu, 10 Apr 2003 10:54:15 +0200 (CEST)
Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h39LMbRN011632 for <[e-mail]>; Wed, 9 Apr 2003 23:22:37 +0200 (MEST)
Received: from localhost (IDENT:[e-mail] [18.29.0.27]) by tux.w3.org (8.12.9/8.12.9) with ESMTP id h39L9Esi006485; Wed, 9 Apr 2003 17:09:18 -0400
From: Joseph Reagle <[e-mail]>
Organization: W3C
To: Eric Brunner-Williams in Portland Maine <[e-mail]>
Subject: Re: [ietf-provreg] [BH] P3P and Extensible Provisioning Protocol
Date: Wed, 9 Apr 2003 17:09:13 -0400
User-Agent: KMail/1.5.1
Cc: "Hollenbeck, Scott" <[e-mail]>, Edward Lewis <[e-mail]>, [e-mail], [e-mail], [e-mail]
References: <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

On Monday 07 April 2003 20:27, Eric Brunner-Williams in Portland Maine 
wrote:
> p3p:nonident - does not collect identified data
> epp:null - data is not persistent
>
> The problem-domains are not identical. P3P is concerned with "initial
> data collection", EPP is concerned with "onward transport" of data
> previously collected.

If the initial data collection had a particular policy (P3P) wouldn't it be 
best to pass on the initial P3P agreed to, with the data, when it is 
distributed to those with the "same" policies?

Let me back way up and ask what data is involved here? Was there a usage 
scenario? (Didn't see one, but I expect its clear to those involved with 
provreg, of which I'm mostly ignorant.) I was presuming, as you said, that 
the data was initially collected by a registrar and then shared with a 
registry. So for instance:
  https://www.gandi.net/whois?l=EN&domain=w3.org
contains personally identifiable data. My (continued) presumption was that 
the registrar, Gandi, might have a policy associated with the collection of 
this information. Now, Gandi might also share this with a .org TLD registry 
data base. So in it's initial <create> it would see the registry <greeting> 
and note its <dcp> (policy). If this didn't match the data it collected it 
under, then it might not upload the information if it said p3p:same, or it 
might if it said p3p:other-recipient. (In the first case, it's more likely 
to say p3p:public since whois is public, or at least to set its privacy 
policy based on the policies it knows it must interact with on the back 
end.)

However, my scenario, which is probably incorrect, fails to predict the 
variances in EPP.

> As "others" are the IESG, looking at what bits of a data collection vocab
> are substantially similar, or dissimilar, across problem domains, may not
> be the best use of anyone's time.

I didn't follow this bit.



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h39BXeRN005160 for <[e-mail]>; Wed, 9 Apr 2003 13:33:40 +0200 (MEST)
Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h39BXevc005159 for ietf-provreg-outgoing; Wed, 9 Apr 2003 13:33:40 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.237.102]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h39BXcRN005154 for <[e-mail]>; Wed, 9 Apr 2003 13:33:38 +0200 (MEST)
Received: from vsvapostalgw3.prod.netsol.com (vsvapostalgw3.prod.netsol.com [10.170.12.61]) by heron.verisign.com (8.12.9/8.12.9) with ESMTP id h39BYxaj009794; Wed, 9 Apr 2003 07:34:59 -0400 (EDT)
Received: by vsvapostalgw3.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <2SCD5MMX>; Wed, 9 Apr 2003 07:33:36 -0400
Message-ID: <5BEA6CDB196A4241B8BE129D309AA4AF10E640@vsvapostal8>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Frederico A C Neves'" <[e-mail]>, [e-mail]
Subject: RE: [ietf-provreg] References for Today's Host Object Discussion
Date: Wed, 9 Apr 2003 07:33:37 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

> > Example domain attributes that describe host machines:
> > 
> > <domain:ns>
> >   <domain:hostAttr>
> >     <domain:hostName>ns1.example.com</domain:hostName>
> >   </domain:hostAttr>
> 
> Here there is a missing <domain:hostAttr> or I'm misunderstanding
> something ?
> 
> >     <domain:hostName>ns1.example.net</domain:hostName>
> >     <domain:hostAddr ip="v4">192.0.2.2</domain:hostAddr>
> >   </domain:hostAttr>
> > </domain:ns>

Ooops, you're right, Fred.  There's a <domain:hostAttr> element missing.
I'll catch and fix those sorts of errors when I fix the documents, schemas,
and examples.

-Scott-


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h39BVHRN005102 for <[e-mail]>; Wed, 9 Apr 2003 13:31:17 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h39BVHB4005100 for ietf-provreg-outgoing; Wed, 9 Apr 2003 13:31:17 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.237.102]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h39BVGRN005095 for <[e-mail]>; Wed, 9 Apr 2003 13:31:17 +0200 (MEST)
Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [10.170.12.38]) by heron.verisign.com (8.12.9/8.12.9) with ESMTP id h39BWbaj009721; Wed, 9 Apr 2003 07:32:37 -0400 (EDT)
Received: by vsvapostalgw1.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <2SB7P4KN>; Wed, 9 Apr 2003 07:31:15 -0400
Message-ID: <5BEA6CDB196A4241B8BE129D309AA4AF10E63F@vsvapostal8>
From: "Hollenbeck, Scott" <[e-mail]>
To: =?iso-8859-1?Q?=27J=F6rg_Bauer/Denic=27?= <[e-mail]>, [e-mail]
Subject: RE: [ietf-provreg] References for Today's Host Object Discussion
Date: Wed, 9 Apr 2003 07:31:15 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id h39BVHRN005096
Sender: [e-mail]
Precedence: bulk

> So, if we are going to change the protocoll I would like to 
> have something 
> like:
> 
> <domain:ns>
>    <domain:hostAttr>
>      <domain:hostName>myhost.example.com</domain:hostName>
>      <domain:hostType>A</domain:hostAddr>
>      <domain:hostRHS>192.0.2.2</domain:hostAddr>
>    </domain:hostAttr>
>    <domain:hostAttr>
>      <domain:hostName>*.example.net</domain:hostName>
>      <domain:hostType>MX</domain:hostAddr>
>      <domain:hostRHS>10 mail.example.net</domain:hostAddr>
>    </domain:hostAttr>
> </domain:ns>

While I can understand Jörg's historical reasons for suggesting this, this
is a prime example of a feature that should be added via an extension -- I
even have an XML schema set aside for provisioning MX records as a result of
a conversation I had a while back with some folks from .au.  I'll share it
off-list to anyone who asks.

I've already documented mappings for other resource records, including NAPTR
and DS records, that use the extension mechanism.  MX is just another RR
that fits the same way.

-Scott-



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h39BLZRN004996 for <[e-mail]>; Wed, 9 Apr 2003 13:21:35 +0200 (MEST)
Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h39BLZMY004995 for ietf-provreg-outgoing; Wed, 9 Apr 2003 13:21:35 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h39BLXRN004990 for <[e-mail]>; Wed, 9 Apr 2003 13:21:33 +0200 (MEST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21851; Wed, 9 Apr 2003 07:18:57 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: [ietf-provreg] I-D ACTION:draft-ietf-provreg-epp-ext-01.txt
Date: Wed, 09 Apr 2003 07:18:56 -0400
Sender: [e-mail]
Precedence: bulk

--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		: Guidelines for Extending the Extensible Provisioning 
                          Protocol
	Author(s)	: S. Hollenbeck
	Filename	: draft-ietf-provreg-epp-ext-01.txt
	Pages		: 16
	Date		: 2003-4-8
	
The Extensible Provisioning Protocol (EPP) is 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 presents guidelines for use of EPP's extension mechanisms to
define new features and object management capabilities.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-ext-01.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-ext-01.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:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-provreg-epp-ext-01.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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

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

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

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h397GqRN003100 for <[e-mail]>; Wed, 9 Apr 2003 09:16:52 +0200 (MEST)
Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h397Gqxm003099 for ietf-provreg-outgoing; Wed, 9 Apr 2003 09:16:52 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from smtp.denic.de (smtp.denic.de [194.246.96.22]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h397GpRN003094 for <[e-mail]>; Wed, 9 Apr 2003 09:16:51 +0200 (MEST)
Received: from notes.denic.de (denics15.denic.de [194.246.96.18]) by smtp.denic.de with esmtp  id 1939pC-0006he-00; Wed, 9 Apr 2003 09:16:51 +0200
In-Reply-To: <5BEA6CDB196A4241B8BE129D309AA4AF10E635@vsvapostal8>
To: [e-mail]
Subject: RE: [ietf-provreg] References for Today's Host Object Discussion
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.0 September 26, 2002
From: "=?iso-8859-1?Q?J=F6rg_Bauer=2FDenic?=" <[e-mail]>
Message-ID: <[e-mail]>
Date: Wed, 9 Apr 2003 09:16:49 +0200
X-MIMETrack: Serialize by Router on notes/Denic(Release 5.0.11 |July 24, 2002) at 09.04.2003 09:16:50, Serialize complete at 09.04.2003 09:16:50
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id h397GqRN003095
Sender: [e-mail]
Precedence: bulk

To make things even worser. 

At the .DE Registry we also registering A and MX records.

means: for these domains we don´t do delegation, we include the machines 
directly into our zone. (don´t hit us for doing this, there are historical 
reasons ...)

So, if we are going to change the protocoll I would like to have something 
like:

<domain:ns>
   <domain:hostAttr>
     <domain:hostName>myhost.example.com</domain:hostName>
     <domain:hostType>A</domain:hostAddr>
     <domain:hostRHS>192.0.2.2</domain:hostAddr>
   </domain:hostAttr>
   <domain:hostAttr>
     <domain:hostName>*.example.net</domain:hostName>
     <domain:hostType>MX</domain:hostAddr>
     <domain:hostRHS>10 mail.example.net</domain:hostAddr>
   </domain:hostAttr>
</domain:ns>

(hostRHS = host right hand side = everything which is after the type in 
the zonedata

With this solution it is possible to put everything inside a hostAttr. 
Then it is up to the registry to define a policy and to accept/reject 
these entries.



[e-mail] wrote on 08.04.2003 19:56:29:

> 
> Example domain attributes that describe host machines:
> 
> <domain:ns>
>   <domain:hostAttr>
>     <domain:hostName>ns1.example.com</domain:hostName>
>   </domain:hostAttr>
>     <domain:hostName>ns1.example.net</domain:hostName>
>     <domain:hostAddr ip="v4">192.0.2.2</domain:hostAddr>
>   </domain:hostAttr>
> </domain:ns>
> 
> Ed: so when can we move forward with document edits for this and the 
privacy
> proposal?
> 
> -Scott-

> ForwardSourceID:NT000391FE 



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h390mVRN029642 for <[e-mail]>; Wed, 9 Apr 2003 02:48:31 +0200 (MEST)
Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h390mVVb029641 for ietf-provreg-outgoing; Wed, 9 Apr 2003 02:48:31 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from clone.registro.br (clone.registro.br [200.160.2.4]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h390mURN029636 for <[e-mail]>; Wed, 9 Apr 2003 02:48:30 +0200 (MEST)
Received: by clone.registro.br (Postfix, from userid 1000) id A19149299; Tue,  8 Apr 2003 21:48:29 -0300 (BRT)
Date: Tue, 8 Apr 2003 21:48:29 -0300
From: Frederico A C Neves <[e-mail]>
To: [e-mail]
Subject: Re: [ietf-provreg] References for Today's Host Object Discussion
Message-ID: <[e-mail]>
References: <5BEA6CDB196A4241B8BE129D309AA4AF10E635@vsvapostal8> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

On Tue, Apr 08, 2003 at 02:36:44PM -0400, Joe Abley wrote:
...
> 
> Stronger text which says that IP addresses MUST only be present in host 
> attributes if the host name is subordinate to the containing domain 
> object name sounds like it is more than is required (and e.g. will not 
> be compatible with the data in the NL registry, as per Jaap.
> 
> 

Joe,

What about the inversion on the requirement as a MUST without the only.

"... the IP addresses MUST be present in host attributes if the host
name is subordinated to the containing domain object ..."

This way it's compatible as Jaap described for .NL and solves the glue
problem were it's explicitly needed.

> Joe
> 

Fred


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h390fCRN029578 for <[e-mail]>; Wed, 9 Apr 2003 02:41:12 +0200 (MEST)
Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h390fC7S029577 for ietf-provreg-outgoing; Wed, 9 Apr 2003 02:41:12 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from clone.registro.br (clone.registro.br [200.160.2.4]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h390fARN029572 for <[e-mail]>; Wed, 9 Apr 2003 02:41:11 +0200 (MEST)
Received: by clone.registro.br (Postfix, from userid 1000) id 5D8E89299; Tue,  8 Apr 2003 21:41:09 -0300 (BRT)
Date: Tue, 8 Apr 2003 21:41:09 -0300
From: Frederico A C Neves <[e-mail]>
To: [e-mail]
Subject: Re: [ietf-provreg] References for Today's Host Object Discussion
Message-ID: <[e-mail]>
References: <5BEA6CDB196A4241B8BE129D309AA4AF10E635@vsvapostal8>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5BEA6CDB196A4241B8BE129D309AA4AF10E635@vsvapostal8>
Sender: [e-mail]
Precedence: bulk

Scott,

On Tue, Apr 08, 2003 at 01:56:29PM -0400, Hollenbeck, Scott wrote:
> > This looks good. It would be helpful to see the descriptive text you 
> > mentioned (and some example requests) to confirm that I'm 
> > understanding 
> > what you mean, exactly.
> 
> Text:
> 
> "Name server hosts for domain delegation can be specified as either
> references to existing host objects or as domain attributes that describe a
> host machine.  A server operator MUST use one name server specification form
> consistently.  A server operator that announces support for host objects
> MUST NOT allow domain attributes to describe a name server host machine.  A
> server operator that does not announce support for host objects MUST allow
> domain attributes to describe a name server host machine."
> 
> The idea here is that it's a bad idea to allow some domain objects in a
> repository to reference host objects and others to use domain attributes
> that describe a host machine.  Using one form consistently will make
> implementation and server management easier.
> 

This text is perfect for .br and solves all the problems I've tried to
explain at SF. If this moves forward we'll not need to use an
extension describing a different domain mapping or another crude hack,
so I'm all in favor of this.

> Example host object references:
> 
> <domain:ns>
>   <domain:hostObj>ns1.example.com</domain:hostObj>
>   <domain:hostObj>ns1.example.net</domain:hostObj>
> </domain:ns>
> 
> Example domain attributes that describe host machines:
> 
> <domain:ns>
>   <domain:hostAttr>
>     <domain:hostName>ns1.example.com</domain:hostName>
>   </domain:hostAttr>

Here there is a missing <domain:hostAttr> or I'm misunderstanding
something ?

>     <domain:hostName>ns1.example.net</domain:hostName>
>     <domain:hostAddr ip="v4">192.0.2.2</domain:hostAddr>
>   </domain:hostAttr>
> </domain:ns>
> 
> Ed: so when can we move forward with document edits for this and the privacy
> proposal?
> 
> -Scott-

Fred


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h38IadRN026245 for <[e-mail]>; Tue, 8 Apr 2003 20:36:39 +0200 (MEST)
Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h38IadNC026244 for ietf-provreg-outgoing; Tue, 8 Apr 2003 20:36:39 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from buffoon.automagic.org (buffoon.automagic.org [208.185.30.208]) by nic.cafax.se (8.12.9/8.12.9) with SMTP id h38IabRN026239 for <[e-mail]>; Tue, 8 Apr 2003 20:36:38 +0200 (MEST)
Received: (qmail 89866 invoked by uid 0); 8 Apr 2003 18:36:36 -0000
Received: from localhost.automagic.org (HELO isc.org) (root@127.0.0.1) by localhost.automagic.org with SMTP; 8 Apr 2003 18:36:36 -0000
Date: Tue, 8 Apr 2003 14:36:44 -0400
Subject: Re: [ietf-provreg] References for Today's Host Object Discussion
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v552)
Cc: "'Edward Lewis'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
To: "Hollenbeck, Scott" <[e-mail]>
From: Joe Abley <[e-mail]>
In-Reply-To: <5BEA6CDB196A4241B8BE129D309AA4AF10E635@vsvapostal8>
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.552)
Sender: [e-mail]
Precedence: bulk

On Tuesday, Apr 8, 2003, at 13:56 Canada/Eastern, Hollenbeck, Scott 
wrote:

>> This looks good. It would be helpful to see the descriptive text you
>> mentioned (and some example requests) to confirm that I'm
>> understanding
>> what you mean, exactly.
>
> Text:
>
> "Name server hosts for domain delegation can be specified as either
> references to existing host objects or as domain attributes that 
> describe a
> host machine.  A server operator MUST use one name server 
> specification form
> consistently.  A server operator that announces support for host 
> objects
> MUST NOT allow domain attributes to describe a name server host 
> machine.  A
> server operator that does not announce support for host objects MUST 
> allow
> domain attributes to describe a name server host machine."
>
> The idea here is that it's a bad idea to allow some domain objects in a
> repository to reference host objects and others to use domain 
> attributes
> that describe a host machine.  Using one form consistently will make
> implementation and server management easier.
>
> [examples]

Cool, that's what I understood. That's all good.

I presume that text would slot into draft-ietf-provreg-epp-domain-06 
section 1.1 in some way (the corresponding section in 
draft-ietf-provreg-epp-host-06 could maybe stay as-is, since if you 
need the spec for host objects you're probably not running a server 
that uses host attributes on domain objects).

The domain mapping document should presumably inherit some text along 
the lines of section 2.5 in the host mapping document, to the effect 
that "When a host object is provisioned for use as a DNS name server, 
IP addresses SHOULD be required only as needed to generate DNS glue 
records."

Stronger text which says that IP addresses MUST only be present in host 
attributes if the host name is subordinate to the containing domain 
object name sounds like it is more than is required (and e.g. will not 
be compatible with the data in the NL registry, as per Jaap.


Joe



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h38I0BRN025719 for <[e-mail]>; Tue, 8 Apr 2003 20:00:12 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h38I0Bk0025718 for ietf-provreg-outgoing; Tue, 8 Apr 2003 20:00:11 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.237.102]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h38I0ARN025713 for <[e-mail]>; Tue, 8 Apr 2003 20:00:11 +0200 (MEST)
Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [10.170.12.38]) by heron.verisign.com (8.12.9/8.12.9) with ESMTP id h38Hvpaj014264; Tue, 8 Apr 2003 13:57:51 -0400 (EDT)
Received: by vsvapostalgw1.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <2HKCPTYP>; Tue, 8 Apr 2003 13:56:29 -0400
Message-ID: <5BEA6CDB196A4241B8BE129D309AA4AF10E635@vsvapostal8>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Joe Abley'" <[e-mail]>
Cc: "'Edward Lewis'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: [ietf-provreg] References for Today's Host Object Discussion
Date: Tue, 8 Apr 2003 13:56:29 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

> This looks good. It would be helpful to see the descriptive text you 
> mentioned (and some example requests) to confirm that I'm 
> understanding 
> what you mean, exactly.

Text:

"Name server hosts for domain delegation can be specified as either
references to existing host objects or as domain attributes that describe a
host machine.  A server operator MUST use one name server specification form
consistently.  A server operator that announces support for host objects
MUST NOT allow domain attributes to describe a name server host machine.  A
server operator that does not announce support for host objects MUST allow
domain attributes to describe a name server host machine."

The idea here is that it's a bad idea to allow some domain objects in a
repository to reference host objects and others to use domain attributes
that describe a host machine.  Using one form consistently will make
implementation and server management easier.

Example host object references:

<domain:ns>
  <domain:hostObj>ns1.example.com</domain:hostObj>
  <domain:hostObj>ns1.example.net</domain:hostObj>
</domain:ns>

Example domain attributes that describe host machines:

<domain:ns>
  <domain:hostAttr>
    <domain:hostName>ns1.example.com</domain:hostName>
  </domain:hostAttr>
    <domain:hostName>ns1.example.net</domain:hostName>
    <domain:hostAddr ip="v4">192.0.2.2</domain:hostAddr>
  </domain:hostAttr>
</domain:ns>

Ed: so when can we move forward with document edits for this and the privacy
proposal?

-Scott-


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h380Y7RN014253 for <[e-mail]>; Tue, 8 Apr 2003 02:34:07 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h380Y7hq014252 for ietf-provreg-outgoing; Tue, 8 Apr 2003 02:34:07 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h380Y6RN014247 for <[e-mail]>; Tue, 8 Apr 2003 02:34:06 +0200 (MEST)
Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.9/8.12.9) with ESMTP id h380RfZj006646; Mon, 7 Apr 2003 20:27:41 -0400 (EDT)
Message-Id: <[e-mail]>
To: Joseph Reagle <[e-mail]>
cc: "Hollenbeck, Scott" <[e-mail]>, Edward Lewis <[e-mail]>, [e-mail], [e-mail], [e-mail]
Subject: Re: [ietf-provreg] [BH] P3P and Extensible Provisioning Protocol 
In-Reply-To: Your message of "Mon, 07 Apr 2003 16:05:53 EDT." <[e-mail]> 
Date: Mon, 07 Apr 2003 20:27:41 -0400
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Joseph,

> > It's not so much that HTTP was rejected, no one suggested doing it.
> 
> Understood.

There is an implementation.

> ACCESS

The vocabulary element(s) in the EPP schema which correspond to the ACCESS
element are not identical to those in the P3P schema.

p3p:nonident - does not collect identified data
epp:null - data is not persistent

The problem-domains are not identical. P3P is concerned with "initial data
collection", EPP is concerned with "onward transport" of data previously 
collected.

Comment: Data that moves from one onward-transport node to another may not
be persistent on any particular node. In particular, a registry could sink
part of a data flow (technical data) and discard part of a data flow (social
data).

> DISPUTES
> EPP doesn't support how a dispute can be addressed.

There is no vocabulary element(s) in the EPP schema which correspond to
the DISPUTES-GROUP element, and its child DISPUTES elements.

No requirement in the problem-domain exists.

Comment: There is a regulatory regime that is controlling for a class of
operators, hence of implementors. There is the complement to that class,
which lacks an equivalent single regulatory regime, and may be particular
to each element in that class (ccTLD operators). There is yet another class
for which little activity is present (non-tld operators, non-dns operators,
and non-IANA root dns operatos, if any).

> REMEDIES
> EPP doesn't support this, see question in DISPUTES.

See above.

> NON-IDENTIFIABLE
> EPP doesn't support this, not sure why.

The problem-domains are not identical.

> PURPOSE
> EPP supports p3p:{admin, contact, other} and epp:prov. I can see the PURPOSE 
> varying widely across application contexts and I think it makes sense to 
> drop and extend from this axes as appropriate.

The comment is not clear.

> REQUIRED

(N.B. An optional child element of PURPOSE. EBW)

1. No requirement in the problem-domain exists for users.
2. No requirement statement for data in the problem-domain is optional.

> RETENTION
> See ACCESS.

See above.

I hope this has helped.

Now for something ... individual.

I advocated the <dcp> construct for this problem domain, because I thought
it the best mechanism to policy the data, and to allow scoped policies.
I've tried to kill whois:43 by several means, stealth, poision, very blunt
instruments (my wit), etc.

Others reject the notion that a protocol with a fixed grammer targeting a
particular application domain, in particular data collection, is of the
slightest use in this problem domain, and insist upon mechanism(s) that
support registrant ("user" in p3p usage) defined access et al models.

As "others" are the IESG, looking at what bits of a data collection vocab
are substantially similar, or dissimilar, across problem domains, may not
be the best use of anyone's time.

I hope this has helped too.

Eric

P.S. It might help to keep things in focus to recall every now and again
just how much, or little, anyone actually pays for "privacy". Indirect
cost recovery models for the internet may be ... historic.


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h37Er5RN008475 for <[e-mail]>; Mon, 7 Apr 2003 16:53:05 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h37Er5YV008474 for ietf-provreg-outgoing; Mon, 7 Apr 2003 16:53:05 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from bartok.sidn.nl (bartok.sidn.nl [193.176.144.164]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h37Er4RN008469 for <[e-mail]>; Mon, 7 Apr 2003 16:53:04 +0200 (MEST)
Received: from bartok.sidn.nl (localhost.sidn.nl [127.0.0.1]) by bartok.sidn.nl (8.12.9/8.12.9) with ESMTP id h37EoMuc017666; Mon, 7 Apr 2003 16:50:23 +0200 (CEST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Joe Abley <[e-mail]>
cc: "Hollenbeck, Scott" <[e-mail]>, "'Edward Lewis'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: Re: [ietf-provreg] References for Today's Host Object Discussion 
In-reply-to: Your message of Sat, 05 Apr 2003 16:22:06 -0500. <[e-mail]> 
Date: Mon, 07 Apr 2003 16:50:22 +0200
From: Jaap Akkerhuis <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Joe,
    
    There is one related issue that may deserve some thought. At the moment 
    an address is required for a host record if the host is named under the 
    apex of the registry. Where hosts are specified as attributes of domain 
    objects, however, there is the opportunity to modify that rule; 
    addresses can be required on hosts which are named under the domain in 
    whose object they appear.
    
    So, for example, a domain object for "automagic.org" might contain host 
    attributes for nameservers "buffoon.automagic.org", "ns1.flame.org" and 
    "foo.something-else.com". Only the "buffoon.automagic.org" host would 
    require addresses under the scheme outlined above.
    
    In the case of a registry which supports hosts-as-attributes, this (or 
    something like it) seems like it would be necessary to avoid different 
    domain objects containing conflicting addresses for hosts.
    
    
Well, as a registry which does that, we actually also like to have
ip#s for out of zone name servers (optionally). We check wether the
delegation exists for the domain at the mentioned nameservers.

If no ip#s are given, we use whatever we find from the DNS. If the
ip#s are given, we use those. This turns out to be useful when more
then one things are happening at the same time. The ip#s of name
servers itself might be changing as well (because of a merger of
parties involved etc.).  In cases like these the proper A record
might not be available yet.

Of course, we never publish the A for "foo.something-else.com" and
the like. We do keep the information archived. We keep an archive
of all transactions surrounding domain names. Just in case
(technical/juridical) problems pop up later.


	jaap


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h35LMIRN021134 for <[e-mail]>; Sat, 5 Apr 2003 23:22:18 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h35LMIJx021133 for ietf-provreg-outgoing; Sat, 5 Apr 2003 23:22:18 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from buffoon.automagic.org (buffoon.automagic.org [208.185.30.208]) by nic.cafax.se (8.12.9/8.12.9) with SMTP id h35LMHRN021128 for <[e-mail]>; Sat, 5 Apr 2003 23:22:17 +0200 (MEST)
Received: (qmail 15789 invoked by uid 0); 5 Apr 2003 21:22:13 -0000
Received: from localhost.automagic.org (HELO isc.org) (root@127.0.0.1) by localhost.automagic.org with SMTP; 5 Apr 2003 21:22:13 -0000
Date: Sat, 5 Apr 2003 16:22:06 -0500
Subject: Re: [ietf-provreg] References for Today's Host Object Discussion
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v552)
Cc: "'Edward Lewis'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
To: "Hollenbeck, Scott" <[e-mail]>
From: Joe Abley <[e-mail]>
In-Reply-To: <[e-mail]>
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.552)
Sender: [e-mail]
Precedence: bulk

Hey Scott,

On Monday, Mar 31, 2003, at 08:17 Canada/Eastern, Hollenbeck, Scott 
wrote:

>> 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 looks good. It would be helpful to see the descriptive text you 
mentioned (and some example requests) to confirm that I'm understanding 
what you mean, exactly.

There is one related issue that may deserve some thought. At the moment 
an address is required for a host record if the host is named under the 
apex of the registry. Where hosts are specified as attributes of domain 
objects, however, there is the opportunity to modify that rule; 
addresses can be required on hosts which are named under the domain in 
whose object they appear.

So, for example, a domain object for "automagic.org" might contain host 
attributes for nameservers "buffoon.automagic.org", "ns1.flame.org" and 
"foo.something-else.com". Only the "buffoon.automagic.org" host would 
require addresses under the scheme outlined above.

In the case of a registry which supports hosts-as-attributes, this (or 
something like it) seems like it would be necessary to avoid different 
domain objects containing conflicting addresses for hosts.


Joe



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h34DdxRN005413 for <[e-mail]>; Fri, 4 Apr 2003 15:39:59 +0200 (MEST)
Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h34Ddxsf005412 for ietf-provreg-outgoing; Fri, 4 Apr 2003 15:39:59 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.237.102]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h34DdvRN005407 for <[e-mail]>; Fri, 4 Apr 2003 15:39:57 +0200 (MEST)
Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [10.170.12.38]) by heron.verisign.com (8.12.9/8.12.9) with ESMTP id h34DfHjv019393; Fri, 4 Apr 2003 08:41:17 -0500 (EST)
Received: by vsvapostalgw1.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <2HKCLKA0>; Fri, 4 Apr 2003 08:39:55 -0500
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Joseph Reagle'" <[e-mail]>
Cc: [e-mail]
Subject: RE: [ietf-provreg] [BH] P3P and Extensible Provisioning Protocol 
Date: Fri, 4 Apr 2003 08:39:53 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

I'll add my two cents below to what Ed has already provided.

-Scott- 

> -----Original Message-----
> From: Joseph Reagle [mailto:[e-mail]]
> Sent: Wednesday, April 02, 2003 6:20 PM
> To: [e-mail]
> Cc: [e-mail]
> Subject: [ietf-provreg] [BH] P3P and Extensible Provisioning Protocol 
> 
> 
> Scott (and the PRP WG), 
> 
> I'm chairing a "Beyond HTTP" taskforce of the W3C P3P 
> Activity looking to 
> other applications and protocols for an understanding of 
> their requirements 
> for *reusing* P3P. We've noted [2] your use of P3P and I hope 
> you wouldn't 
> mind giving us some feedback so we can help others in your 
> context re-use 
> as much as possible of P3P -- mitigating and confusing divergences.
> 
> 1. Did you find anything particularly troublesome with 
> adapting P3P to your 
> context from a protocol/binding position? (I assume not, you 
> just include 
> P3P in your XML.) Do you have any scenarios where your XML 
> application 
> would also be transported over HTTP, which itself could 
> conceivable have a 
> P3P policy? (Or is this an unlikely scenario?)

The most significant issue that we had to deal with involved an analysis of
the elements from the perspextive of our operational model.  We're not
dealing with web browser users and web servers, so many of the web-specific
features of P3P weren't of interest to us.

Our XML protocol *could* be transported over HTTP, but that's not something
we're currently doing in the provreg WG.  The IETF has had a bit of
heartburn lately about layering protocols on top of HTTP.

> 2. What led you to make the changes to the vocabulary that 
> you did? (Some 
> terms are removed, some are altered -- we're these casual 
> changes or did 
> you have significant market/policy tensions in your app context?)

It was all an attempt to tailor the P3P elements to the EPP operating
environment.  We wanted to eliminate elements that weren't needed and ensure
that those that remained made sense in our operational context.

> 3. Your XML app does use schema, did you give any thought to 
> actually using 
> elements from the P3P namespace and if so, what discouraged that?

Yes, we did.  See my responses to 1. and 2. above for the rationale.

> 4. Do you have any other feedback that I've missed? <smile/>

Not really.  I found P3P to be a very complete work, it was just contained
more than what we needed.

-Scott-


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h33MMpRN027126 for <[e-mail]>; Fri, 4 Apr 2003 00:22:51 +0200 (MEST)
Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h33MMpXH027125 for ietf-provreg-outgoing; Fri, 4 Apr 2003 00:22:51 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from mail.libertyrms.com ([209.167.124.227]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h33MMnRN027120 for <[e-mail]>; Fri, 4 Apr 2003 00:22:50 +0200 (MEST)
Received: from dev3.int.libertyrms.com ([10.1.2.204] helo=libertyrms.info) by mail.libertyrms.com with esmtp (Exim 3.22 #3 (Debian)) id 191D6f-0006Oe-00; Thu, 03 Apr 2003 17:22:49 -0500
Message-ID: <[e-mail]>
Date: Thu, 03 Apr 2003 17:23:01 -0500
From: janusz sienkiewicz <[e-mail]>
Organization: LibertyRMS Co.
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-3custom i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Edmon Chung <[e-mail]>
CC: [e-mail]
Subject: Re: [ietf-provreg] pendingCreate should allow domain update
References: <013701c2f8bf$56bc7af0$[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Allowing domain updates on pendingCreate looks like a registry specific policy.
Usually a request results in pendingCreate status because some manual or
external processing is required. In many cases it may not be even feasible for
a registry to modify the process because I of update. If update of a domain in
pendingCreate state is really necessary such case should be handled within epp
extensions.

Janusz Sienkiewicz

Edmon Chung wrote:

> Hi,
>
> Currently, the EPP doc defines that on pendingCreate, no domain updates are
> allowed.  This poses a chicken and egg problem: for example many times, upon
> a pendingCreate the registry may require the registrant to change the admin
> contact for local presence requirements.  If the registrant is not able to
> update the domain, then the domain cannot be approved...
>
> Thoughts?
>
> Edmon



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h33KvQRN026170 for <[e-mail]>; Thu, 3 Apr 2003 22:57:26 +0200 (MEST)
Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h33KvQc5026169 for ietf-provreg-outgoing; Thu, 3 Apr 2003 22:57:26 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h33KvORN026164 for <[e-mail]>; Thu, 3 Apr 2003 22:57:25 +0200 (MEST)
Received: from [192.136.136.80] ([192.136.136.80]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id PAA09411; Thu, 3 Apr 2003 15:57:12 -0500 (EST)
Mime-Version: 1.0
X-Sender: edlewis@ops
Message-Id: <a05111b02bab24da6fb58@[192.136.136.80]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Thu, 3 Apr 2003 15:56:15 -0500
To: Joseph Reagle <[e-mail]>
From: Edward Lewis <[e-mail]>
Subject: Re: [ietf-provreg] [BH] P3P and Extensible Provisioning Protocol
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk

In a nutshell...

(I'm one of the co-chairs of the WG, Jaap Akkerhuis is the other, but 
I am not an implementor of the protocol.)

Please note that I took "[e-mail]" off the cc list - to 
avoid cross-posting and I'm not on that list.  If anyone wants to 
forward this message to that list, you have my permission.

At 18:20 -0500 4/2/03, Joseph Reagle wrote:

>1. Did you find anything particularly troublesome with adapting P3P to your
>context from a protocol/binding position? (I assume not, you just include
>P3P in your XML.) Do you have any scenarios where your XML application
>would also be transported over HTTP, which itself could conceivable have a
>P3P policy? (Or is this an unlikely scenario?)

Not that I am aware of - trouble with adapting P3P, that is.

On HTTP - one of the items in our charter has been to investigate 
"other transports" with "other" meaning "not TCP" in the context. 
But to date, there's been no sustained interest in pursuing any 
transport other than TCP (with TLS) but multiple members of the WG. 
It's not so much that HTTP was rejected, no one suggested doing it.

>2. What led you to make the changes to the vocabulary that you did? (Some
>terms are removed, some are altered -- we're these casual changes or did
>you have significant market/policy tensions in your app context?)

To some extent because our protocol is "business to business" and 
constrained in it's reach, as opposed to being "person to business" 
and in general use.

>3. Your XML app does use schema, did you give any thought to actually using
>elements from the P3P namespace and if so, what discouraged that?

I'd have to research that.

>4. Do you have any other feedback that I've missed? <smile/>

None, other than to say that I thought the P3P specification is well 
written and organized, especially from the perspective of someone who 
has written specifications in the past.  I like having the 
requirement clearly stated and then use prose to convey the spirit.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            [phone]
ARIN Research Engineer

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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h33HvLRN023718 for <[e-mail]>; Thu, 3 Apr 2003 19:57:21 +0200 (MEST)
Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h33HvLIX023717 for ietf-provreg-outgoing; Thu, 3 Apr 2003 19:57:21 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from mail.libertyrms.com ([209.167.124.227]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h33HvJRN023710 for <[e-mail]>; Thu, 3 Apr 2003 19:57:19 +0200 (MEST)
Received: from dev7.int.libertyrms.com ([10.1.2.225] helo=libertyrms.info) by mail.libertyrms.com with esmtp (Exim 3.22 #3 (Debian)) id 1918xi-0001cX-00 for <[e-mail]>; Thu, 03 Apr 2003 12:57:18 -0500
Message-ID: <[e-mail]>
Date: Thu, 03 Apr 2003 13:13:13 -0500
From: Daniel Manley <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.3b) Gecko/20030212
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: [ietf-provreg] pendingCreate should allow domain update
References: <[e-mail]> <028701c2f97d$cf05b080$[e-mail]>
In-Reply-To: <028701c2f97d$cf05b080$[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

I can see an application of your point Edmon.  What if the pendingCreate 
thing is rejected?  Is the object deleted and the registrar notified 
through a PAN?  This would leave the object open for creation from 
another registrant (at the same registrar or a different one).  Is that 
fair (maybe it is, maybe it isn't)?  If the answer is always to approve 
it with then a serverHold status, doesn't that defeat the purpose of 
"pendingCreate"?

Dan

Edmon Chung wrote:

>----- Original Message ----- 
>From: "Hollenbeck, Scott" <[e-mail]>
>  
>
>>2. Approve the request and require an update (using a status like
>>serverHold) before you allow the domain to go "active".
>>    
>>
>
>This is a good suggestion I suppose.
>
>Edmon
>
>  
>




Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h339jIRN018395 for <[e-mail]>; Thu, 3 Apr 2003 11:45:18 +0200 (MEST)
Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h339jInJ018394 for ietf-provreg-outgoing; Thu, 3 Apr 2003 11:45:18 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from bartok.sidn.nl (bartok.sidn.nl [193.176.144.164]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h339jHRN018389 for <[e-mail]>; Thu, 3 Apr 2003 11:45:18 +0200 (MEST)
Received: from bartok.sidn.nl (localhost.sidn.nl [IPv6:::1]) by bartok.sidn.nl (8.12.9/8.12.9) with ESMTP id h339jHZ8018461 for <[e-mail]>; Thu, 3 Apr 2003 11:45:17 +0200 (CEST) (envelope-from [e-mail])
Received: (from jaap@localhost) by bartok.sidn.nl (8.12.9/8.12.6/Submit) id h339jHww018460 for [e-mail]; Thu, 3 Apr 2003 11:45:17 +0200 (CEST)
Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h32NL0RN011582 for <[e-mail]>; Thu, 3 Apr 2003 01:21:00 +0200 (MEST)
Received: from localhost (IDENT:[e-mail] [18.29.0.27]) by tux.w3.org (8.12.9/8.12.9) with ESMTP id h32NKxsi026301; Wed, 2 Apr 2003 18:20:59 -0500
From: Joseph Reagle <[e-mail]>
Organization: W3C
To: [e-mail]
Subject: [ietf-provreg] [BH] P3P and Extensible Provisioning Protocol
Date: Wed, 2 Apr 2003 18:20:59 -0500
User-Agent: KMail/1.5.1
Cc: [e-mail], [e-mail]
MIME-Version: 1.0
Content-Disposition: inline
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Scott (and the PRP WG), 

I'm chairing a "Beyond HTTP" taskforce of the W3C P3P Activity looking to 
other applications and protocols for an understanding of their requirements 
for *reusing* P3P. We've noted [2] your use of P3P and I hope you wouldn't 
mind giving us some feedback so we can help others in your context re-use 
as much as possible of P3P -- mitigating and confusing divergences.

1. Did you find anything particularly troublesome with adapting P3P to your 
context from a protocol/binding position? (I assume not, you just include 
P3P in your XML.) Do you have any scenarios where your XML application 
would also be transported over HTTP, which itself could conceivable have a 
P3P policy? (Or is this an unlikely scenario?)
2. What led you to make the changes to the vocabulary that you did? (Some 
terms are removed, some are altered -- we're these casual changes or did 
you have significant market/policy tensions in your app context?) 
3. Your XML app does use schema, did you give any thought to actually using 
elements from the P3P namespace and if so, what discouraged that?
4. Do you have any other feedback that I've missed? <smile/>

[1] http://www.w3.org/P3P/2003/04-beyond-http.html
[2] http://lists.w3.org/Archives/Public/public-p3p-spec/2003Mar/0008.html

-- 
Joseph Reagle Jr.                 http://www.w3.org/People/Reagle/
W3C Policy Analyst                mailto:[e-mail]
IETF/W3C XML-Signature Co-Chair   http://www.w3.org/Signature/
W3C XML Encryption Chair          http://www.w3.org/Encryption/2001/



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h339iuRN018387 for <[e-mail]>; Thu, 3 Apr 2003 11:44:57 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h339iuLY018386 for ietf-provreg-outgoing; Thu, 3 Apr 2003 11:44:56 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from bartok.sidn.nl (bartok.sidn.nl [193.176.144.164]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h339itRN018381 for <[e-mail]>; Thu, 3 Apr 2003 11:44:56 +0200 (MEST)
Received: from bartok.sidn.nl (localhost.sidn.nl [IPv6:::1]) by bartok.sidn.nl (8.12.9/8.12.9) with ESMTP id h339irZ8018448 for <[e-mail]>; Thu, 3 Apr 2003 11:44:53 +0200 (CEST) (envelope-from [e-mail])
Received: (from jaap@localhost) by bartok.sidn.nl (8.12.9/8.12.6/Submit) id h339ir2m018447 for [e-mail]; Thu, 3 Apr 2003 11:44:53 +0200 (CEST)
Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h32NKNRN011561 for <[e-mail]>; Thu, 3 Apr 2003 01:20:23 +0200 (MEST)
Received: from localhost (IDENT:[e-mail] [18.29.0.27]) by tux.w3.org (8.12.9/8.12.9) with ESMTP id h32NKMsi026133; Wed, 2 Apr 2003 18:20:22 -0500
From: Joseph Reagle <[e-mail]>
Organization: W3C
To: [e-mail]
Subject: [ietf-provreg] [BH] P3P and Extensible Provisioning Protocol   
Date: Wed, 2 Apr 2003 18:20:21 -0500
User-Agent: KMail/1.5.1
Cc: [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Scott (and the PRP WG), 

I'm chairing a "Beyond HTTP" taskforce of the W3C P3P Activity looking to 
other applications and protocols for an understanding of their requirements 
for *reusing* P3P. We've noted [2] your use of P3P and I hope you wouldn't 
mind giving us some feedback so we can help others in your context re-use 
as much as possible of P3P -- mitigating and confusing divergences.

1. Did you find anything particularly troublesome with adapting P3P to your 
context from a protocol/binding position? (I assume not, you just include 
P3P in your XML.) Do you have any scenarios where your XML application 
would also be transported over HTTP, which itself could conceivable have a 
P3P policy? (Or is this an unlikely scenario?)
2. What led you to make the changes to the vocabulary that you did? (Some 
terms are removed, some are altered -- we're these casual changes or did 
you have significant market/policy tensions in your app context?) 
3. Your XML app does use schema, did you give any thought to actually using 
elements from the P3P namespace and if so, what discouraged that?
4. Do you have any other feedback that I've missed? <smile/>

[1] http://www.w3.org/P3P/2003/04-beyond-http.html
[2] http://lists.w3.org/Archives/Public/public-p3p-spec/2003Mar/0008.html

-- 
Joseph Reagle Jr.                 http://www.w3.org/People/Reagle/
W3C Policy Analyst                mailto:[e-mail]
IETF/W3C XML-Signature Co-Chair   http://www.w3.org/Signature/
W3C XML Encryption Chair          http://www.w3.org/Encryption/2001/



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h331DbRN013114 for <[e-mail]>; Thu, 3 Apr 2003 03:13:37 +0200 (MEST)
Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h331DbPF013113 for ietf-provreg-outgoing; Thu, 3 Apr 2003 03:13:37 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from neteka.com (www.namesbeyond.com [216.220.34.103]) by nic.cafax.se (8.12.9/8.12.9) with SMTP id h331DZRN013108 for <[e-mail]>; Thu, 3 Apr 2003 03:13:36 +0200 (MEST)
Message-ID: <028701c2f97d$cf05b080$[e-mail]>
From: "Edmon Chung" <[e-mail]>
To: "Hollenbeck, Scott" <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: [ietf-provreg] pendingCreate should allow domain update
Date: Wed, 2 Apr 2003 20:10:21 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk

----- Original Message ----- 
From: "Hollenbeck, Scott" <[e-mail]>
> 2. Approve the request and require an update (using a status like
> serverHold) before you allow the domain to go "active".

This is a good suggestion I suppose.

Edmon



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h32Ho1RN007013 for <[e-mail]>; Wed, 2 Apr 2003 19:50:01 +0200 (MEST)
Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h32Ho1ST007012 for ietf-provreg-outgoing; Wed, 2 Apr 2003 19:50:01 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from bartok.sidn.nl (bartok.sidn.nl [193.176.144.164]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h32HnxRN007004 for <[e-mail]>; Wed, 2 Apr 2003 19:49:59 +0200 (MEST)
Received: from bartok.sidn.nl (localhost.sidn.nl [IPv6:::1]) by bartok.sidn.nl (8.12.9/8.12.9) with ESMTP id h32HnwZ8015812 for <[e-mail]>; Wed, 2 Apr 2003 19:49:58 +0200 (CEST) (envelope-from [e-mail])
Received: (from jaap@localhost) by bartok.sidn.nl (8.12.9/8.12.6/Submit) id h32Hnwlw015811 for [e-mail]; Wed, 2 Apr 2003 19:49:58 +0200 (CEST)
Received: from ran.psg.com (ip166.usw12.rb1.bel.nwlink.com [209.20.253.166]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h32HDjRN006484 for <[e-mail]>; Wed, 2 Apr 2003 19:13:46 +0200 (MEST)
Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.12) id 190lnv-0003zC-00; Wed, 02 Apr 2003 09:13:39 -0800
From: Randy Bush <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: Wed, 2 Apr 2003 09:13:39 -0800
To: Edward Lewis <[e-mail]>
Cc: [e-mail]
Subject: Re: [ietf-provreg] the privacy problem statement
References: <[e-mail]> <a05111b09bab0bd532767@[192.149.252.108]> <[e-mail]> <a05111b0abab0c79e598f@[192.149.252.108]>
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

> In the 'official' comment, you mentioned 'domain.'   Is there 
> specific data you had in mind when writing the comment?

i meant the org data may have sensitive fields.  e.g., for an
extreme example, i am aware of domains where the org is vulnerable
to real-world attack, and hence wishes to hide its identity from
all but legitimate queries to do with domain maintenance.

i did not mean that i thought it reasonable to hide the
nameservers.

hope this helps.

randy



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h32HfMRN006908 for <[e-mail]>; Wed, 2 Apr 2003 19:41:22 +0200 (MEST)
Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h32HfM1q006907 for ietf-provreg-outgoing; Wed, 2 Apr 2003 19:41:22 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.237.102]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h32HfKRN006902 for <[e-mail]>; Wed, 2 Apr 2003 19:41:20 +0200 (MEST)
Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [10.170.12.38]) by heron.verisign.com (8.12.8/8.12.8) with ESMTP id h32HeN2P000764; Wed, 2 Apr 2003 12:40:23 -0500 (EST)
Received: by vsvapostalgw1.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <2DXNSKM7>; Wed, 2 Apr 2003 12:39:02 -0500
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Edward Lewis'" <[e-mail]>
Cc: [e-mail]
Subject: RE: [ietf-provreg] the privacy problem statement
Date: Wed, 2 Apr 2003 12:39:01 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

> At 7:38 -0500 4/1/03, Hollenbeck, Scott wrote:
> >Absent anything that resembles social data (as described in RFC 3375)
> >outside the contact mapping, I'm working with a definition 
> of social data
> >that only applies to elements present in the contact mapping.
> 
> In the IESG comment, "why do domain/contact/.. not have granular 
> information about privacy?" domains are mentioned too.

I know -- and I thought we got past that in San Francisco.

-Scott-


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h32HPKRN006679 for <[e-mail]>; Wed, 2 Apr 2003 19:25:20 +0200 (MEST)
Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h32HPKx7006678 for ietf-provreg-outgoing; Wed, 2 Apr 2003 19:25:20 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from arachne.lendl.priv.at (vianet-ispa-gw01.via.at [194.96.143.146] (may be forged)) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h32HPIRN006673 for <[e-mail]>; Wed, 2 Apr 2003 19:25:19 +0200 (MEST)
Received: from lendl by arachne.lendl.priv.at with local (Exim 3.36 #1 (Debian)) id 190lzC-00086T-00 for <[e-mail]>; Wed, 02 Apr 2003 19:25:18 +0200
Date: Wed, 2 Apr 2003 19:25:18 +0200
From: Otmar Lendl <[e-mail]>
To: [e-mail]
Subject: [ietf-provreg] Version 1.0 of mod_epp released.
Message-ID: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.3i
Sender: [e-mail]
Precedence: bulk

What is it?
----------

mod_epp is an Apache 2.0 module that implements the EPP over TCP
protocol as defined in draft-ietf-provreg-epp-tcp-06.txt and the session
management parts of draft-ietf-provreg-epp-0(6|7|8).txt.

This is not a full implementation of EPP; this module just makes it
possible to write an EPP server as a set of CGI scripts.
It can also be used in a reverse proxy setup to hand off the
EPP processing to a HTTP-based backend.


Where to get it?
----------------

The project homepage ist at http://sourceforge.net/projects/aepps/
The 1.0 tarball is at
http://freshmeat.net/redir/mod_epp/38699/url_tgz/mod_epp-1.0.tar.gz?download

My PowerPoint presentation from the Centr meeting at RIPE44 covering the 
design and basic configuration is still at
http://prdownloads.sourceforge.net/aepps/mod_epp-ripe44.ppt?download


Changes
-------

* I'm sufficently happy with the code to call it 1.0
* LICENSE (apache style for real now)
* Cookie support
* Rewrite of bucket handling
* Some SSL fixes (but be aware of
* http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18339)
* Error handling improvements
* Apache scoreboard works now



I hope someone here has some use for this code.

Share and Enjoy!

/ol
-- 
Otmar Lendl <[e-mail]>


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h32H59RN006341 for <[e-mail]>; Wed, 2 Apr 2003 19:05:09 +0200 (MEST)
Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h32H59Yr006340 for ietf-provreg-outgoing; Wed, 2 Apr 2003 19:05:09 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h32H57RN006335 for <[e-mail]>; Wed, 2 Apr 2003 19:05:07 +0200 (MEST)
Received: from [192.149.252.108] ([192.136.136.30]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id MAA09777; Wed, 2 Apr 2003 12:03:46 -0500 (EST)
Mime-Version: 1.0
X-Sender: edlewis@ops
Message-Id: <a05111b0abab0c79e598f@[192.149.252.108]>
In-Reply-To: <[e-mail]>
References:  <[e-mail]> <a05111b09bab0bd532767@[192.149.252.108]> <[e-mail]>
Date: Wed, 2 Apr 2003 12:03:17 -0500
To: [e-mail]
From: Edward Lewis <[e-mail]>
Subject: Re: [ietf-provreg] the privacy problem statement
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk

Randy,

While the group is preparing to address the comment below, this 
statement was made.  I think we need a little more clarification 
(hopefully not much) from you on this.

In the 'official' comment, you mentioned 'domain.'   Is there 
specific data you had in mind when writing the comment?

At 11:43 -0500 4/2/03, janusz sienkiewicz wrote:
>Edward Lewis wrote:
>
>>  At 7:38 -0500 4/1/03, Hollenbeck, Scott wrote:
>>  >Absent anything that resembles social data (as described in RFC 3375)
>>  >outside the contact mapping, I'm working with a definition of social data
>>  >that only applies to elements present in the contact mapping.
>>
>>  In the IESG comment, "why do domain/contact/.. not have granular
>>  information about privacy?" domains are mentioned too.
>>
>
>Domains don't have any social data (<domain:registrant>, <domain:contact> are
>just references to social data owned and maintained by registrars). That's
>why domains should not be within the scope of any privacy mechanism.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            [phone]
ARIN Research Engineer

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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h32GnHRN006170 for <[e-mail]>; Wed, 2 Apr 2003 18:49:17 +0200 (MEST)
Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h32GnHRW006169 for ietf-provreg-outgoing; Wed, 2 Apr 2003 18:49:17 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from mail.libertyrms.com ([209.167.124.227]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h32GnDRN006164 for <[e-mail]>; Wed, 2 Apr 2003 18:49:15 +0200 (MEST)
Received: from dev3.int.libertyrms.com ([10.1.2.204] helo=libertyrms.info) by mail.libertyrms.com with esmtp (Exim 3.22 #3 (Debian)) id 190lL1-0004fH-00; Wed, 02 Apr 2003 11:43:47 -0500
Message-ID: <[e-mail]>
Date: Wed, 02 Apr 2003 11:43:56 -0500
From: janusz sienkiewicz <[e-mail]>
Organization: LibertyRMS Co.
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-3custom i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Edward Lewis <[e-mail]>
CC: "Hollenbeck, Scott" <[e-mail]>, "'George Michaelson'" <[e-mail]>, [e-mail]
Subject: Re: [ietf-provreg] the privacy problem statement
References: <[e-mail]> <a05111b09bab0bd532767@[192.149.252.108]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Edward Lewis wrote:

> At 7:38 -0500 4/1/03, Hollenbeck, Scott wrote:
> >Absent anything that resembles social data (as described in RFC 3375)
> >outside the contact mapping, I'm working with a definition of social data
> >that only applies to elements present in the contact mapping.
>
> In the IESG comment, "why do domain/contact/.. not have granular
> information about privacy?" domains are mentioned too.
>

Domains don't have any social data (<domain:registrant>, <domain:contact> are
just references to social data owned and maintained by registrars). That's
why domains should not be within the scope of any privacy mechanism.


>
> --
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Edward Lewis                                            [phone]
> ARIN Research Engineer
>
> I've had it with world domination.  The maintenance fees are too high.

Janusz Sienkiewicz




Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h32GLhRN005729 for <[e-mail]>; Wed, 2 Apr 2003 18:21:43 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h32GLhJr005728 for ietf-provreg-outgoing; Wed, 2 Apr 2003 18:21:43 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h32GLXRN005720 for <[e-mail]>; Wed, 2 Apr 2003 18:21:37 +0200 (MEST)
Received: from [192.149.252.108] ([192.136.136.52]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id LAA01777; Wed, 2 Apr 2003 11:21:14 -0500 (EST)
Mime-Version: 1.0
X-Sender: edlewis@ops
Message-Id: <a05111b09bab0bd532767@[192.149.252.108]>
In-Reply-To:  <[e-mail]>
References:  <[e-mail]>
Date: Wed, 2 Apr 2003 11:20:50 -0500
To: "Hollenbeck, Scott" <[e-mail]>
From: Edward Lewis <[e-mail]>
Subject: RE: [ietf-provreg] the privacy problem statement
Cc: "'George Michaelson'" <[e-mail]>, [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk

At 7:38 -0500 4/1/03, Hollenbeck, Scott wrote:
>Absent anything that resembles social data (as described in RFC 3375)
>outside the contact mapping, I'm working with a definition of social data
>that only applies to elements present in the contact mapping.

In the IESG comment, "why do domain/contact/.. not have granular 
information about privacy?" domains are mentioned too.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            [phone]
ARIN Research Engineer

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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h32GLLRN005716 for <[e-mail]>; Wed, 2 Apr 2003 18:21:21 +0200 (MEST)
Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h32GLLta005714 for ietf-provreg-outgoing; Wed, 2 Apr 2003 18:21:21 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h32GLJRN005709 for <[e-mail]>; Wed, 2 Apr 2003 18:21:19 +0200 (MEST)
Received: from [192.149.252.108] ([192.136.136.52]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id LAA01761; Wed, 2 Apr 2003 11:21:09 -0500 (EST)
Mime-Version: 1.0
X-Sender: edlewis@ops
Message-Id: <a05111b08bab0bcd80a9e@[192.149.252.108]>
In-Reply-To:  <[e-mail]>
References:  <[e-mail]>
Date: Wed, 2 Apr 2003 11:15:35 -0500
To: "Hollenbeck, Scott" <[e-mail]>
From: Edward Lewis <[e-mail]>
Subject: RE: [ietf-provreg] References for Today's Host Object Discussion
Cc: "'Edward Lewis'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk

To those who are asking for this, please comment...either to the 
list, or you can send something to the chairs (Jaap and I).

At 8:17 -0500 3/31/03, Hollenbeck, Scott wrote:
>Sure.  Here's what I have in mind:

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            [phone]
ARIN Research Engineer

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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h32FwORN005431 for <[e-mail]>; Wed, 2 Apr 2003 17:58:24 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h32FwO3T005430 for ietf-provreg-outgoing; Wed, 2 Apr 2003 17:58:24 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h32FwMRN005425 for <[e-mail]>; Wed, 2 Apr 2003 17:58:22 +0200 (MEST)
Received: from [192.149.252.108] ([192.136.136.52]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id KAA27517; Wed, 2 Apr 2003 10:58:06 -0500 (EST)
Mime-Version: 1.0
X-Sender: edlewis@ops
Message-Id: <a05111b07bab0b44507f6@[192.149.252.108]>
In-Reply-To: <080301c2f874$d9edcb90$[e-mail]>
References: <[e-mail]> <080301c2f874$d9edcb90$[e-mail]>
Date: Wed, 2 Apr 2003 10:57:14 -0500
To: "Ram Mohan" <[e-mail]>
From: Edward Lewis <[e-mail]>
Subject: Re: side bar, was Re: [ietf-provreg] Our "Privacy Issue"
Cc: "Edmon Chung" <[e-mail]>, "Jaap Akkerhuis" <[e-mail]>, "Asbjorn Mikkelsen" <[e-mail]>, <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk

At 12:20 -0500 4/1/03, Ram Mohan wrote:
>reality is that EPP has taken off and no-one is waiting for the RFC to
>implement - we have much more than just prototypes :)

Great news.  This is the way it is supposed to work.  Running code 
and all that...but now we want to make sure the running code bases 
interoperate.

As the chair I would encourage those who have taken the time to write 
code and deploy to speak out about their experiences, operational 
considerations, and what they feel about the specification.  That's 
what the WG is here for.

My statement should not be taken in the context of reprimanding any 
effort for not doing so - but rather an encouragement for those who 
have not so far.  The documents that Scott is editing are reflections 
of the discussion on this mailing list (and not what is done face to 
face, nor what he feels like saying), so, please speak up.

But you say that we are too far towards RFC'ing the current drafts? 
Well, that's because we can't wait for folks to voice opinions.  Keep 
in mind that becoming an RFC means (in IETF speak), it means, well, 
not much!  The documents will be coming out as Proposed Standard (if 
and when), which is the first rung on the standards ladder. 
Standards have "re-cycled" at Proposed, eventually progressing to 
Draft and then, in rare instances, to Full.

It's never too late to comment.

Also - even if this WG closes down after the current set of documents 
reach PS, this mail list will stay open (perhaps moving servers if 
the current hosts wish) for continuing discussion.  At some time in 
the future, when it is thought that the specs are ready for DS, a new 
group will be convened to make that happen.

So, it's never too late to comment.

Where I expect to see comments arise in the future is when a 
registrar tries to register names in, say, .nl, .sg, and .info. 
That'll be when interoperability is put to the test.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            [phone]
ARIN Research Engineer

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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h32COWRN003141 for <[e-mail]>; Wed, 2 Apr 2003 14:24:32 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h32COVXh003140 for ietf-provreg-outgoing; Wed, 2 Apr 2003 14:24:31 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.237.102]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h32COURN003135 for <[e-mail]>; Wed, 2 Apr 2003 14:24:31 +0200 (MEST)
Received: from vsvapostalgw3.prod.netsol.com (vsvapostalgw3.prod.netsol.com [10.170.12.61]) by heron.verisign.com (8.12.8/8.12.8) with ESMTP id h32CPo2P017842; Wed, 2 Apr 2003 07:25:50 -0500 (EST)
Received: by vsvapostalgw3.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <2DYC91ZW>; Wed, 2 Apr 2003 07:24:28 -0500
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Edmon Chung'" <[e-mail]>, [e-mail]
Subject: RE: [ietf-provreg] pendingCreate should allow domain update
Date: Wed, 2 Apr 2003 07:24:26 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

> Currently, the EPP doc defines that on pendingCreate, no 
> domain updates are
> allowed.  This poses a chicken and egg problem: for example 
> many times, upon
> a pendingCreate the registry may require the registrant to 
> change the admin
> contact for local presence requirements.  If the registrant 
> is not able to
> update the domain, then the domain cannot be approved...

Why not require the registrant to provide correct information in the first
place?

Making changes after a request has been submitted seems like a bad idea to
me.  You're suggesting that once the evaluation starts it should be OK to
change the data being evaluated.  This isn't a "chicken and egg" problem,
it's a "get your ducks in a row before you apply" issue.  If something is
found to be in error you can always:

1. Reject the request because it can't be approved as submitted.

2. Approve the request and require an update (using a status like
serverHold) before you allow the domain to go "active".

My feeling is that an atomic request to create something should be static.
Once you get into allowing updates after a request is submitted it becomes
more difficult to track what's being requested.

-Scott-


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h32C9qRN002969 for <[e-mail]>; Wed, 2 Apr 2003 14:09:52 +0200 (MEST)
Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h32C9qlc002968 for ietf-provreg-outgoing; Wed, 2 Apr 2003 14:09:52 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.237.102]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h32C9oRN002963 for <[e-mail]>; Wed, 2 Apr 2003 14:09:51 +0200 (MEST)
Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [10.170.12.38]) by heron.verisign.com (8.12.8/8.12.8) with ESMTP id h32CBA2P017556; Wed, 2 Apr 2003 07:11:10 -0500 (EST)
Received: by vsvapostalgw1.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <2DXNSA0P>; Wed, 2 Apr 2003 07:09:49 -0500
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Edmon Chung'" <[e-mail]>
Cc: [e-mail]
Subject: RE: [ietf-provreg] the privacy problem statement
Date: Wed, 2 Apr 2003 07:09:47 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="UTF-8"
Sender: [e-mail]
Precedence: bulk

> I dont think a privacy profile for contact objects only is 
> much useful...
> 
> The most prominent example is that a registry might mandate 
> that the Admin
> contact Address be displayed while other contacts may have 
> them hidden.  If
> a contact is the Admin contact of one domain and a billing contact for
> another, and the contact object was created when s/he needed 
> to be an Admin
> contact, then s/he will be forced to also disclose his/her 
> address for the
> other domains that s/he is associated with.
> 
> I think privacy profile for domain mapping is as important... 
> if not more
> important

I'm not talking about privacy profiles.  My regurgitated proposal was
limited to the simple mechanism required to get the documents past the IESG.
Additional privacy syntax and semantics can (and should) be addressed in an
extension.

-Scott-


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h324nERN029886 for <[e-mail]>; Wed, 2 Apr 2003 06:49:14 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h324nE6T029885 for ietf-provreg-outgoing; Wed, 2 Apr 2003 06:49:14 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from neteka.com (www.namesbeyond.com [216.220.34.103]) by nic.cafax.se (8.12.9/8.12.9) with SMTP id h324nCRN029880 for <[e-mail]>; Wed, 2 Apr 2003 06:49:13 +0200 (MEST)
Message-ID: <016101c2f8d3$2c4766e0$[e-mail]>
From: "Edmon Chung" <[e-mail]>
To: "Rick Wesson" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]>
Subject: Re: [ietf-provreg] pendingCreate should allow domain update
Date: Tue, 1 Apr 2003 23:48:53 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk

But the issue is that the contact might need to be replaced.
Another issue is that some registries require name servers to be properly
setup before domain creation is approved.  And it may be necessary to
replace or add name servers.
Edmon


----- Original Message -----
From: "Rick Wesson" <[e-mail]>
To: "Edmon Chung" <[e-mail]>
Cc: <[e-mail]>
Sent: Tuesday, April 01, 2003 10:18 PM
Subject: Re: [ietf-provreg] pendingCreate should allow domain update


> On Tue, 1 Apr 2003, Edmon Chung wrote:
>
> > Hi,
> >
> > Currently, the EPP doc defines that on pendingCreate, no domain updates
are
> > allowed.  This poses a chicken and egg problem: for example many times,
upon
> > a pendingCreate the registry may require the registrant to change the
admin
> > contact for local presence requirements.  If the registrant is not able
to
> > update the domain, then the domain cannot be approved...
>
> If it is the contact that needs to be updated, then you don't have to
> update the association between the domain and the contact. If the contact
> has a pendingCreate then you have a problem.
>
> -rick
>
>
>



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h323ItRN029196 for <[e-mail]>; Wed, 2 Apr 2003 05:18:55 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h323ItI5029195 for ietf-provreg-outgoing; Wed, 2 Apr 2003 05:18:55 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from bean.ar.com (bean.ar.com [66.123.187.68]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h323IsRN029190 for <[e-mail]>; Wed, 2 Apr 2003 05:18:54 +0200 (MEST)
Received: from flash.ar.com (wessorh@flash [66.123.187.80]) by bean.ar.com (8.12.6/8.12.6) with ESMTP id h323IsgN027987; Tue, 1 Apr 2003 19:18:54 -0800 (PST)
Date: Tue, 1 Apr 2003 19:18:52 -0800 (PST)
From: Rick Wesson <[e-mail]>
To: Edmon Chung <[e-mail]>
cc: <[e-mail]>
Subject: Re: [ietf-provreg] pendingCreate should allow domain update
In-Reply-To: <013701c2f8bf$56bc7af0$[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

On Tue, 1 Apr 2003, Edmon Chung wrote:

> Hi,
>
> Currently, the EPP doc defines that on pendingCreate, no domain updates are
> allowed.  This poses a chicken and egg problem: for example many times, upon
> a pendingCreate the registry may require the registrant to change the admin
> contact for local presence requirements.  If the registrant is not able to
> update the domain, then the domain cannot be approved...

If it is the contact that needs to be updated, then you don't have to
update the association between the domain and the contact. If the contact
has a pendingCreate then you have a problem.

-rick




Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h322R8RN028821 for <[e-mail]>; Wed, 2 Apr 2003 04:27:08 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h322R8oF028820 for ietf-provreg-outgoing; Wed, 2 Apr 2003 04:27:08 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from neteka.com (www.namesbeyond.com [216.220.34.103]) by nic.cafax.se (8.12.9/8.12.9) with SMTP id h322R6RN028815 for <[e-mail]>; Wed, 2 Apr 2003 04:27:07 +0200 (MEST)
Message-ID: <013701c2f8bf$56bc7af0$[e-mail]>
From: "Edmon Chung" <[e-mail]>
To: <[e-mail]>
Subject: [ietf-provreg] pendingCreate should allow domain update
Date: Tue, 1 Apr 2003 21:26:55 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk

Hi,

Currently, the EPP doc defines that on pendingCreate, no domain updates are
allowed.  This poses a chicken and egg problem: for example many times, upon
a pendingCreate the registry may require the registrant to change the admin
contact for local presence requirements.  If the registrant is not able to
update the domain, then the domain cannot be approved...

Thoughts?

Edmon



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h321eFRN028477 for <[e-mail]>; Wed, 2 Apr 2003 03:40:15 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h321eF0q028476 for ietf-provreg-outgoing; Wed, 2 Apr 2003 03:40:15 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from neteka.com (www.namesbeyond.com [216.220.34.103]) by nic.cafax.se (8.12.9/8.12.9) with SMTP id h321eDRN028471 for <[e-mail]>; Wed, 2 Apr 2003 03:40:14 +0200 (MEST)
Message-ID: <010a01c2f8b8$c2254ad0$[e-mail]>
From: "Edmon Chung" <[e-mail]>
To: "Hollenbeck, Scott" <[e-mail]>, "'George Michaelson'" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]>
Subject: Re: [ietf-provreg] the privacy problem statement
Date: Tue, 1 Apr 2003 20:39:48 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk

I dont think a privacy profile for contact objects only is much useful...

The most prominent example is that a registry might mandate that the Admin
contact Address be displayed while other contacts may have them hidden.  If
a contact is the Admin contact of one domain and a billing contact for
another, and the contact object was created when s/he needed to be an Admin
contact, then s/he will be forced to also disclose his/her address for the
other domains that s/he is associated with.

I think privacy profile for domain mapping is as important... if not more
important

Edmon




----- Original Message -----
From: "Hollenbeck, Scott" <[e-mail]>
To: "'George Michaelson'" <[e-mail]>
Cc: <[e-mail]>
Sent: Tuesday, April 01, 2003 7:38 AM
Subject: RE: [ietf-provreg] the privacy problem statement


> > > If I remember correctly the feeling of the room in San
> > Francisco was that
> > > 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.
>
> Absent anything that resembles social data (as described in RFC 3375)
> outside the contact mapping, I'm working with a definition of social data
> that only applies to elements present in the contact mapping.
>
> -Scott-
>



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h31HY5RN023244 for <[e-mail]>; Tue, 1 Apr 2003 19:34:05 +0200 (MEST)
Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h31HY4iA023243 for ietf-provreg-outgoing; Tue, 1 Apr 2003 19:34:04 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from ns01.afilias.info (ns01.afilias.info [66.45.25.225]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h31HY1RN023238 for <[e-mail]>; Tue, 1 Apr 2003 19:34:01 +0200 (MEST)
Received: from eagle (ismtp.afilias.com [216.217.55.254]) (authenticated) by ns01.afilias.info (8.11.6/8.11.6) with ESMTP id h31HXnW30874; Tue, 1 Apr 2003 12:33:49 -0500
Message-ID: <080301c2f874$d9edcb90$[e-mail]>
From: "Ram Mohan" <[e-mail]>
To: "Edmon Chung" <[e-mail]>, "Jaap Akkerhuis" <[e-mail]>
Cc: "Asbjorn Mikkelsen" <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: side bar, was Re: [ietf-provreg] Our "Privacy Issue" 
Date: Tue, 1 Apr 2003 12:20:16 -0500
Organization: Afilias
MIME-Version: 1.0
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk

agreed, under IETF "Correct " rules.

reality is that EPP has taken off and no-one is waiting for the RFC to
implement - we have much more than just prototypes :)

-ram
----- Original Message -----
From: "Jaap Akkerhuis" <[e-mail]>
To: "Edmon Chung" <[e-mail]>
Cc: "Asbjorn Mikkelsen" <[e-mail]>; "Ram Mohan"
<[e-mail]>; <[e-mail]>
Sent: Tuesday, April 01, 2003 5:42 AM
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)
>
> To be (IETF) polical correct, the last time I checked, there was no
> EPP at all. Note that the IETF discourages the use of dratfs in any
> form. See attached scitation from RFC 2026. So, at best one can
> talk about "by the IETF provreg-WG insprired" protocol.
>
> And for good order, .NL is not using anything which remotely
> looks like EPP.
>
> jaap
>
> RFC 2026, section 2.6
>
>    An Internet-Draft is NOT a means of "publishing" a specification;
>    specifications are published through the RFC mechanism described in
>    the previous section.  Internet-Drafts have no formal status, and are
>    subject to change or removal at any time.
>
>       ********************************************************
>       *                                                      *
>       *   Under no circumstances should an Internet-Draft    *
>       *   be referenced by any paper, report, or Request-    *
>       *   for-Proposal, nor should a vendor claim compliance *
>       *   with an Internet-Draft.                            *
>       *                                                      *
>       ********************************************************
>



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h31CgTRN019914 for <[e-mail]>; Tue, 1 Apr 2003 14:42:29 +0200 (MEST)
Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h31CgT0r019913 for ietf-provreg-outgoing; Tue, 1 Apr 2003 14:42:29 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.237.102]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h31CgSRN019908 for <[e-mail]>; Tue, 1 Apr 2003 14:42:28 +0200 (MEST)
Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [10.170.12.38]) by heron.verisign.com (8.12.8/8.12.8) with ESMTP id h31Chf2P009610; Tue, 1 Apr 2003 07:43:41 -0500 (EST)
Received: by vsvapostalgw1.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <2AQR906K>; Tue, 1 Apr 2003 07:38:32 -0500
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'George Michaelson'" <[e-mail]>
Cc: [e-mail]
Subject: RE: [ietf-provreg] the privacy problem statement
Date: Tue, 1 Apr 2003 07:38:32 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

> > If I remember correctly the feeling of the room in San 
> Francisco was that
> > 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.

Absent anything that resembles social data (as described in RFC 3375)
outside the contact mapping, I'm working with a definition of social data
that only applies to elements present in the contact mapping.

-Scott-


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h31Ah9RN018775 for <[e-mail]>; Tue, 1 Apr 2003 12:43:09 +0200 (MEST)
Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h31Ah9XV018774 for ietf-provreg-outgoing; Tue, 1 Apr 2003 12:43:09 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from bartok.sidn.nl (bartok.sidn.nl [193.176.144.164]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h31Ah7RN018769 for <[e-mail]>; Tue, 1 Apr 2003 12:43:08 +0200 (MEST)
Received: from bartok.sidn.nl (localhost.sidn.nl [127.0.0.1]) by bartok.sidn.nl (8.12.6p2/8.12.8) with ESMTP id h31AgtNk089306; Tue, 1 Apr 2003 12:42:55 +0200 (CEST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Edmon Chung" <[e-mail]>
cc: "Asbjorn Mikkelsen" <[e-mail]>, "Ram Mohan" <[e-mail]>, [e-mail]
Subject: Re: side bar, was Re: [ietf-provreg] Our "Privacy Issue" 
In-reply-to: Your message of Fri, 28 Mar 2003 08:48:17 -0500. <00da01c2f530$b178bb30$[e-mail]> 
Date: Tue, 01 Apr 2003 12:42:54 +0200
From: Jaap Akkerhuis <[e-mail]>
Sender: [e-mail]
Precedence: bulk

    > 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)
    
To be (IETF) polical correct, the last time I checked, there was no
EPP at all. Note that the IETF discourages the use of dratfs in any
form. See attached scitation from RFC 2026. So, at best one can
talk about "by the IETF provreg-WG insprired" protocol.

And for good order, .NL is not using anything which remotely
looks like EPP.

	jaap

RFC 2026, section 2.6

   An Internet-Draft is NOT a means of "publishing" a specification;
   specifications are published through the RFC mechanism described in
   the previous section.  Internet-Drafts have no formal status, and are
   subject to change or removal at any time.

      ********************************************************
      *                                                      *
      *   Under no circumstances should an Internet-Draft    *
      *   be referenced by any paper, report, or Request-    *
      *   for-Proposal, nor should a vendor claim compliance *
      *   with an Internet-Draft.                            *
      *                                                      *
      ********************************************************



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h2VN6wRN012254 for <[e-mail]>; Tue, 1 Apr 2003 01:06:58 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h2VN6wZr012253 for ietf-provreg-outgoing; Tue, 1 Apr 2003 01:06:58 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from garlic.apnic.net (garlic.apnic.net [202.12.29.224]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h2VN6tRN012248 for <[e-mail]>; Tue, 1 Apr 2003 01:06:56 +0200 (MEST)
Received: from garlic.apnic.net (localhost [127.0.0.1]) by garlic.apnic.net (8.12.8p1/8.12.8) with ESMTP id h2VN4CHd000981; Tue, 1 Apr 2003 09:04:12 +1000 (EST)
Received: (from ggm@localhost) by garlic.apnic.net (8.12.8p1/8.12.8) id h2VN49eL000427; Tue, 1 Apr 2003 09:04:09 +1000 (EST)
Date: Tue, 1 Apr 2003 09:04:09 +1000
From: George Michaelson <[e-mail]>
To: "Hollenbeck, Scott" <[e-mail]>
Cc: "'Edward Lewis'" <[e-mail]>, [e-mail]
Subject: Re: [ietf-provreg] the privacy problem statement
Message-Id: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Organization: APNIC Pty Ltd
X-Mailer: Sylpheed version 0.8.10claws101 (GTK+ 1.2.10; i386--netbsdelf)
X-Fruit-Of-The-Month-Club: persimmon
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

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

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

> 
> If I remember correctly the feeling of the room in San Francisco was that
> 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: [e-mail]    |  PO Box 2131 Milton QLD 4064
Phone: [phone]  |  Australia
  Fax: [phone]  |  http://www.apnic.net