[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: "Hollenbeck, Scott" <shollenbeck@verisign.com>
Cc: "'ietf-provreg@cafax.se'" <ietf-provreg@cafax.se>
From: Edward Lewis <edlewis@arin.net>
Date: Mon, 21 Apr 2003 11:21:29 -0400
In-Reply-To: <5BEA6CDB196A4241B8BE129D309AA4AF10E698@vsvapostal8>
Sender: owner-ietf-provreg@cafax.se
Subject: Re: [ietf-provreg] Proposed Text for Contact Mapping DisclosureElements

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                                            +1-703-227-9854
ARIN Research Engineer

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

Home | Date list | Subject list