Subject: [ire] progressing this work

From: James M Galvin <[email-masked]>
Date: Tue, 25 May 2010 14:44:14 -0400

Speaking as co-Chair, I would like to ask the question again
(perhaps for the last time) about progressing this work.  We had
some good discussion in Anaheim and we've had some good discussion
here on the mailing list.  The question remains as to whether or not
to progress this work in the IETF.

I believe there are three questions to be considered.

1. Is there work to be done?
2. Is there a community to do the work and use the result?
3. Does the work belong in the IETF?

The first question is whether or not there is work to be done.  I
sense there is enough agreement that the answer is yes.  Creating a
uniform standard for escrow data has value.  It has value for
service providers supporting multiple clients, who have a basis to
ensure they need to implement one escrow format.  It has value for
escrow agents who only need one set of tools to validate escrow
dumps.  It has value for recovery agents who only need one set of
tools to consume the escrow dumps so as to restore service when a
service provider fails.

While there have been folks who disagree with this subjective view
of value, I did not notice anyone who gave a technical reason as to
why such a standard would be bad.  If I missed it I would appreciate
it if someone could restate it.

This is important because folks are not required to participate in
standards work, particularly if you're not supportive of it.  But
not liking it and stating problems with it are two different things.

The second question is if there are folks who will do the work and
use the result.  The answer here is again yes.  There are at least two 
organizations represented by the Chairs who care about this work. 
Others have suggested on the list they are supportive.

This is not a large number but it does not need to be a large
number.  Even the IETF has had a fair number of working groups over
the years that have progressed work developed by a small number of
committed individuals.

As for users of the work, here is where it is important to mention
ICANN.  I'm certainly not in a position to speak for ICANN but it is
my understanding from messages I have seen on this list that if a
standard for data escrow is created that ICANN will adopt it and be 
migrating gTLDs to require its use.  I think the correct response to 
that is, "Yeah!"  It is great thing when you can create something that 
will actually get used.

The last question is whether or not this work belongs in the IETF.
I can respond to this question personally since I would not have
agreed to be a co-chair if I did not think this work belonged in the
IETF.

Speaking personally, I believe this work belongs in the IETF in part
because it is related to work the IETF has already accepted, i.e.,
EPP.  This data escrow work is about storing the information that is
transacted using EPP.  I believe it is best to keep the definition
of the escrow close to the home of the protocol that executes
transactions based on it.  While this work could be done in other
places, without the overlap with folks who worked on EPP we risk the
two specifications getting out of sync.  I would consider this bad.

I believe it belongs in the IETF because the IETF has a broad set of
expertise available that would be helpful to this work.  While the
IETF may not have the world's best data format experts, we do
understand problems associated with scaling better than any other
group I am aware of.  We have some large registries in our midst and
other registries getting larger (with potentially more on the
horizon).  The IETF also has a good sense of internationalization
issues across many protocols.  Some of the data to be escrowed
includes email addresses, domain names, and URLs.  No other group is
going to have experts readily available in all of these areas.

Additionally, one technical question I remember from the Anaheim
discussion was asking about the transport for moving the data escrow
deposits around.  It is because this question was asked that I think
the work belongs in the IETF.  There are technical, architectural
experts in the IETF that will ask questions about work that will not
come up in any other forum.

Finally, interoperability is an important mantra of the IETF and
this work needs interoperability.  The IETF insists on multiple
implementations of its standards.  The success of this work will
ultimately depend on interoperability since otherwise why do it?
Your co-chairs both work for companies that will implement this
standard if it is created.  I'm sure there will be others.  This
would be a harder sell in other fora.

It has been suggested that these reasons are underwhelming.  My
concern with that evaluation is it suggests that the reasons for
bringing work to the IETF need to be overwhelming.  I don't agree
that this is necessary.  I believe what is necessary is that there
be no negative consequences of doing work that has value.

Speaking again as co-chair, I obviously want to hear any comments
you have about what I said above.  I am especially interested in the
negative consequences of proceeding with this work.

Thanks for reading to the end!

Jim

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 25 May 2010 16:16:13 -0400

Dear colleagues,

I'm not likely actually to object to the WG getting formed, and anyway
I'm probably not one of the target consumers of a specification in
this area.  Nevertheless, as one of the previous wet blankets, I
thought it'd be correct for me to recite my reasoning.  

The fundamental reasons for not setting up a WG or undertaking this
work is that, despite the arguments Jim makes, it isn't clear that
there is work to do that is amenable to standardization except in the
narrowest sense; and even if that were clear, it isn't plain that the
IETF has the expertise needed for that work.  I think these arguments
were already made on list, but I address specific points below.  I've
cut liberally from Jim's original message.

> it if someone could restate it.

Nobody was saying a standard would be bad; but some of us certainly
suggested that we didn't understand what was to be standardized and
(more importantly) whether that standardization would turn out to be
just a little bit of framework with all the real interoperation
hinging on local extensions.  Alternatively, it seemed possible that
the plan was to standardize on something narrowly tailored to the
problems of certain industry participants in one corner of one
industry.  In the former case, I'm not convinced we're really talking
about "standards" in any useful sense; and in the latter, I think the
goal could be better addressed within the existing corner of the
relevant industry.  Said corner, I believe, holds regular meetings.

> not liking it and stating problems with it are two different things.

I think this argument ignores an important function of the barriers to
setting up an IETF WG.  WGs take resources, and some of those
resources necessarily draw from the same pool as other IETF work.
There's a trade-off in determining whether the value that accrues from
the additional (to-be) interoperable specification is worth the cost
to the rest of the community in the lost cycles dedicated to that
specification.  (I don't know where this work falls on the trade-off
spectrum, but it's in my view wrong just to ignore that
consideration.)

> that is, "Yeah!"  It is great thing when you can create something that  

The reason some of us have expressed scepticism so far is that ICANN
(or those with agreements with ICANN) seems to be the _only_ real user
for this proposed work.  There were suggestions that the protocol
ought to be more general purpose, and the answer was both that the
IETF doesn't really have the expertise and that anyway those groups
already have their own escrow specifications.  So this looks
remarkably like the case where ICANN is assuming that the IETF is its
standards supporting organization, as originally envisioned.  Some
people object to that.

I don't actually care if ICANN does that, but I note that it results
in significant negatives for any specification work:

    1.  Non-ICANN-policy people can feel marginalized and frustrated,
    and leave.  During the development of EPP, there was a significant
    registry that felt its needs were not accommodated, and as a
    consequence spent much of the time simply arguing that the planned
    specification wouldn't meet its needs.  I don't think it will
    profit us to rehash those arguments (and I don't have an opinion
    about their merits); all I'm noting is that this happened.

    2.  The requirements are at best foggy, because ICANN has very
    wide policy needs.  The result is a specification that only
    interoperates in principle.  The vast number of EPP extensions,
    many of which do the same thing, is again an indicator here.
    While it might be regarded as a success of the intent of EPP (I
    tend to view it that way), the fact is that the subtly different
    approaches in each extension are kind of a pain for implementers.
    A person new to the protocol might reasonably understand these
    different extensions as plain incompatible implementations, even
    if from the point of view of the protocol proper they're not. 

    3.  The specification is almost ossified as soon as ICANN adopts
    it.  EPP is again a useful example: during an early round of
    discussions of moving EPP along the standards track, I argued for
    some changes that some people thought were nice, but that
    certainly introduced a schema change.  The quite reasonable
    response was that, if we did that, ICANN would require the two
    versions of the protocol to be operated side by side, and nobody
    wanted that.  In effect, this means that ICANN's needs are poorly
    aligned with the IETF standards process, because ICANN wants a
    stable standard even if it's not quite right, and the IETF wants
    to be able to make major changes if a protocol needs work.

If this is just contract work for ICANN, why not just do it at ICANN?

> transacted using EPP.  

Surely that can't be right, or it would be an argument for including
billing servers, postal databases, and all manner of other things
obviously outside our collective competence.  Many EPP systems entail
accounting data, for instance, but that isn't a reason why standards
for accounting data interchange belong at the IETF.  And I'd be pretty
sceptical of anyone who claimed the IETF was a place to develop the
One True Way to escrow all data published on the web, even though
every single web page goes across a protocol that came from the IETF.

> two specifications getting out of sync.  I would consider this bad.

That sounds like an implicit scope narrowing from "registry escrow
specification" to "EPP escrow specification".  If that's what's
intended (it's not in any draft charter I've seen), then again I might
be a little more supportive.  

> While the IETF may not have the world's best data format experts, we
> do understand problems associated with scaling better than any other
> group I am aware of.  

Really?  You really think that we understand scaling of large data
interchanges better than, say, Oracle Corp?  Or the Transaction
Processing Council?

I think it is true that the IETF has deep and broad expertise in the
scaling of Internet protocols; and that therefore if this work were in
any way aiming at producing either on-the-wire protocols or something
that would seriously affect such protocols, your argument would have
some merit.  But the target work here can really only be a data
format, not a protocol.  I don't buy for an instant that the IETF has
any special expertise in scaling data systems.  On the contrary, from
what I have seen, many IETF people don't understand the first thing
about how you scale data systems and make them usable.  (That's ok.
This is not the TPC or the SQL committee.  Or even the database SIG at
some operations group like USENIX.)

> deposits around.  

I had the impression that the question was an opening for someone to
make an argument that a protocol was needed, since that would have
been a clear argument in favour of WG formation.  I thought the answer
(which I understood to be roughly, "What's wrong with sftp?") was that
no protocol was needed.  I took this to be a reason not to do the
work, in fact.

> would be a harder sell in other fora.

I cannot believe that.  The whole point of the work is to generate a
data interchange format.  Nobody who has that as a goal is going to
reject interoperation as one of the primary tasks.  The other SDOs in
the world don't go around ignoring interoperability: there would be no
"S" in their description if they did.

Best,

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Warren Kumari <[email-masked]>
Date: Tue, 25 May 2010 16:18:55 -0400

> 1. Is there work to be done?

Yes, I believe that there is.

> 2. Is there a community to do the work and use the result?

Again, yes, I believe so.

> 3. Does the work belong in the IETF?

Yes, I think that it does -- while things like data formats are not  
what the IETF usually deals with, it is important work for  
interoperability purposes, and is closely related to the EPP stuff.
I *think* that some of the objection and push-back we have heard is  
driven by a general dislike of ICANN and feelings that ICANN tasked  
the IETF with this work.

> use the result.  The answer here is again yes.
> There are at least two organizations represented by the Chairs who  
> care about this work. Others have suggested on the list they are  
> supportive.

In case I have not stated it publicly, I'll sign up for helping with  
the work...

> that is, "Yeah!"  It is great thing when you can create something  
> that will actually get used.
>

Fully agree..

> negative consequences of proceeding with this work.

Yes, what's that harm of us working on this in the IETF? If we design  
something truly horrendous, I cannot think of a group more qualified  
(and likely :-P) to point it out, and it's not like we are asking for  
huge resources...

> _______________________________________________
> ire mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ire

--
"Being the Fun-Police in the global Internet is a thankless - and  
probably futile - task."
  --  R. Whittle ("draft-whittle-sram-ip-forwarding-01.txt")

---

From: David Conrad <[email-masked]>
Date: Tue, 25 May 2010 15:00:33 -0700

Andrew,

On May 25, 2010, at 1:16 PM, Andrew Sullivan wrote:
> for this proposed work.  

So, you do not believe that a generalized escrow data format would be useful to registries that are not contractually bound to ICANN?  I thought some folks who run registries had already indicated that it would be useful -- maybe I'm misremembering.

> There were suggestions that the protocol
> IETF doesn't really have the expertise 

I don't get the argument suggesting the IETF doesn't have the expertise. The IETF isn't a thing with expertise. The IETF is a set of individuals who voluntarily agree to congregate to address commonly shared issues related to Internet technologies.  The individuals bring their own expertise and apply it as they deem appropriate.  In this case, there appears to be significant expertise already demonstrated.

> and that anyway those groups already have their own escrow specifications.  

The fact that other groups already have their own escrow specifications is exactly what demonstrates there is a need for standardization.

> So this looks
> standards supporting organization, as originally envisioned.  

Err, originally envisioned when/where?  The original envisioning was of something called the "Protocol Supporting Organization" that was intended to be "a group of open international Internet related standards development organizations (SDOs)" and initially included the IETF, W3C, ITU, and ETSI.

> Some people object to that.

My impression is that some people have a tendency to knee jerk whenever "ICANN" is mentioned. I'll admit I find it a bit tiresome.

> If this is just contract work for ICANN, why not just do it at ICANN?

ICANN generally looks to "the technical community" to define standards that it makes use of in technical contexts.  In many cases (since the "I" in ICANN stands for "Internet"), the standards are defined by the IETF.  Examples are many and include RFC 1591, the EPP RFCs, the IDNA RFCs, etc.  ICANN does, of course, look to other bodies for other forms of standardization (e.g., GAAP for accounting, ISO-3166 for the definition of ccTLD strings, etc).

As far as I can tell, raising ICANN in this context is mostly a red herring. Yes, ICANN-related entities would be beneficiaries of the output of IRE, but I don't see this as being an exclusively ICANN thing (if it was, I'd likely have a different opinion). As I've mentioned in other contexts, the questions really should be:

0) is the base protocol defined by the IETF?

My answer: yes (EPP)

1) is there a problem?

My answer: yes (multiple non-interoperable escrow specs seems sub-optimal to me)

2) do multiple independent parties need a standardized solution to that problem?

My answer: yes (a standardized solution would make future escrow efforts (definition, development, deployment) simpler)

3) are there folks who will work on a solution within the context of an IETF working group?

My answer: looks like it.

Regards,
-drc
(Working at (at least for 50 more days), but in no way representing ICANN)

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 25 May 2010 18:48:53 -0400

On Tue, May 25, 2010 at 03:00:33PM -0700, David Conrad wrote:
> 
> So, you do not believe that a generalized escrow data format would
> be useful to registries that are not contractually bound to ICANN?
> I thought some folks who run registries had already indicated that
> it would be useful -- maybe I'm misremembering.

Well, I did another quick glance through the archives before posting
earlier, and I didn't see the example you have remembered.  Maybe I
didn't go back far enough.  The obvious candidates, however, would be
RIRs or something like that, and I think they've been quiet.

> I don't get the argument suggesting the IETF doesn't have the
> expertise. The IETF isn't a thing with expertise. The IETF is a set
> of individuals 

Ok.  If you want me to talk in longer but more precise terms, "The
IETF does not seem to attract people with technical expertise in data
formats."  My evidence for this is that many of the data formats the
IETF produces aren't that great.
 
> The fact that other groups already have their own escrow
> specifications is exactly what demonstrates there is a need for
> standardization.

I'm not sure I buy that argument.  New things get deployed
operationally when someone has an itch to scratch.  If people have a
working escrow format, why in the world would they want to change it?
There's never revenue associated with escrow for the party sending it
-- this is pure cost.  So there's going to be automatic resistance to
altering any working systems.

Moreover, your argument does not address the other issue I mentioned,
which is that different specifications get worked out _because_ the
needs are different.  The result is that if you want to standardize,
your lowest common denominator is so low as to mean that everything
interesting is done in the local-only portion of the protocol.  This
is a trend we have seen to some extent in EPP.  See more on this at
the end of this mail.

> ICANN generally looks to "the technical community" to define
> standards that it makes use of in technical contexts.  In many cases

Well, yes, but I am asking whether that's a good thing for it to do,
when it has a problem that seems to have its boundaries lined up
nicely along the organizational boundary.  In this case, we seem to
have ICANN-and-its-clients but nobody else clamouring for this work.
It's work (data formats, and not protocol) with which the IETF has a
mixed record of success.  Moreover, a significant portion (all?) of the task
here is really to specify an interchange format for what is almost
certainly a relational database, and the IETF does not tend to attract
database experts either (and our database formats show that).

All of that said,

> 0) is the base protocol defined by the IETF?

if this is just supposed to be the EPP data escrow WG, then let's call
it that and be done.  The draft that we read before the BOF
(draft-arias-registry-data-escrow-00) was, in my view, incompletely
useful for EPP repositories and not at all for anything else.  But it
claimed it was doing registry data, and I have grave doubts that such
can ever be made usefully standardized (how will it work for people
not using EPP?  What about those who use non-standard extensions?).
So if we had a proposed charter that said something along the
following lines, I'd be more inclined to support such work (and maybe
even sign up to do some review):

    The Extensible Provisioning Protocol is a mechanism by which a client
    may request the provisioning of resources by a repository.  It is
    sometimes necessary to reconstruct all or part of a repository without
    the participation of the orignal repository operator.  In order to
    facilitate this, repositories occasionally make escrow desposits, in
    order that the contents of the repository can be reconstructed.

    There is no well-established data format for these repositories.
    The IRDE Working Group will produce such a data format, to support
    all the object mappings defined by IETF RFC documents.  Moreover,
    the IRDE WG will define rules by which new data formats can be
    generated for any EPP object mapping or extension.

> My answer: yes (multiple non-interoperable escrow specs seems sub-optimal to me)

But you're going to get non-interoperable escrow data from
non-interoperable repositories.  There is no way around this problem:
if you collect a bunch of data that I don't, then your data can't be
represented in my schema.  "So," you say, "let's take the superset."
But it's not obvious what the superset is.  For instance, the base EPP
protocol + mappings allow either that DNS NS records be properties of
domain names, or else that they be associations with other full-blown
objects (host objects) in the repository.  So to get the superset of
this, you have to have support for both approaches, and then have some
tricky way of signalling which approach you use.  Do this for every
local variation of implementation.  Soon, everything interesting is in
the local specification and not in the standard part.  That's not a
useful standard at all: it's worse than nothing, because you have all
this giant machinery with its attendant possibilities of bugs, and yet
everything has to be done as a local extension anyway.  

This is why I'm sceptical that something really usefully standard is
likely.  It's not some knee-jerk anti-ICANN bias: I don't think ICANN
is any worse than anything else we'd invent to do the same function.
But if we constrain the problem such that it's "just ICANN registry
functions" or something like that, I can't see why this is something
that wouldn't be better handled by those actually familiar with the
ICANN conditions; and if we don't so constrain the problem, then I
don't think anything will come of it that is usefully standard.
Unless, perhaps, we do some EPP-only thing as I suggested.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: NOGUCHI Shoji <[email-masked]>
Date: Wed, 26 May 2010 11:19:05 +0900

Hello, James-san.

On Tue, 25 May 2010 14:44:14 -0400

> 1. Is there work to be done?

Yes.

> 2. Is there a community to do the work and use the result?

Yes.

> 3. Does the work belong in the IETF?

Yes, I think that it does.

-- 
NOGUCHI Shoji <[email-masked]>

---

From: Daniel Kalchev <[email-masked]>
Date: Wed, 26 May 2010 09:15:48 +0300

I tend to agree with Andrew on the topic.

My personal perspective on this is as follows:

For our registry (BG), we do multi-site escrow of all data. The escrow 
is in multiple formats, including raw binary dumps, SQL dumps, schemas 
etc, amongst others. The escrow is also incremental. We go trough all 
this hassle, because:

- the raw formats let us restart the registry very quickly, at it's 
current state;
- non-raw formats let us reconstruct the registry, possibly in 
completely different environment -- different hardware, operating 
systems, database software, etc.

If there was a "standartized" format/protocol, we would have used it, as 
this could have saved us resources in developing our own format, escrow 
protocols and export/import tools.

In my opinion, defining data format only is useless. There are already 
too many available data formats, that can represent virtually any data 
structure. The escrow definition should include the data format and 
escrow protocol.Or rather, set of possible data formats and set of 
possible protocols. Implementations will build export, import and 
storage management tools, as well as servers and clients to handle the 
protocol.

Having set of data formats will let any 'registry' to escrow it's data, 
not only EPP registries.

On the question, whether there will be users: there are too many 
registries out there, that have not implemented any form of escrow. The 
typical advice to those is "go buy services from a certified escrow 
provider". This advice sort of implies "then, your escrow is certified". 
If there is published set of escrow formats and protocols, those 
registries may implement it and "be certified". Especially if ICANN 
adopts the protocol as sort of requirement or best practice.

If the working group should be created, it should work on escrow 
protocol(s), as well as escrow format(s). Oh, and schema(s) as well. :) 
This work may become big...

Daniel

---

From: David Conrad <[email-masked]>
Date: Wed, 26 May 2010 08:34:18 -0700

Daniel,

Sorry, I'm a bit confused.  Andrew is (as I understand it) arguing against the creation of a working group to standardize escrow, yet you say:

> If there was a "standartized" format/protocol, we would have used it, as this could have saved us resources in developing our own format, escrow protocols and export/import tools.

Which would seem to suggest you'd view the creation of the working group positively.  Could you clarify?

Thanks,
-drc

---

From: Jorge Cano <[email-masked]>
Date: Thu, 27 May 2010 16:07:56 -0500

> 3. Does the work belong in the IETF?

Yes, I believe there is work to be done and I believe there is a community to do the work and use it.
 
We (NIC Mexico) will use the output of this WG to standardize the way we escrow our data. 

It's important that this work is done in the IETF because I see it as a complement to EPP and being and IETF's work makes it an easy sell when we need to export our data.

Regards,
Jorge Cano

---

From: Daniel Kalchev <[email-masked]>
Date: Sun, 30 May 2010 21:59:41 +0300

David,

First, I don't think Andrew is opposed to the creation of this 
workgroup. I read his statements more on the side of his wondering 
whether such group will bring us more value than the cost it will incur. 
Perhaps the confusion comes from my imperfect use of English.

In any case, I do see value in having standartized escrow format AND 
protocol.

Some thoughts:
Perhaps, what is causing the confusion is the original desire by ICANN 
to have standartized specific kind of escrow, with possible specific 
policy framework. Achieving only this goal with the working group would 
be waste of resources in my opinion. Or, ICANN could just hire someone 
to produce the required (for their task) specification.
If things are to be handled by a more broad group, it's better to have 
result, that may be used by more parties, not just ICANN. In some 
future, ICANN may not even exist anymore, nor it's contracts. This will 
not automatically make escrow bad idea.

Daniel

---

From: "Michael Young" <[email-masked]>
Date: Mon, 31 May 2010 09:13:27 -0400

I share a similar interpretation of what Andrew is saying as Daniel has just stated.

Also, like Daniel I generally support see creation of a standardized escrow format and protocol AND do not see a superior alternative to the IETF in this case, all things considered.

However I think Andrew has a very valid point, narrowing this down to an EPP escrow and addressing the transport makes this much clearer and more appropriate work for the IETF resources. I think we also need to clearly define what this work won't do, for example, if its real purpose is continuity of a working TLD space when registry operators and/or registrars are no longer able to function, then I believe we need a very narrowed data set that DOES NOT include specific business information such as billing data.  It's important I believe to match the work to the mission objectives carefully.

Michael Young

 

-----Original Message-----
From: Daniel Kalchev [mailto:[email-masked]] 
Sent: Sunday, May 30, 2010 3:00 PM
To: David Conrad
Cc: [email-masked]
Subject: Re: [ire] progressing this work

David,

Some thoughts:

Daniel

---

From: James Gould <[email-masked]>
Date: Mon, 31 May 2010 15:36:37 +0200

I agree with Michael.  A standardized format and transport for escrow is
needed that is narrowed to EPP.  The data escrow should be as extensible as
EPP considering not all registries have the same data and all of the
relevant Registry information needs to be escrowed.  Ideally there would be
a base format defined (like EPP RFC 5730), a transport defined (like EPP RFC
5734), and a set of standard objects that are extensible (like EPP RFC 5731
– 5733).  The format should be less verbose as EPP XML to accommodate a much
larger dataset.   I also agree that this should not get into the business of
trying to capture business rules and billing data.

I see the need for a standard, but I’m still not convinced that the IETF is
the right place.  If the IETF does take this up I would certainly like to be
involved with the effort.

-- 

JG 

-------------------------------------------------------
James F. Gould
Principal Software Engineer
VeriSign Naming Services
[email-masked]
Direct: 703.948.3271
Mobile: 703.628.7063

21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

Notice to Recipient:  This e-mail contains confidential, proprietary and/or
Registry  Sensitive information intended solely for the recipient and, thus
may not be  retransmitted, reproduced or disclosed without the prior written
consent of  VeriSign Naming and Directory Services.  If you have received
this e-mail message in error, please notify the sender immediately by
telephone or reply e-mail and destroy the original message without making a
copy.  Thank you.

From: Michael Young <[email-masked]>
Date: Mon, 31 May 2010 09:13:27 -0400
To: Daniel Kalchev <[email-masked]>, David Conrad <[email-masked]>
Cc: <[email-masked]>
Subject: Re: [ire] progressing this work

I share a similar interpretation of what Andrew is saying as Daniel has just
stated.

Also, like Daniel I generally support see creation of a standardized escrow
format and protocol AND do not see a superior alternative to the IETF in
this case, all things considered.

However I think Andrew has a very valid point, narrowing this down to an EPP
escrow and addressing the transport makes this much clearer and more
appropriate work for the IETF resources. I think we also need to clearly
define what this work won't do, for example, if its real purpose is
continuity of a working TLD space when registry operators and/or registrars
are no longer able to function, then I believe we need a very narrowed data
set that DOES NOT include specific business information such as billing
data.  It's important I believe to match the work to the mission objectives
carefully.

Michael Young

-----Original Message-----
From: Daniel Kalchev [mailto:[email-masked]]
Sent: Sunday, May 30, 2010 3:00 PM
To: David Conrad
Cc: [email-masked]
Subject: Re: [ire] progressing this work

David,

Some thoughts:

Daniel

On 26.5.2010 г. 18:34, David Conrad wrote:
> Sorry, I'm a bit confused.  Andrew is (as I understand it) arguing against the
creation of a working group to standardize escrow, yet you say:
>
>   
>> If there was a "standartized" format/protocol, we would have used it, as this
could have saved us resources in developing our own format, escrow protocols and
export/import tools.

---

From: "Jiankang YAO" <[email-masked]>
Date: Tue, 1 Jun 2010 09:21:04 +0800

-----Original Message-----
From: Daniel Kalchev [mailto:[email-masked]] 
Sent: Sunday, May 30, 2010 3:00 PM
To: David Conrad
Cc: [email-masked]
Subject: Re: [ire] progressing this work

>In any case, I do see value in having standartized escrow format AND 

+1.
with the emergence of IDN TLDs and more gTLDs, the delegation and re-delegation of TLD may become popular.

Jiankang Yao