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

[Christopher Browne <[e-mail]>]

Stephane Bortzmeyer <[e-mail]> writes:
> On Mon, Jan 25, 2010 at 05:40:06PM -0800,
>  by way of Paul Hoffman <[e-mail]> wrote 
>  a message of 36 lines which said:
>
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>
>> 	Title           : Internet Domain Registry Data Escrow specification
>
> 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.

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.

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

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.

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

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.

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

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.

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

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