Subject: [ire] Draft of IETF 77 BoF Notes

From: Edward Lewis <[email-masked]>
Date: Wed, 31 Mar 2010 12:35:56 -0400

Draft of notes

Please post comments to the list or to the chairs
==================================================================

This is a summary of the issues raised during the BoF, sorted into 
categories.  There is an audio recording of the session is available, 
if further detail and personal attribution is needed.

To access the audio recording, go to:

         http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf77/

and find the file named:

         ietf77-ch8-wed-am.mp3

Our session is from  from 1h37m40s to 2h39m12s on the "tape".

The full URL for the audio file is here:
http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf77/ietf77-ch8-wed-am.mp3 

Escrow Problem Domain

    Basic scope - the relationship of objects (like domain names, IP address
    ranges) to entities (people, organizations).  Ancillary information like
    contact roles, addresses. Operational information related to registrants
    like registered servers and meta-data.  Slippery slope - operational
    parameters of the registration entity.

    Is not the same thing as system backups.  Different collection practice,
    different retrieval methods.

    History of data - can be included within an escrow drop but escrow drops
    don't constitute a history.  ("Title searches.")  ("Escrow drop" is one
    instance of the escrow, usually visualized as a file or a set of files.)

    Policies - usually available via other means, set by other means (by the
    regulator for instance), therefore not envisioned in the escrow.

    What is in a registry's registration database is in scope.

    Q: Why so many "exclusions?"
    A: Perception of registry scope is wider than the reality.  Registration
       organizations offer many side services, which makes the problem seem
       bigger

    DNSSEC private keys - not in escrow, this is part of operations parameters

    Public keys held for DNSSEC (or other purposes) - in scope

Escrow Actors

    Usually the registration body, the regulator (requires it), and the
    third party that holds the information.

    Role of law enforcement - considered external to problem domain, which is
    deriving the format of the data, not a discussion of policies over it

Escrow Policies

    One policy that borders in-scope and out-of-scope is the protection
    of the Escrow "drop" itself.  It might be "up to the regulator" to
    specify this, nevertheless, a discussion of this issue should be present
    in any IETF document produced on the topic.

    Out of scope for the work, each regulator can specify these differently for
    their registration space
      Security considerations, including authorization to read (access)/write.

    The transit of the data is undefined, that is a matter usually determined
    by the third party holding the escrow.

Escrow Purpose

    WG scope is to define a format for what is essential to reconstitute a
    registration body.  (Time budget is undefined.)

    Not for transfer of registry operations - this has been done before with
    out escrow (SRI-NIC to Network Solutions, .ORG, others).

Why IETF?

    This work comes from a need identified within ICANN but is a problem more
    general than the environment within ICANN.  ICANN has generated a few
    attempts to solve this but nothing sufficiently general.

    IETF provides a global view (wrt registration), is inclusive of 
domain names,
    of any kind (gTLD, ccTLD, IDN), and network identifiers (RIRs), and has
    technical expertise for generating the formatting needed.  However, it is
    recognized that not all of the involved entities will actively participate
    without much encouragement and outreach.

BoF Concerns and Polls

    No work should be open ended, balanced against bringing in a 
solution seeking
    a "rubber stamp" of approval.

    Charter presented doesn't match the draft.

    Still a large group to consult on this issue, to determine whether it is
    "global" or something specific to ICANN.  One next step is to establish
    that there is an appropriate spread of interest that would lead this to
    be a fit for the IETF.  (E.g., do any of the RIRs care about escrow?)

    Chairs asked for a show of hands and a super-majority of the ones
    present wanted to have this work inside the IETF.  There were a
    "non-negligible to to noticeable to significant" number of "no's"
    and "abstains"

    Chairs also asked about if people have clarity about the possible
    scope of the working group; very few people believed so.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

New pithy statement under construction...still thinking about it...