Individual Contribution                              E. Brunner-Williams
Internet-Draft                                                Wampumpeag
Expires: April 28, 2003                                 October 28, 2002


                        EPP Data Considerations

             <draft-brunner-epp-data-considerations-00.txt>

Status of this Memo

   This document is an Internet-Draft and is NOT offered in accordance
   with Section 10 of RFC2026, and the author does not provide the IETF
   with any rights other than to publish as an Internet-Draft.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at http://
   www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 28, 2003.

Abstract

   This memo discusses data collection considerations and EPP. It is
   far from complete, but deadlines press.

   Distribution of this document is unlimited.

Dedication

   This draft is dedicated to Paul Wellstone, Senator from Minisota.









Brunner-Williams         Expires April 28, 2003                 [Page 1]

Internet-Draft                  EPP Data                    October 2002


Table of Contents

   1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . .   3
   2. Background . . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3. The PROVREG WG . . . . . . . . . . . . . . . . . . . . . . . .   5
   4. The Problem (or IESG Considerations) . . . . . . . . . . . . .   7
   5. The EPP Data Collection Element <dcp>  . . . . . . . . . . . .   9
   6. W3C P3P Overview . . . . . . . . . . . . . . . . . . . . . . .  12
   7. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . .  13
      References . . . . . . . . . . . . . . . . . . . . . . . . . .  15
      Author's Address . . . . . . . . . . . . . . . . . . . . . . .  15
   A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  16







































Brunner-Williams         Expires April 28, 2003                 [Page 2]

Internet-Draft                  EPP Data                    October 2002


1. Introduction

   After Working Group Last Call (WGLC) on the set of memos that form
   the core specification [EPP-P],[EPP-C],[EPP-D],[EPP-H] of a
   provisioning protocol for domain names meeting the requirements
   contained in [RFC3XXX], an issue relating to the access model for
   data was raised.

   Provisioning protocols for domain names [RFC2832],[SRS],[EPP-P]
   minimally transport data necessary for name servers implementing
   [RFC1034][RFC1035] et seq., aka "DNS", to provide mappings between
   some addresse(s) and some name(s).  This is generally referred to as
   "publication" via a zone file.  The usage of the PROVREG Working
   Group is to refer to this data as "technical data".  The prevailing
   policy at the time [RFC881] was written, which defined the modern
   form of namespaces for doman name (see [RFC606],[RFC608]), required
   additional data to be provisioned.  This policy was originally
   articulated in [RFC742], and subsequently revised in [RFC812], and
   ultmately [RFC954].  The usage of the PROVREG Working Group is to
   refer to this data as "social data".  The primary distinguishing
   characteristic between "technical" and "social" data is that absence
   of or error in "social" data has no effect on the DNS.

   [Discussion of Thick vs Thin.]

   Fee-for-service operator of domain name operators, "pay-registries"
   hereafter, and fee-for-service regstrars, "pay-registries" hereafter,
   generally require sufficient additional data to support payment
   mechanisms.  One policy for the management of domain name spaces
   imposes an expiry property on domain names.  This policy is used by
   fee-for-service operators for service subscription, and a common form
   of this is the annual renewal model.  For historical reasons the
   prevailing practice by fee-for-service registry and registrar
   operators is to require [RFC954] "social data", in addition to the
   data sufficient to support payment mechanisms, and to publish the
   "social data", following the practices set down in [RFC954].















Brunner-Williams         Expires April 28, 2003                 [Page 3]

Internet-Draft                  EPP Data                    October 2002


2. Background

   Several memos have appeared that attempt to reduce the impact of
   trafficing in network endpoint identfiers, e.g.,

   1.  Anti-Spam Recommendations for SMTP MTAs [RFC2505],

   2.  DON'T SPEW A Set of Guidelines for Mass Unsolicited Mailings and
       Postings (spam*) [RFC2635],

   3.  How to Advertise Responsibly Using E-Mail and Newsgroups or - how
       NOT to $$$$$ MAKE ENEMIES FAST! $$$$$ [RFC3098],

   Additionally, several memos have appeared that directly or incidently
   reduce the accessibility of network endpoint identifiers to
   trafficers in identfiers, e.g.,

   1.  The IP Network Address Translator (NAT) [RFC1631]

   2.  Network Address Translator (NAT)-Friendly Application Design
       Guidelines [RFC3235

   None has been published which obsoletes or updates NICNAME/WHOIS
   [RFC954], which mandates whois operators to acquire, and publish
   without any access controls, the names, postal, telephonic, and
   internet endpoint identfiers, of domain name infrastructure providors
   (aka "registrants").
























Brunner-Williams         Expires April 28, 2003                 [Page 4]

Internet-Draft                  EPP Data                    October 2002


3. The PROVREG WG

   Some contributors to PROVREG are EPP implementors, and some are
   registry (or registrar) operators, or both.  The operational
   practices of each operator may be limited to a single controlling
   authority, however, operators may operate multiple instances, each
   with a distinct operational practice.  Implementors may seek to
   support "lazy evaluation" of operational practices.

   In particular, collection practices of registries, registrars are not
   assumed to be uniform.  This lead to the the requirement:

    8.4 Data Collection Requirements [1], GRRQ


   	The protocol MUST provide services to identify data collection
   	policies.


   Note that the requirement is for collector policies, not originator
   preferences.

   The PROVREG WG considered the mechanism of the W3C's P3P activity,
   and adopted the following basic elements:

   1.  the mechanism would allow description of data collection
       practice, necessarily by the data collector

   2.  portions of the P3P XML Schema, specifically:

       1.  <access> element

       2.  <statement> element containing:

           1.  <purpose> element

           2.  <recipient> element

           3.  <retention> element

           4.  <expiry> element (optional)

   3.  [anything else I think of]

   4.  the optional character of P3P.

   These allow for the registry data-collector to announce to the
   registrar the registry's data collection practices, and for registrar



Brunner-Williams         Expires April 28, 2003                 [Page 5]

Internet-Draft                  EPP Data                    October 2002


   data to be provisioned to a registry under a specific policy.


















































Brunner-Williams         Expires April 28, 2003                 [Page 6]

Internet-Draft                  EPP Data                    October 2002


4. The Problem (or IESG Considerations)

   The problem or issue raised upon IESG review of the work product of
   the PROVREG contributors is two-fold, some IESG commentors sought
   finer granularity for data protection, some to add originator
   preference.

   The PROVREG contributors considered these possibilities in mid-2001.
   A semantic could be attached to an individual XML element, or to an
   EPP object, or to an operation on an object, or to a group of EPP
   commands and responses, aka, an EPP "session".  The semantic could
   originate from a registry, or from a regstrar, or from a reseller, or
   from a registrant.

   Because EPP is protocol between regstrar and registry peers, allowing
   resellers or users mechanisms to affect the state of an EPP
   transaction was eventually considered "out-of-scope".

   Because the initial focus of the PROVREG contributors was on a
   connection-oriented, session-maintaining transport (TCP), and
   operational practice of PROVREG contributing registry operators and
   registrars did not suggest a use case for multiple data collection
   practices within a single namespace, reflected within the protocol as
   a single logical instance of an EPP server, the "EPP session" was
   associated with the <dcp> element.

   The proposal from the IESG to the Working Group was to add a new
   attribute to every object element in the domain, contact, and host
   mappings.  The new attribute would be a Boolean type, named
   "private", and will be used to note that the value of an element
   SHOULD NOT (emphasis added) be disclosed to third parties.

   This proposal would change the EPP schema, which of necessity, is a
   change to the protocol, as the protocol is defined in XML Schema.  It
   is not an extension, hence optional to implement.  Ironically, it is
   optional to evaluate.  Conformant EPP+XML parsers could ignore the
   value of the attribute, or simply treat as white-space anything
   following the closure of each element in the Working Group Schema.

   The proposal additionally held that the default value should be
   "false", meaning that the element should be disclosed to third
   parties.

   This proposal would be consistent with the "opt-out" legal regime of
   the United States, but inconsistent with the "opt-in" regime of the
   OECD States, and inconflict with the "opt-in" regime of the EU
   States.




Brunner-Williams         Expires April 28, 2003                 [Page 7]

Internet-Draft                  EPP Data                    October 2002


    Examples of the IESG proposal:


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


   Note: This extension example isn't syntactically valid, it is shown
   for expository purposes only.



































Brunner-Williams         Expires April 28, 2003                 [Page 8]

Internet-Draft                  EPP Data                    October 2002


5. The EPP Data Collection Element <dcp>

   From the -07 xsd.



   <!--
   A greeting is sent by a server in response to a client connection
   or <hello>.
   -->
     <complexType name="greetingType">
       <sequence>
         ...
         <element name="dcp" type="epp:dcpType" minOccurs="0"/>
         ...
       </sequence>
     </complexType>

   <!--
   Data Collection Policy types.
   -->
     <complexType name="dcpType">
       <sequence>
         <element name="access" type="epp:dcpAccessType"/>
         <element name="statement" type="epp:dcpStatementType"
          maxOccurs="unbounded"/>
         <element name="expiry" type="epp:dcpExpiryType"
          minOccurs="0"/>
       </sequence>
     </complexType>

     <complexType name="dcpAccessType">
       <choice>
         <element name="all"/>
         <element name="none"/>
         <element name="null"/>
         <element name="other"/>
         <element name="personal"/>
         <element name="personalAndOther"/>
       </choice>
     </complexType>

     <complexType name="dcpStatementType">
       <sequence>
         <element name="purpose" type="epp:dcpPurposeType"/>
         <element name="recipient" type="epp:dcpRecipientType"/>
         <element name="retention" type="epp:dcpRetentionType"/>
       </sequence>



Brunner-Williams         Expires April 28, 2003                 [Page 9]

Internet-Draft                  EPP Data                    October 2002


     </complexType>

     <complexType name="dcpPurposeType">
       <sequence>
         <element name="admin"
          minOccurs="0"/>
         <element name="contact"
          minOccurs="0"/>
         <element name="other"
          minOccurs="0"/>
         <element name="prov"
          minOccurs="0"/>
       </sequence>
     </complexType>

     <complexType name="dcpRecipientType">
       <sequence>
         <element name="other"
          minOccurs="0"/>
         <element name="ours" type="epp:dcpOursType"
          minOccurs="0" maxOccurs="unbounded"/>
         <element name="public"
          minOccurs="0"/>
         <element name="same"
          minOccurs="0"/>
         <element name="unrelated"
          minOccurs="0"/>
       </sequence>
     </complexType>

     <complexType name="dcpOursType">
       <sequence>
         <element name="recDesc" type="epp:dcpRecDescType"
          minOccurs="0"/>
       </sequence>
     </complexType>

     <simpleType name="dcpRecDescType">
       <restriction base="token">
         <minLength value="1"/>
         <maxLength value="255"/>
       </restriction>
     </simpleType>

     <complexType name="dcpRetentionType">
       <choice>
         <element name="business"/>
         <element name="indefinite"/>



Brunner-Williams         Expires April 28, 2003                [Page 10]

Internet-Draft                  EPP Data                    October 2002


         <element name="legal"/>
         <element name="none"/>
         <element name="stated"/>
       </choice>
     </complexType>

     <complexType name="dcpExpiryType">
       <choice>
         <element name="absolute" type="dateTime"/>
         <element name="relative" type="duration"/>
       </choice>
     </complexType>







































Brunner-Williams         Expires April 28, 2003                [Page 11]

Internet-Draft                  EPP Data                    October 2002


6. W3C P3P Overview

   This section left mostly blank for the time being.

   Some intro blurb for those lacking clue.

   P3P requires that policy reference files MUST be encoded using UTF-8,
   (2.3.2), and all policies MUST be encoded using UTF-8 (3.2).

   The exception to this is the p3p-link-tag, which has the same
   character encoding will be the same as that of the HTML document it
   is embedded in.

   This is not required by XML, see draft-brunner-epp-smtp-00 for
   details.




































Brunner-Williams         Expires April 28, 2003                [Page 12]

Internet-Draft                  EPP Data                    October 2002


7. Discussion

   There are 5 areas of significant difference between the PROVREG and
   IESG approaches:

   1.  optional element vs pervasive attribute

   2.  command (or "session") scope vs element scope

   3.  extensible vocabulary vs binary toggle

   4.  collector policy vs user preference

   5.  undisclosed policy default vs opt-out preference default

   What follows is a brief discussion of these.

   The impact of the IESG's proposal is that every implementor would
   have to implement the attribute.  While evaluation is "MAY",
   discussed later, the schema-change is "MUST".  Since implemention of
   the <dcp> element is optional, and may be absent from a server's
   <greeting> response, it is possible that the IESG's proposal would
   have the effect of making the PROVREG approach moot.

   The IESG's proposal is that third parties are not recipients of data,
   ignoring the difference between "preference" and (IESG) and "policy"
   (PROVREG).  There is no benefit from narrowing the scope to a leaf
   elements, except subdivision "social" data into discretionary
   categories with combinatorial scaling issues.  Indicating that third
   parties are not recipients of data is trivially accomplished with the
   <dcp>.

   The IESG's proposal is restricted to a binary value set, or possibly
   an enumerated set.  If enumerated, changes to it would require a
   protocol version identifier change, as it is a proposed pervasive
   property of the EPP schema.  The PROVREG approach is extensible, and
   uses a well-known vocabulary covering registrant access to the
   registry-resident data, recipients of the registrant data,
   repurposing of registrant data, and retention of registrant data,
   with problem-domain specific modification.

   The IESG's proposal is to express the third-party disclosure
   preference of registrants.  EPP clients MUST emit "privacy"
   attributes on each <element>, which EPP servers MAY ignore.  The
   PROVREG approach allows EPP clients to REQUIRE EPP servers to emit a
   <dcp> element, and evalute the policy, before sending data to the EPP
   server.  The net of the IESG proposal is that registries may accept
   registrant social data with this preference, and may then ignore it,



Brunner-Williams         Expires April 28, 2003                [Page 13]

Internet-Draft                  EPP Data                    October 2002


   except for faithfully returning the attribue's value in <info>
   responses, but treating the data as unencumbered.  The user's
   PREFERENCE is not binding.  The PROVREG approach is the collector
   states its policy, allowing registrant selection of operators based
   upon policy.

   The IESG's proposal is that the registrant must opt-out of third-
   party disclosure.  The PROVREG approach is that the registrars data
   collection policy is unknown unless stated.

   One issue remains in the author's mind as a sub-text in the IESG's
   proposal that is worth pursuing.  Charitably restated, the IESG
   proposes element-wise access policy for the EPP schema.  Mechanism
   left to the imagination.  This can be accomplished by element-wise
   encryption, which has the disadvantage of adding key management to
   the problem doamin, and the advantages of allowing a richer access
   policy.  The W3C XML Encryption Activity has published in this area.


































Brunner-Williams         Expires April 28, 2003                [Page 14]

Internet-Draft                  EPP Data                    October 2002


References

   [1]  Bradner, S., "The Internet Standards Process -- Revision 3", RFC
        2026, BCP 9, October 1996.

   [2]  Hollenbeck, S., "Extensible Provisioning Protocol", , August
        2002.

   [3]  Hollenbeck, S., "Extensible Provisioning Protocol Contact
        Mapping", , August 2002.

   [4]  Hollenbeck, S., "Extensible Provisioning Protocol Domain Name
        Mapping", , August 2002.

   [5]  Hollenbeck, S., "Extensible Provisioning Protocol Host Mapping",
        , August 2002.


Author's Address

   Eric Brunner-Williams
   Wampumpeag, LLC
   1415 Forest Avenue
   Portland, Maine  04103
   United States

   EMail: brunner@nic-naa.net
























Brunner-Williams         Expires April 28, 2003                [Page 15]

Internet-Draft                  EPP Data                    October 2002


Appendix A. Acknowledgements

   The author gratefully acknowledges the contributions over the years
   of the Chair, Staff, Member Company contributing representitives, and
   Invited Experts of the W3C's P3P Specification Working Group.  Many
   thanks go to the contributors to the IETF EPP drafts.

   In addition the author thanks Marshall Rose who provided the
   extremely useful [RFC2629] document type description and xml2rfc tool
   used to edit this specification.  The author may yet learn how to use
   this tool.








































Brunner-Williams         Expires April 28, 2003                [Page 16]