Subject: [ire] I-D Action:draft-arias-registry-data-escrow-00.txt

From: [email-masked] (by way of Paul Hoffman)
Date: Mon, 25 Jan 2010 17:40:06 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : Internet Domain Registry Data Escrow specification
	Author(s)       : F. Arias
	Filename        : draft-arias-registry-data-escrow-00.txt
	Pages           : 24
	Date            : 2010-01-25

This document specifies the format and contents of Data Escrow
deposits for Domain Registries.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-arias-registry-data-escrow-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

[The following attachment must be fetched by ftp.  Command-click the URL below to ask your ftp client to fetch it.]
<ftp://ftp.ietf.org/internet-drafts/draft-arias-registry-data-escrow-00.txt>
_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 25 Jan 2010 17:44:28 -0800

I'm now very confused about this BoF. The draft that Ed promised had been published. The draft describes a format that is unlike almost any published by the IETF (CSV, metadata both in the file name and in the first line of the file, and so on). The draft also points to <http://www.icann.org/en/topics/new-gtlds/draft-agreement-specs-clean-04oct09-en.pdf>, which looks like a nearly-done agreement that embodies this work.

Why is the IRE work being proposed to be done in the IETF at all if ICANN has pretty much agreed on the format in advance, and is choosing to use a format that would probably not come out of the IETF if it had been designed here? Shouldn't this just be ICANN work?

--Paul Hoffman, Director
--VPN Consortium

---

From: Francisco Arias <[email-masked]>
Date: Mon, 25 Jan 2010 18:19:04 -0800

Hi Paul,

Sorry for the misunderstanding. I was going to send a message explaining it but you got ahead of me with the announcement.

The document being referred in the I-D (which is also a draft in ICANN) is just what was used as a basis. A community worked on the ICANN document and then asked for it to be taken to IETF to better be developed here.

Even though that I can not speak for ICANN, it there were a Registry Data Escrow RFC, I think ICANN would be very happy to use it instead of whatever is now there; just as it is done with other IETF standards for DNS, EPP, WHOIS, etc.

In other words, this work once began in the ICANN community, but being a technical work more than policy, some of us thought it will be better done inside the IETF where a more broader technical community could participate in the effort and give a better technical result.

In the question of CSV, I should say I think it doesn't have to be CSV. If the group believes XML or something else is better for the task, so be it. Currently it is just what is there.

Regards,

__
Francisco

On 1/25/10 5:44 PM, "Paul Hoffman" <[email-masked]> wrote:

--Paul Hoffman, Director
--VPN Consortium
_______________________________________________
ire mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ire

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 25 Jan 2010 18:27:21 -0800

>Sorry for the misunderstanding. I was going to send a message explaining it but you got ahead of me with the announcement.

Heck, I even waited a few hours after you posted the draft. :-)

>In other words, this work once began in the ICANN community, but being a technical work more than policy, some of us thought it will be better done inside the IETF where a more broader technical com…

Really? They will wait for the new gTLD agreements until the IETF comes up with a standard for this format? That seems either very unlikely or very unwise. Also, the referred-to draft agreement says that the format is being developed by ICANN and registry technical teams; is there any indication of actual buy-in to waiting for the IETF to do the work?

>In the question of CSV, I should say I think it doesn't have to be CSV.

CSV is fine if you don't mind horrible quoting problems and more edge cases than you can imagine.

>If the group believes XML or something else is better for the task, so be it. Currently it is just what is there.

There will probably be at least four different formats proposed.

--Paul Hoffman, Director
--VPN Consortium

---

From: Francisco Arias <[email-masked]>
Date: Mon, 25 Jan 2010 18:57:42 -0800

On 1/25/10 6:27 PM, "Paul Hoffman" <[email-masked]> wrote:

>> The document being referred in the I-D (which is also a draft in ICANN) is
>> just what was used as a basis. A community worked on the ICANN document and
>> then asked for it to be taken to IETF to better be developed here.
>> 
>> Even though that I can not speak for ICANN, it there were a Registry Data
>> Escrow RFC, I think ICANN would be very happy to use it instead of whatever
>> is now there; just as it is done with other IETF standards for DNS, EPP,
>> WHOIS, etc.
>> 
>> In other words, this work once began in the ICANN community, but being a
>> technical work more than policy, some of us thought it will be better done
>> inside the IETF where a more broader technical community could participate in
>> the effort and give a better technical result.
> 
> Really? They will wait for the new gTLD agreements until the IETF comes up
> with a standard for this format? That seems either very unlikely or very
> unwise. Also, the referred-to draft agreement says that the format is being
> developed by ICANN and registry technical teams; is there any indication of
> actual buy-in to waiting for the IETF to do the work?

I never said they will wait, and I think they won't. I think a Registry Data
Escrow (RyDE) spec as RFC would be used once it is available.

Currently there are other non-technical issues that need to be solved prior
to the launch of new gTLDs. I don't know when they are going to be solved.
Also there are other things that would need to happen after the launch
(reception of applications, evaluation, etc.) before there is any Agreement
signed.

Maybe we could have the RFC before there is any Agreement signed.

__ 
Francisco

---

From: James M Galvin <[email-masked]>
Date: Tue, 26 Jan 2010 07:53:03 -0500

Speaking as co-chair of the BOF:

-- On January 25, 2010 5:44:28 PM -0800 Paul Hoffman 
<[email-masked]> wrote regarding Re: [ire] I-D 
Action:draft-arias-registry-data-escrow-00.txt --

> I'm now very confused about this BoF. The draft that Ed promised had
> been published. The draft describes a format that is unlike almost
> any published by the IETF (CSV, metadata both in the file name and in
> the first line of the file, and so on). The draft also points to
> <http://www.icann.org/en/topics/new-gtlds/draft-agreement-specs-clean
> -04oct09-en.pdf>, which looks like a nearly-done agreement that
> embodies this work.

As is common with many (most?) BOFs these days in the IETF, the draft 
is an individual submission being offered as a starting point for this 
work, if the IETF adopts it of course.

> Why is the IRE work being proposed to be done in the IETF at all if
> ICANN has pretty much agreed on the format in advance, and is
> choosing to use a format that would probably not come out of the IETF
> if it had been designed here?

For many of the same reasons that any work is brought to the IETF. 
Here's a few that come to my mind.

While ICANN is not purely a policy body I think it is fair to say that 
it leans on the policy side.  This work is purely technical.  While it 
is true that many of those who would be most directly affected by this 
work do participate in ICANN's work, this work has the potential to be 
useful outside of just registries.  In addition, given the technical 
nature of this work and the tendency towards policy issues on the ICANN 
side, more of the necessary technical participants will be present in 
the IETF.

There is a broader base of expertise present in the IETF that this work 
would benefit from, e.g., security review.  You pointed out another 
example above: the format chosen.  People tend to work with what they 
know.  There are more "format experts" in the IETF and thus this work 
is likely to find a better choice in this forum.

Finally, this is not the first time ICANN has looked to the IETF for 
technical expertise.  You do remember EPP and CRISP?

> Shouldn't this just be ICANN work?

ICANN will set a policy that adopts this work, if the IETF agrees to do 
the work.  This is as it should be, in my opinion of course.

Jim

---

From: James M Galvin <[email-masked]>
Date: Tue, 26 Jan 2010 08:01:33 -0500

-- On January 25, 2010 6:27:21 PM -0800 Paul Hoffman 
<[email-masked]> wrote regarding Re: [ire] I-D 
Action:draft-arias-registry-data-escrow-00.txt --

> > In other words, this work once began in the ICANN community, but
> > being a technical work more than policy, some of us thought it will
> > be better done inside the IETF where a more broader technical
> > community could participate in the effort and give a better
> > technical result.
>
> Really? They will wait for the new gTLD agreements until the IETF
> comes up with a standard for this format? That seems either very
> unlikely or very unwise. Also, the referred-to draft agreement says
> that the format is being developed by ICANN and registry technical
> teams; is there any indication of actual buy-in to waiting for the
> IETF to do the work?

Sorry for the confusion Paul.  It was decided to move this along in the 
IETF less than a week ago and we've had the BOF request deadline right 
in front of us.

So, while Francisco did a great job getting the document into an 
internet draft format and published, there are a few rough edges.

ICANN is going to do what ICANN is going to do, just as the IETF is 
going to do what the IETF is going to do.  If ICANN moves forward 
without this work being completed, that probably means they will just 
write their contracts the same way they have been for years.  When the 
IETF is done then they'll revise their contracts.  Other options are 
possible, I don't know nor do I control what ICANN will do, but ICANN's 
choice should not concern the IETF.

Certainly the intent is for the IETF to adopt this work and then ICANN 
will adopt the completed and published specification, as they have in 
the past with other specification, just as any other organization might 
do.  This is the most we can ask for right now.

Jim

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 26 Jan 2010 08:32:55 -0800

At 8:01 AM -0500 1/26/10, James M Galvin wrote:
>When the IETF is done then they'll revise their contracts. 

That works for me. It also sets a better expectation for what the value of the IETF work might be.

>Other options are possible, I don't know nor do I control what ICANN will do, but ICANN's choice should not concern the IETF.

Of course it should. If ICANN said "we will write our contracts to keep our current format for ten years, then see if there is an IETF has a better idea", that would help people decide whether or not to participate. Similarly, if ICANN said "we really hope that whatever comes out of the IETF is upward compatible from what we create", that also has a huge effect on who would want to participate.

>Certainly the intent is for the IETF to adopt this work and then ICANN will adopt the completed and published specification, as they have in the past with other specification, just as any other organization might do.  This is the most we can ask for right now.

Fully agree.

--Paul Hoffman, Director
--VPN Consortium

---

From: James M Galvin <[email-masked]>
Date: Tue, 26 Jan 2010 11:51:51 -0500

-- On January 26, 2010 8:32:55 AM -0800 Paul Hoffman 
<[email-masked]> wrote regarding Re: [ire] I-D 
Action:draft-arias-registry-data-escrow-00.txt --

> > Other options are possible, I don't know nor do I control what
> > ICANN will do, but ICANN's choice should not concern the IETF.
>
> Of course it should. If ICANN said "we will write our contracts to
> keep our current format for ten years, then see if there is an IETF
> has a better idea", that would help people decide whether or not to
> participate. Similarly, if ICANN said "we really hope that whatever
> comes out of the IETF is upward compatible from what we create", that
> also has a huge effect on who would want to participate.

Fair enough.  We don't work in a vacuum and neither should they.

I'm not expecting any sort of formal statement from ICANN but it is 
useful to note that ICANN reached out to make this BOF happen and 
promote interest and development in the IETF.  Given the expected 
timing of TLD activities in ICANN, which you mentioned early in this 
thread, I think it's safe to say that adoption of this work and 
progress on a specification sooner rather than later would be ideal.

As far as "upwardly" compatible is concerned, my expectation is that 
those who have to implement this are going to be present in the 
discussion and that detail will not get lost.

Jim

---

From: Jaap Akkerhuis <[email-masked]>
Date: Tue, 26 Jan 2010 18:17:06 +0100

Jim Galvin:
    As far as "upwardly" compatible is concerned, my expectation
    is that those who have to implement this are going to be present
    in the discussion and that detail will not get lost.

Note that there are already folks that have implemented escrow
protocols on their own (not in relation with ICANN). Some (European)
registries do have years of experience dealing with data in escrow.
It would be benificial to have them in the discussion as well.

	jaap

---

From: Edward Lewis <[email-masked]>
Date: Tue, 26 Jan 2010 12:22:20 -0500

>Shouldn't this just be ICANN work?

The reason I am willing to participate in this is because the 
underlying technical work benefits from the experiences from a wider 
audience than ICANN provides and can also turn around an benefit a 
wider audience than ICANN provides.  This despite the fact that ICANN 
is raising the concern.

In the TLD registry world, there is no alternative to the IETF when 
it comes to being an inclusive discussion forum for registration 
(technical) activity.  We have ICANN, but that only covers a few TLDs 
(few if you count delegations from the IANA root zone).  We have 
CENTR, APTLD, and LACTLD as other organizations that I can think of 
for discussion, and only one has a technical list open (only) to it's 
members.  Expanding further, there RIRs, routing registries, etc., 
that have may or may not have coordination fora.

Consider it an accident of history that the initial draft is rooted 
in the ICANN world.  This accident is not looking to be rubber 
stamped by the IETF.  The goal of the BoF is to first set goals for a 
WG.  Our idea is that the goals of the WG was to define a standard 
for data escrow that could then be fed back to ICANN.

Remember that we are still in BoF mode now, setting expectations.

At 18:17 +0100 1/26/10, Jaap Akkerhuis wrote:

>It would be beneficial to have them in the discussion as well.

And that's just the kind of experience the BoF wants to draw into the 
discussion.

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

As with IPv6, the problem with the deployment of frictionless surfaces is
that they're not getting traction.

---

From: James M Galvin <[email-masked]>
Date: Tue, 26 Jan 2010 12:24:32 -0500

Please do forward the BOF announcement on to whoever should know about 
it.  We certainly want to include everyone we can.

Jim
co-chair

-- On January 26, 2010 6:17:06 PM +0100 Jaap Akkerhuis 
<[email-masked]> wrote regarding Re: [ire] I-D 
Action:draft-arias-registry-data-escrow-00.txt --

---

From: Francisco Arias <[email-masked]>
Date: Tue, 26 Jan 2010 15:19:38 -0800

> It would be benificial to have them in the discussion as well.

I think there are already a few people from ccTLDs in this list as the
message got to the four regional ccTLD organizations (AfTLD, APTLD, CENTR
and LACTLD).

I don't know if it got to the RIR's, Registrars and others who may also be
interested?

__ 
Francisco

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 27 Jan 2010 16:30:29 +0100

On Mon, Jan 25, 2010 at 05:40:06PM -0800,
 by way of Paul Hoffman <[email-masked]> wrote 

>From the discussion that followed, I understand that it is not a real
proposal, just an example of what a standard could look like, in order
to sparkle the discussion.

If so, thanks, it is an useful document. IMHO, it is also a good
example of what we should NOT do in the future possible Working Group.

1) The biggest problem is that it is not policy-independant. A lot of
policy choices are cast in stone in this document. (Personal opinion:
even if it's limited to ICANN's TLD, I find incredible the level of
micro-management exercised by ICANN and the little freedom it leaves
to the registries.) A few examples: the mandatory inclusion of
registrar data (even billing data), the status codes from RFC 5731,
the obligation to escrow the ACE encoding of an IDN instead of the
real Unicode name, the long lists of mandatory attributes in section
5.1 (what if there is no expiration in the registry?), the lack of
some very important attributes in 5.2 (for instance, for a contact,
whether he is a physical person - and therefore entitled to the data
privacy provisions - or not), etc.

2) A variant of the previous problem: it is intended only for one
class of objects, domain names. John Curran indicated here that he
could be interested in a format for IP registries. May be something
more like EPP and IRIS (separating the format and the definition of
the classes of objects) would be a good idea. As said already here, we
should discuss the objects first and the format after.

3) The draft goes in very low-level details, even the filename
convention, which is not necessary for interoperability. IETF is about
formats and protocols, not procedures. Similar issue with things like
compression or encryption.
 
4) There is a discussion of Full vs. Incremental deposits. Before
deciding on a format for incremental deposits, we should search if
they are worth it. In my opinion, for an escrow system, integrity is
the most important thing and it is easier to achive with only full
deposits (if we are worry about performances, we can always use a
mechanism like rsync). Even if we use incremental deposits, rather
than inventing a patch language, we should reuse an existing one (for
instance RFC 5261 if the format is XML).

5) There is an obligation to escrow the forbidden names. But they are
not always defined in extension
<http://en.wikipedia.org/wiki/Extensional_definition>, sometimes the
rules are intensional (example: in .FR, the law - not the registry's
rules - forbids registration of the names of the cities, even if
intermixed with dashes so paris.fr and p-a-ris.fr and p-a-r-i-s.fr are
all reserved to the mayor, something you cannot enumerate).

6) Some choices even restrict the current rules, without
explanation. For instance, in the DNSSEC section, the public key is
mandatory, while RFC 4310 and RFC 4641 does not force the registrant
to send it to the registry.

---

From: Edward Lewis <[email-masked]>
Date: Wed, 27 Jan 2010 12:20:52 -0500

I appreciate seeing this level of comment.  This demonstrates the 
need for the broad external review that can be best accomplished 
within the IETF.  It also demonstrates that we have to travel quite a 
distance to accomplish the goal of an escrow "protocol" (nodding that 
protocol here does not imply specifying a transport layer protocol).

At 16:30 +0100 1/27/10, Stephane Bortzmeyer wrote:

>1) The biggest problem is that it is not policy-independant.

>could be interested in a format for IP registries.

When I consider the work item here I ask myself, "can I imagine my 
current employer (an ICANN gTLD operator and a ccTLD operator) 
assuming the operations for my previous employer (an RIR) for a 
6-month period in just a few days/weeks and then reversing the flow 
in a short time window?  That's certainly not a general case, but it 
is kind of what would be desirable to achieve.

>3) The draft goes in very low-level details...
>4) ...deciding on a format for <insert features>, ... if they are worth it.
>5) There is an obligation to ... the law - ...
>6) Some choices ... restrict ... current rules...

As a chair my first priority is process, so in as much as my opinions 
agree or disagree, I'll refrain from saying now.  I do want to 
highlight the implicit actions items Stephan has raised.

1 - Figure out how to separate data expression and policy
2 - Make this as general as possible within bounds of usefulness
3 - Target first interoperability
4 - Evaluate what's a requirement
5 - Evaluate this with the realization of the environments
6 - Review the specification for consistency with other specifications

Etc.

---

From: HiroHOTTA <[email-masked]>
Date: Thu, 28 Jan 2010 08:31:08 +0900

On Tue, 26 Jan 2010 18:17:06 +0100
> registries do have years of experience dealing with data in escrow.

and .JP runs its daily regitry data escrow as well.

Hiro

---

From: Christopher Browne <[email-masked]>
Date: Thu, 28 Jan 2010 18:48:39 -0500

> privacy provisions - or not), etc.

I originally wrote a fair chunk of it, and a lot of it remains after a
couple of layers of rewrites by others, so I can comment on why some of
these things were suggested.  Hopefully the perspective seems useful.

A number of the criticisms you're pointing at it fall from using
EPP-related specs as sources.  - Using whatever random status codes
anyone might want to use seems a bit too open-ended; - Using those from
RFC 5731 as a starting point seemed pretty appropriate.

The sets of attributes similarly derive from what's in the RFCs about
EPP.  I'll decline to quibble about which attributes are "very
important" or not - the factor determining their absence is that if they
weren't in a normative source such as RFC 4933 (or, I guess, 5733, now),
it would have been a leap to propose adding them, so I didn't.  It is
quite appropriate for this group to consider adding attributes that are
agreed to be important.

On the provreg list, there's a relevant parallel process going on...
There is discussion ongoing as to what sorts of extensions ought to be
consolidated into common RFCs, as different registries frequently
implement different custom extensions for one thing or another.

I would think that to be a proper thing to reference - common escrowed
data presumably begins with the sorts of data that are fairly universal
("included in base EPP RFCs" seems like a pretty good measure of that to
me), EPP extensions being a natural way to characterize, in a normative
fashion, things that are common additions.

As for the ACE-versus-Unicode issue, the perspective that I came from
was that it was necessary to capture the DNS data in the form in which
it will be passed around by BIND and the like, and that form is, at this
point, the ASCII-encoded form.  This isn't the time to get into detailed
debate about the handling of IDN variants and such, but that certainly
is an important complication.

> compression or encryption.

I wasn't very comfortable with this portion; when discussing it with
some of our operations folks, they were actually keen on putting in even
more details relating to error checking, resubmission, and such.  At one
point, I was seeing something akin to the file version numbers of VMS or
ISO9660 emerging, which seemed like *way* too much detail to go into,
even if we were embracing a "procedural" perspective.

That is definitely inappropriate at the IETF level.

But keep in mind that the origin of the document was as a proposal of
ICANN policy, and there are therefore things that could be apropos
there, even though they aren't appropriate to an IETF protocol process.

> instance RFC 5261 if the format is XML).

I suspect that there is a partitioning that should be done between
protocol and procedure, which might even appropriately cross
organizational layers.

That is, it could be appropriate to have:

a) An IETF protocol describing internals of format, and

b) An ICANN document that references the IETF material, which then
specifies (or suggests) usage patterns.

While I agree that full-versus-incremental is a performance
optimization, I would be disappointed if the possible need for awareness
of this was pushed out and treated as a purely out-of-band technical
mechanism.  It may be that recognizing "incremental aspects" at the
protocol/format level will not be terribly difficult, and can ease the
deployment of technical solutions.

When we're at the state of trying to define the work of the working
group, it's a bit early to conclude that this should certainly be left
out.

If I put my "have-done-escrow" hat on for the moment, I'll just comment
that I've never actually used "incremental deposit" to improve
performance.  It hasn't seemed worthwhile.  Every time hardware or
networks improve, the size of registry that would need "incremental"
increases.  Perhaps hardware's good enough that it doesn't matter
anymore.

On the other hand, putting on the "I have seen precedent" hat, ICANN has
described escrow processes on several occasions (two of which I examined
in a fair bit of detail), and each time they have described escrow, they
have included provision for incremental deposits.

> all reserved to the mayor, something you cannot enumerate).

There is certainly similarity in this case to the handling of IDN
variants, where there are frequently the same pair of possibilities:

a) The set of names restricted from registration are discretely
enumerable, and a list of "reasonable" size that may be listed in detail

b) The set of names restricted are not reasonably enumerable, such that
all that is "reasonable" to record is a reference to the algorithm
required to compute matches against the set

This will surely warrant further discussion.

> to send it to the registry.

The ongoing discussion of 4310bis on ietf-provreg indicates that there
is some ways to go before that all stabilizes!  No doubt the "IRE draft"
predates that discussion.
-- 
output = reverse("ofni.sailifa.ac" "@" "enworbbc")
Christopher Browne
Database Architect
Afilias Canada