Re: "private" Element Attribute

[Mike Lampson <lampson@iaregistry.com>]

Scott,

Would "private" object elements appear to non-sponsoring entities
(Registrars) when they issue the "info" command?

My preference would be that "info" would only show non-private object
elements to non-sponsoring entities *unless* the non-sponsoring entity has a
valid AuthInfo code.  This allows the elements to remain private, but also
allows for the values to be disclosed to another Registrar if they have been
provided the correct AuthInfo code.  While this isn't necessary at a
protocol level to initiate a transfer, it is necessary at an administrative
level so that the potential gaining Registrar knows whose domain they are
actually transferring.  (It's better to verify that the Transfer is being
initiated by a current contact for the domain rather than a former employee
or other individual who may have somehow acquired the AuthInfo code.)

I expect that once a "private" attribute is implemented at a Registry that
you are not going to see just phone numbers and email addresses marked as
private, but entire contacts will be marked as private.  Hence my
recommendation for the "info" comand to show everything when a valid
AuthInfo code is included.

Just my 2cents,

Mike Lampson
The Registry at Info Avenue, LLC
(Really a Registrar, not a Registry)


----- Original Message -----
From: "Hollenbeck Scott" <shollenbeck@verisign.com>
To: "'ietf-provregcafaxse'" <ietf-provreg@cafax.se>
Sent: Monday, October 21, 2002 10:08 AM
Subject: "private" Element Attribute


A heads-up to the WG related to IESG comment #8, described here [1]:

In the ongoing IESG discussion of our EPP documents, we (Patrik and I) have
come to the conclusion that we might need to add a new attribute to every
object element in the domain, contact, and host mappings.  This boolean
attribute, "private", will be used to note that the value of an element
should not be disclosed to third parties.  It will have a default value of
"false" meaning it is ok to disclose info.  Additional constraints can be
defined using the protocol extension mechanism.

Here are some examples:

<contact:email private="true">jdoe@example.com</contact:email>

<domain:name private="false">example.com</domain:name>

<host:addr ip="v4" private="true">192.1.2.3</host:addr>

<extension>
  <noWhois><contact:email></noWhois>
</extension>

(This extension example isn't syntactically valid, but I wanted it to be
short, clear, and to the point without the clutter needed to make it valid.
In this case it means that the email address should not be published via
whois.)

Patrik's point is that we start getting into the policy issues that bogged
us down earlier if we try to pick and choose the elements to which the
attribute should be added.  That's a good point that can get us past where
we failed a year or so ago, but it means that server operators might have to
deal with some operational inconsistencies.  We'll have to add some notes to
explain that server policy might not recognize the value of an attribute if
it's turned on (like in the address example above) when turning on the
attribute is counter to some policy.

If anyone has any issues with this approach, please mention them now.

-Scott-

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