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.