Folks,

My work schedule has suffered one of life's inescapable interruptions.  In this case, it's good: our granddaughter entered the world this past Saturday.  My wife and I have been in San Francisco providing support.  Everyone is well, but I'm behind on my participation in this working group.

Attached is my partial draft of a composite treatment of the natural vs legal collection of issues.  I started writing from front to back but haven't had time to finish.  I added a section at the end with the conclusions and recommendations.  I will fill in the missing pieces as quickly as I can.

Despite the incompleteness, we did have an opportunity in the SSAC work party to review and agree on the recommendations.

For ease of access, the recommendations are copied below.

Thanks,

Steve

1.     Inescapable Requirement: Definition of Roles

Each role must be defined in terms of the authority and responsibilities associated with the role.  This definition must be explicitly available to both the people fulfilling the role and the people interacting with the people in those roles.  Each person named in a role must be aware of being named and must agree to the obligations associated with the role.

The definition must also include an explicit statement of how the information about the person in the role will be disseminated.

Information about the registrant is provided by the Account Holder.  The Account Holder is effectively an agent of the Registrant and is the only authoritative source of information about the status of the registrant.

2.     Recommendation: Unknown Persons

In addition to definite status of Natural Person or Legal Person, the status of Unknown should be included in the design of the system.

3.     Recommendation: Additional Protection

In addition to whether the registrant is a Natural, Legal or Unknown Person, the status should also include an additional attribute regarding whether the registrant requires special privacy protection.

It is an open question as to whether additional privacy protection should be available to any registrant who wishes it or should require justification.  At the very least, to facilitate visibility into potentially harmful behaviors, Registrars should avoid unnecessary protection of registration data.

4.     Recommendation: Downgrading

Registrants should have the option of “downgrading” the level of protection for some or all of their data elements.

Registrars should have the option of implementing downgrading on a field by field basis or in groups of fields.

ICANN should establish a date certain for registrars to implement registrant option to downgrade the sensitivity of their registrations.

5.     Comment: Recourse

 If a person named in any role in a registration feels the data is incorrect or is being disseminated improperly, they have recourse via the Registrant.  Failing that, they have recourse through ICANN’s compliance process.  No additional processes are required.

6.     Recommendation: Org Field

The Org field should not be used to determine the registrant’s status.  The Registrar should require Legal Persons to provide the Org data element.  The Registrar should permit Natural or Unknown registrants to provide or not provide the Org data element.

7.     Recommendation: Transition

ICANN should establish a plan for transitioning Unknown registrations into known status.