Subject: [ire] Minutes uploaded

From: Edward Lewis <[email-masked]>
Date: Tue, 13 Apr 2010 09:02:58 -0400

FYI, the minutes have been uploaded.

Just 103 more days until the next IETF!

Upcoming "important dates" for that meeting:

2010-04-26 (Week of): IETF Online Registration opens.
2010-04-26 (Monday):  Working Group and BOF scheduling begins.
2010-06-01 (Tuesday): Cutoff date for BOF proposal requests to ADs
2010-06-14 (Monday):  Cutoff date for requests to schedule WG meetings
2010-06-14 (Monday):  Cutoff date for Area Directors to approve BOFs

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

Wouldn't it be nice if all of the definitions of equivalence were the same?

---

From: Edward Lewis <[email-masked]>
Date: Mon, 19 Apr 2010 12:22:43 -0400

At 9:02 -0400 4/13/10, Edward Lewis wrote:

(I live for the snooze bar!)

Just 7 more days until the *scheduling* for IETF 78 begins.  Seven days!

Check it - from the key dates page:
     2010-04-26 (Monday):  Working Group and BOF scheduling begins.

When we left Anaheim, we had some work ahead of us to establish this 
work more firmly as fodder for a WG.  Having work to do is fine, 
executing and documenting it is even more important.

One of the principle, principal, err, most important things we need 
to get moving on is a framework for the escrow.  If I recall 
correctly, a bit more detail in this area would let "fence sitters" 
(those not sure if this might be a WG or not) get a better idea of 
the work ahead of us.

It's been a months since we left Anaheim, I think it's time to get 
some progress.  Also, in about 10 days we will be into a RIPE 
meeting, having been through a DNS-OARC and CENTR-Tech meeting where 
interest parties will be gathering.  Even more reason to show some 
progress.

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 19 Apr 2010 14:36:50 -0700

At 12:22 PM -0400 4/19/10, Edward Lewis wrote:
>When we left Anaheim, we had some work ahead of us to establish this work more firmly as fodder for a WG.  Having work to do is fine, executing and documenting it is even more important.
>
>One of the principle, principal, err, most important things we need to get moving on is a framework for the escrow.  If I recall correctly, a bit more detail in this area would let "fence sitters" (those not sure if this might be a WG or not) get a better idea of the work ahead of us.
>
>It's been a months since we left Anaheim, I think it's time to get some progress.  Also, in about 10 days we will be into a RIPE meeting, having been through a DNS-OARC and CENTR-Tech meeting where interest parties will be gathering.  Even more reason to show some progress.

Is there much interest from the parties that are currently required, or are likely to be required in the near future, that this be standardized? I heard a lot of pushback from those folks in Anaheim.

My interest in this work is as a neutral party who would want to become a trusted escrow agent for the registries. That means that I have no downside risk from the IETF creating the format, and some good upside possibility (assuming we do it right). That only gives *me* incentive for this work to happen; it is not at all sufficient for the IETF to take it on. Without the more-directly affected stakeholders wanting to help in an open environment, forming a WG is not a good idea.

--Paul Hoffman, Director
--VPN Consortium

---

From: Francisco Arias <[email-masked]>
Date: Mon, 19 Apr 2010 23:46:48 -0700

I'm working on having something out in a couple of weeks. Sorry for the
delay.

__ 
Francisco

---

From: Francisco Arias <[email-masked]>
Date: Mon, 19 Apr 2010 23:49:59 -0700

Hi, Paul.

I got a different feeling from the meeting. There was a good number of
registries gTLDs and ccTLDs and at least one RIR interested on this.

__ 
Francisco

On 4/19/10 2:36 PM, "Paul Hoffman" <[email-masked]> wrote:

>> When we left Anaheim, we had some work ahead of us to establish this work
>> more firmly as fodder for a WG.  Having work to do is fine, executing and
>> documenting it is even more important.
>> 
>> One of the principle, principal, err, most important things we need to get
>> moving on is a framework for the escrow.  If I recall correctly, a bit more
>> detail in this area would let "fence sitters" (those not sure if this might
>> be a WG or not) get a better idea of the work ahead of us.
>> 
>> It's been a months since we left Anaheim, I think it's time to get some
>> progress.  Also, in about 10 days we will be into a RIPE meeting, having been
>> through a DNS-OARC and CENTR-Tech meeting where interest parties will be
>> gathering.  Even more reason to show some progress.
> 
> Is there much interest from the parties that are currently required, or are
> likely to be required in the near future, that this be standardized? I heard a
> lot of pushback from those folks in Anaheim.
> 
> My interest in this work is as a neutral party who would want to become a
> trusted escrow agent for the registries. That means that I have no downside
> risk from the IETF creating the format, and some good upside possibility
> (assuming we do it right). That only gives *me* incentive for this work to
> happen; it is not at all sufficient for the IETF to take it on. Without the
> more-directly affected stakeholders wanting to help in an open environment,
> forming a WG is not a good idea.
> 
> --Paul Hoffman, Director
> --VPN Consortium
> _______________________________________________
> ire mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ire
>

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 20 Apr 2010 07:25:18 -0700

>registries gTLDs and ccTLDs and at least one RIR interested on this.

I'm quite happy to be shown to be wrong about my impressions; that would help us for a WG to get real work done. Let them speak up here.

--Paul Hoffman, Director
--VPN Consortium

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 20 Apr 2010 12:16:03 -0400

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Paul Hoffman
> Sent: Tuesday, April 20, 2010 10:25 AM
> To: Francisco Arias; Edward Lewis; [email-masked]
> Subject: Re: [ire] Prodding by one of the chairs
> 
> I'm quite happy to be shown to be wrong about my impressions; 
> that would help us for a WG to get real work done. Let them 
> speak up here.

I'm not yet convinced that there's work here for the IETF.

Scott

---

From: Francisco Arias <[email-masked]>
Date: Tue, 20 Apr 2010 10:59:32 -0700

Hello, Scott.

Why not?

__ 
Francisco

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 21 Apr 2010 07:11:49 -0400

Primarily because there are working escrow implementations, such as the
one developed to meet the requirements of the .COM agreement between
VeriSign and ICANN*, already in place.  I'm not convinced that there's
enough benefit in a new escrow data format to outweigh the cost to
define, implement, and deploy it.

*
http://www.icann.org/en/tlds/agreements/verisign/appendix-02-23jun09-en.
htm

Scott

> From: Francisco Arias [mailto:[email-masked]] 
> Sent: Tuesday, April 20, 2010 2:00 PM
> To: Hollenbeck, Scott; Paul Hoffman; [email-masked]

---

From: David Conrad <[email-masked]>
Date: Wed, 21 Apr 2010 09:21:35 -0700

Scott,

On Apr 21, 2010, at 4:11 AM, Hollenbeck, Scott wrote:
> VeriSign and ICANN*, already in place.

I think the issue is that there are multiple escrow implementations and that it would probably be nice to standardize as that would likely facilitate a bunch of good things.

Regards,
-drc
Speaking personally

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 21 Apr 2010 13:48:45 -0400

> From: David Conrad [mailto:[email-masked]] 
> Sent: Wednesday, April 21, 2010 12:22 PM
> To: Hollenbeck, Scott
> Cc: Francisco Arias; [email-masked]
> > Primarily because there are working escrow implementations, such as 
> > the one developed to meet the requirements of the .COM agreement 
> > between VeriSign and ICANN*, already in place.
> 
> I think the issue is that there are multiple escrow 
> implementations and that it would probably be nice to 
> standardize as that would likely facilitate a bunch of good things.

Maybe, but "nice" and "good" are relative terms.

Scott

---

From: "Papac, Krista" <[email-masked]>
Date: Wed, 21 Apr 2010 23:58:06 -0400

I'm not sure what is meant by "multiple escrow implementations".  Escrow, for the most part, is fairly consistent across Registries and is exactly the same for all depositing Registrars.  I don't see why this consistency can't continue into the future.

Krista Papac 
Iron Mountain Digital 
5530 Bandini Blvd 
Bell, CA  90201  US 
Home Office: +1.714.846.8780 
Mobile: +1.714.865.7655 
Fax: +1.323.443.3573 
[email-masked] 
 
"Software Escrow for Dummies" - order your complimentary copy today at www.ironmountain.com/escrowfordummies
 
New Gartner Report: Successful Software Escrow Requires Planning and Negotiation
Gartner advises: "It is also important that the licensee continue to track the software vendor's financials and viability annually, because any signs of financial problems would justify the cost of verification services." Continue reading the full report at: http://www.gartner.com/technology/media-products/reprints/ironmountain/170569.html

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of David Conrad
Sent: Wednesday, April 21, 2010 9:22 AM
To: Hollenbeck, Scott
Cc: [email-masked]
Subject: Re: [ire] Prodding by one of the chairs

Scott,

Regards,
-drc
Speaking personally

_______________________________________________
ire mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ire
-----------------------------------------
The information contained in this email message and its attachments
is intended only for the private and confidential use of the
recipient(s) named above, unless the sender expressly agrees
otherwise.
Transmission of email over the Internet is not a secure
communications medium. If you are requesting or have requested the
transmittal of personal data, as defined in applicable privacy laws
by means of email or in an attachment to email, you must select a
more secure alternate means of transmittal that supports your
obligations to protect such personal data. 
If the reader of this message is not the intended recipient and/or
you have received this email in error, you must take no action
based on the information in this email and you are hereby notified
that any dissemination, misuse or copying or disclosure of this
communication is strictly prohibited. If you have received this
communication in error, please notify us immediately by email and
delete the original message.

---

From: David Conrad <[email-masked]>
Date: Wed, 21 Apr 2010 21:08:17 -0700

Krista,

Does "this consistency" include present and/or future cases where ccTLDs, address registries, etc. are escrowing data?

Regards,
-drc

---

From: "Papac, Krista" <[email-masked]>
Date: Thu, 22 Apr 2010 00:13:56 -0400

We currently have some ccTLD customers and yes I am including them.  In respect to address registries, or IDNs (I'm guessing you are asking about them too), there currently aren't specs for these situations but that shouldn't prevent us from creating a spec for where consistency is required for these additional data fields.  

Krista Papac 
Iron Mountain Digital 
5530 Bandini Blvd 
Bell, CA  90201  US 

-----Original Message-----
From: David Conrad [mailto:[email-masked]] 
Sent: Wednesday, April 21, 2010 9:08 PM
To: Papac, Krista
Cc: [email-masked]
Subject: Re: [ire] Prodding by one of the chairs

Krista,

Regards,
-drc

---

From: Francisco Arias <[email-masked]>
Date: Wed, 21 Apr 2010 21:26:23 -0700

Currently each gTLD has its own data escrow format, for example, there are ones that use colon separated data, there are others that use XML and others that use SQL dumps. JP also uses XML.

Even those that use XML, that are the majority, do not necessarily have the same spec.

__
Francisco

On 4/21/10 8:58 PM, "Krista Papac" <[email-masked]> wrote:

Krista Papac
Iron Mountain Digital
5530 Bandini Blvd
Bell, CA  90201  US

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of David Conrad
Sent: Wednesday, April 21, 2010 9:22 AM
To: Hollenbeck, Scott
Cc: [email-masked]
Subject: Re: [ire] Prodding by one of the chairs

Scott,

Regards,
-drc
Speaking personally

---

From: David Conrad <[email-masked]>
Date: Wed, 21 Apr 2010 21:29:03 -0700

Krista,

On Apr 21, 2010, at 9:13 PM, Papac, Krista wrote:
> there currently aren't specs for these situations but that shouldn't prevent us from creating a spec for where consistency is required for these additional data fields.  

I believe that's the point of the working group.

Regards,
-drc

---

From: "Papac, Krista" <[email-masked]>
Date: Thu, 22 Apr 2010 00:40:55 -0400

Currently Iron Mountain escrows for 13 of the 16 gTLDs that are required to deposit.  Of those 13, which comprise the majority of both registries and domain names registered, 2 escrow in CSV and 11 in XML.
Additionally, there are well over 800 registrars escrowing with Iron Mountain and ALL of them escrow in CSV.
I agree that the registry specs vary, but not that significantly and the variance is largely due to uncoordinated writing of the specs rather than data requirements.
The registrar spec was thought out in advance and therefore they all have the same spec.

Krista Papac
Iron Mountain Digital
5530 Bandini Blvd
Bell, CA  90201  US
Home Office: +1.714.846.8780
Mobile: +1.714.865.7655
Fax: +1.323.443.3573
[email-masked]<mailto:[email-masked]>

"Software Escrow for Dummies" - order your complimentary copy today at <http://www.ironmountain.com/escrowfordummies> www.ironmountain.com/escrowfordummies<http://www.ironmountain.com/escrowfordummies>

________________________________
From: Francisco Arias [mailto:[email-masked]]
Sent: Wednesday, April 21, 2010 9:26 PM
To: Papac, Krista; David Conrad; Hollenbeck, Scott
Cc: [email-masked]
Subject: Re: [ire] Prodding by one of the chairs

__
Francisco

Krista Papac
Iron Mountain Digital
5530 Bandini Blvd
Bell, CA  90201  US

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of David Conrad
Sent: Wednesday, April 21, 2010 9:22 AM
To: Hollenbeck, Scott
Cc: [email-masked]
Subject: Re: [ire] Prodding by one of the chairs

Scott,

Regards,
-drc
Speaking personally

---

From: Francisco Arias <[email-masked]>
Date: Wed, 21 Apr 2010 21:57:40 -0700

Krista, you are right about the unified CSV spec for ICANN accredited
registrars. In fact, the current draft spec for new gTLDs that I put in
Internet-Draft format for this group is based on the registrar's one, up to
certain point.

As it has been mentioned before, the idea of forming this group is to define
a spec that could be used by gTLDs, ccTLDs and maybe other types of
registries.

Storing the data with a data escrow agent is just the fist step. The
ultimate goal is to be able to do something useful with the data should the
need be. Having a well defined and unified spec will certainly help on that
regard.

__ 
Francisco

On 4/21/10 9:40 PM, "Krista Papac" <[email-masked]> wrote:

> Currently Iron Mountain escrows for 13 of the 16 gTLDs that are required to
> deposit.  Of those 13, which comprise the majority of both registries and
> domain names registered, 2 escrow in CSV and 11 in XML.
> I agree that the registry specs vary, but not that significantly and the
> variance is largely due to uncoordinated writing of the specs rather than data
> requirements.
> [email-masked] <mailto:[email-masked]>
>  
> ³Software Escrow for Dummies² - order your complimentary copy today at
> <http://www.ironmountain.com/escrowfordummies>
> www.ironmountain.com/escrowfordummies
> <http://www.ironmountain.com/escrowfordummies>
>  
> Gartner advises: ³It is also important that the licensee continue to track the
> software vendor¹s financials and viability annually, because any signs of
> financial problems would justify the cost of verification services.² Continue
> reading the full report at:
> http://www.gartner.com/technology/media-products/reprints/ironmountain/170569.
> html 
> <http://www.gartner.com/technology/media-products/reprints/ironmountain/170569
> .html> 
>  
> 
> 
> Currently each gTLD has its own data escrow format, for example, there are
> ones that use colon separated data, there are others that use XML and others
> that use SQL dumps. JP also uses XML.
> 
> I'm not sure what is meant by "multiple escrow implementations".  Escrow, for
> the most part, is fairly consistent across Registries and is exactly the same
> for all depositing Registrars.  I don't see why this consistency can't
> continue into the future.
> 
> Krista Papac
> Iron Mountain Digital
> 5530 Bandini Blvd
> Bell, CA  90201  US
> Gartner advises: "It is also important that the licensee continue to track the
> software vendor's financials and viability annually, because any signs of
> financial problems would justify the cost of verification services." Continue
> reading the full report at:
> http://www.gartner.com/technology/media-products/reprints/ironmountain/170569.
> html
> 
> I think the issue is that there are multiple escrow implementations and that
> it would probably be nice to standardize as that would likely facilitate a
> bunch of good things.
> 
> Regards,
> -drc
> Speaking personally
> 
> The information contained in this email message and its attachments is
> intended only for the private and confidential use of the recipient(s) named
> above, unless the sender expressly agrees otherwise. Transmission of email
> over the Internet is not a secure communications medium. If you are requesting
> or have requested the transmittal of personal data, as defined in applicable
> privacy laws by means of email or in an attachment to email, you must select a
> more secure alternate means of transmittal that supports your obligations to
> protect such personal data. If the reader of this message is not the intended
> recipient and/or you have received this email in error, you must take no
> action based on the information in this email and you are hereby notified that
> any dissemination, misuse or copying or disclosure of this communication is
> strictly prohibited. If you have received this communication in error, please
> notify us immediately by email and delete the original message.
>

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 22 Apr 2010 07:36:31 -0400

> Behalf Of David Conrad
> Sent: Thursday, April 22, 2010 12:29 AM
> To: Papac, Krista
> Cc: [email-masked]
> > there currently aren't specs for these situations but that 
> shouldn't prevent us from creating a spec for where 
> consistency is required for these additional data fields.  
> 

This touches on the thing that I still don't understand:  there are
existing specifications for registry (multiple formats) and registrar
(standard format) data escrow that were developed outside the IETF using
some process.  Some people feel that there's a need for a standard
registry escrow data format specification.  Why is the process that was
used to develop the registrar specification inadequate?  What were the
specific issues with that process that makes the IETF process more
suitable to do the work?

In other words, I'd really like to ask the people who think that there's
IETF work here to please support their position.  For whatever it's
worth, I do believe there's value in having a standard format for escrow
of registry technical data.  I'm less convinced of the value when we
start talking about business and/or financial data, but we can debate
that later.

Scott

---

From: "Michael Young" <[email-masked]>
Date: Thu, 22 Apr 2010 08:23:13 -0400

Scott my take on it is that there is good precedent for the IETF to provide
the forum for the development of related technical specifications given past
registry and DNS endeavors.  ICANN is certainly not a body that was created
with the idea of handling the development of said specifications.  EPP and
DNS related RFCs are directly referred to within all ICANN registry
contracts.  Some of the very same people that formed the IETF also helped
formed ICANN, I think it was pretty clear they expected technical
specifications to handled by technical people in the IETF forum and not by
policy folks in the ICANN forum.

Escrow was one of the after-thoughts that I believe slipped through the
cracks, it should have been fully developed in the IETF in the first place,
by implementers that know what the consequences of what they are specifying.
The IETF forum also allows neutral participation by ccTLD registry operators
and registrars as well the g/sTLDs under operational contracts with ICANN.

As far as the general work goes, it meets the criteria as far as I can see.
It's clearly internet related, it's a technical specification that a known
internet community can benefit from being standardized (that we have
interested volunteers from) and it's a project for which we can achieve a
well defined scope (although like you I think this is about registry data,
not business or financial).

Does that answer the question?

Thanks

Michael Young

-----Original Message-----
From: Hollenbeck, Scott [mailto:[email-masked]] 
Sent: Thursday, April 22, 2010 7:37 AM
To: David Conrad
Cc: [email-masked]
Subject: Re: [ire] Prodding by one of the chairs

Scott

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 22 Apr 2010 08:35:51 -0400

> From: Michael Young [mailto:[email-masked]] 
> Sent: Thursday, April 22, 2010 8:23 AM
> To: Hollenbeck, Scott; 'David Conrad'
> Cc: [email-masked]
> Subject: RE: [ire] Prodding by one of the chairs
> 
> Scott my take on it is that there is good precedent for the 
> IETF to provide the forum for the development of related 
> technical specifications given past registry and DNS 
> endeavors.  ICANN is certainly not a body that was created 
> with the idea of handling the development of said 
> specifications.  EPP and DNS related RFCs are directly 
> referred to within all ICANN registry contracts.  Some of the 
> very same people that formed the IETF also helped formed 
> ICANN, I think it was pretty clear they expected technical 
> specifications to handled by technical people in the IETF 
> forum and not by policy folks in the ICANN forum.
> 
> Escrow was one of the after-thoughts that I believe slipped 
> through the cracks, it should have been fully developed in 
> the IETF in the first place, by implementers that know what 
> the consequences of what they are specifying.
> The IETF forum also allows neutral participation by ccTLD 
> registry operators and registrars as well the g/sTLDs under 
> operational contracts with ICANN.
> 
> It's clearly internet related, it's a technical specification 
> that a known internet community can benefit from being 
> standardized (that we have interested volunteers from) and 
> it's a project for which we can achieve a well defined scope 
> (although like you I think this is about registry data, not 
> business or financial).
> 

Incompletely - while you described the benefits of the work being done
in the IETF (assuming that the scope is narrowed to technical data I
understand those benefits), you didn't describe any issues with the
process that was used to develop the registrar specification.  Did you
take part in that effort?

Original message included below for context...

Scott

> Behalf Of 
> > David Conrad
> > shouldn't prevent us from creating a spec for where consistency is 
> > required for these additional data fields.
> > 
> This touches on the thing that I still don't understand:  
> there are existing specifications for registry (multiple 
> formats) and registrar (standard format) data escrow that 
> were developed outside the IETF using some process.  Some 
> people feel that there's a need for a standard registry 
> escrow data format specification.  Why is the process that 
> was used to develop the registrar specification inadequate?  
> What were the specific issues with that process that makes 
> the IETF process more suitable to do the work?
> 
> In other words, I'd really like to ask the people who think 
> that there's IETF work here to please support their position. 
>  For whatever it's worth, I do believe there's value in 
> having a standard format for escrow of registry technical 
> data.  I'm less convinced of the value when we start talking 
> about business and/or financial data, but we can debate that later.
> 
> Scott

---

From: "Michael Young" <[email-masked]>
Date: Thu, 22 Apr 2010 08:42:32 -0400

I can only comment as far as I have, sorry, as I did not work on the
registrar specification. Hopefully others can chime in on that piece.

Michael

-----Original Message-----
From: Hollenbeck, Scott [mailto:[email-masked]] 
Sent: Thursday, April 22, 2010 8:36 AM
To: Michael Young
Cc: [email-masked]
Subject: RE: [ire] Prodding by one of the chairs

Scott

---

From: "Yao Jiankang" <[email-masked]>
Date: Thu, 22 Apr 2010 21:09:10 +0800

----- Original Message ----- 
From: "Hollenbeck, Scott" <[email-masked]>
To: "David Conrad" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, April 22, 2010 7:36 PM
Subject: Re: [ire] Prodding by one of the chairs

>IETF work here to please support their position. 
yes, I think that there is some value to be done in IETF.
the uniform of escrow is good for all kinds of domain related organization and services.

> For whatever it's
>of registry technical data.

+1

---

From: "Papac, Krista" <[email-masked]>
Date: Thu, 22 Apr 2010 10:53:21 -0400

I am not familiar with the process that was used to develop the registrar spec, but what I do know is the spec was developed by the Registrar Liaison office.  Mike Zupke was responsible for executing and delivering on all aspects Registrar Data Escrow.  I "believe" he wrote the spec, but assume he consulted with others in the ICANN organization.  

Maybe Francisco can look further into this???

Krista Papac 
Iron Mountain Digital 
5530 Bandini Blvd 
Bell, CA  90201  US 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael Young
Sent: Thursday, April 22, 2010 5:43 AM
To: 'Hollenbeck, Scott'
Cc: [email-masked]
Subject: Re: [ire] Prodding by one of the chairs

Michael

-----Original Message-----
From: Hollenbeck, Scott [mailto:[email-masked]] 
Sent: Thursday, April 22, 2010 8:36 AM
To: Michael Young
Cc: [email-masked]
Subject: RE: [ire] Prodding by one of the chairs

Scott

---

From: David Conrad <[email-masked]>
Date: Thu, 22 Apr 2010 09:12:02 -0700

Krista and Scott,

I think the idea here is that a data escrow standard defined by a neutral 3rd party like the IETF could be used by more folks than just ICANN and the ICANN contracted parties.  Further, I personally believe folks who participate in the IETF (who may not show up in ICANN-related forums) have expertise in the areas of data definition and use and that could be quite helpful in providing a more generally useful specification.

Regards,
-drc
Speaking personally

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 22 Apr 2010 12:33:36 -0400

Dear colleagues,

I think I agree with Scott that the arguments in favour of a WG to
undertake work in this area still seem underwhelming.  I'm picking on
Michael below because his message was a handy summary of certain
arguments that I think need strengthening before there's a good
argument for a WG (and because I know he can take it ;-)

On Thu, Apr 22, 2010 at 08:23:13AM -0400, Michael Young wrote:

> contracts.  

We had a bar BOF at Anaheim in which people were arguing that a number
of different, incompatible extensions have emerged under EPP.  One way
to interpret that state of affairs is that the IETF ought to undertake
to unify the specifications.  But _another_ way to look at the
evidence is that EPP worked: it's extensible, and people have added a
lot of extensions because they had different local needs.  In the same
way, the multiplicity of escrow formats could reasonably be
interpreted as an indication that different agreements required
different responses, and therefore the escrow rules are different.

Even if one didn't think that the different formats were really
necessary, there's the additional matter of cost.  It will not be free
for people conforming to a current agreement to modify their systems
to support a new format.  What is the incentive to do this?  (Can
anyone say "IRIS"?)

That DNS is cited all over ICANN agreements is sort of irrelevant:
the DNS was specified long before ICANN was even a gleam in
politicians' eyes, and ICANN was formed to allocate names in one part
of the DNS.

> policy folks in the ICANN forum.

The IETF is not the ICANN protocol-definition service.  I have no idea
what was supposed by those who set up ICANN, but the IETF does not
have a responsibility to perform protocol-definition work for ICANN.
If ICANN has an ICANN-specific protocol it needs developed, it should
go and develop it on its own.  (Moreover, one might be excused for
thinking that part of the problem ICANN has is that it has only policy
people and no technical people informing those policies.  I don't
actually think that, but I know lots of people who do.)  So there
needs to be a significant indication that the work benefits someone
other than just ICANN for it to be plausible that we need a general
format here.  If the upshot is that there are several completely
different formats to be defined, we don't need an IETF WG: the
different communities of interest need to go and develop a format that
fits their different needs.

That said, I had the impression from the room at Anaheim that there
were two other arguments in favour of taking this on in the IETF:

1.  There is a wide variety of different escrow needs, and therefore a
general-purpose escrow framework would be a good thing.  (This has
variations: some people would narrow the purpose to general
Internet-registry framework, for instance.  I think the more
constrained the work, the more defensible.)  This is roughly the
argument I note above to be needed; but I didn't see a lot of people
in the room clamouring for this format who weren't involved in domain
name registry operations.

2.  There is a serious interoperation issue here, because in the event
of takeover of an Internet registry, a new operator needs to be able
to get hold of the old data and read it reliably.

Both of those are potentially good arguments as to why an escrow
format is needed, but neither is a good argument for why it is work
that belongs at the IETF.  The IETF is mostly good at network
protocols: things on the wire.  There's really very little (no?) wire
format here.  (1) above actually suggests that the right place for
this is some sort of data-interchange forum, of the sort that database
systems people are good at.  The reliability of (2) actually seems to
me to require that kind of datatype expertise too, and I'm not sure
the IETF is the right forum for it either.

> internet community can benefit from being standardized (that we have

I don't think that being Internet related or benefitting an Internet
community are what the IETF is for.  There's more than one completely
separate standards development organization (W3C and XMPP Standards
Foundation come to mind) that could also serve that goal.  The IETF is
good at protocols on the wire.  In my view, it's less good the further
from "on the wire" one gets.  Apart from transmitting escrow data
(which, I think, involves ssh and probably not much more), there is no
wire here.

A

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

---

From: Francisco Arias <[email-masked]>
Date: Thu, 22 Apr 2010 09:41:22 -0700

Krista,

The data escrow spec for ICANN-accredited registrars was developed in
collaboration between the registrar constituency and ICANN staff. Mike was
the project leader for that effort.

__ 
Francisco

On 4/22/10 7:53 AM, "Krista Papac" <[email-masked]> wrote:

> I am not familiar with the process that was used to develop the registrar
> spec, but what I do know is the spec was developed by the Registrar Liaison
> office.  Mike Zupke was responsible for executing and delivering on all
> aspects Registrar Data Escrow.  I "believe" he wrote the spec, but assume he
> consulted with others in the ICANN organization.
>

---

From: Peter Koch <[email-masked]>
Date: Thu, 22 Apr 2010 20:46:14 +0200

On Thu, Apr 22, 2010 at 12:33:36PM -0400, Andrew Sullivan wrote:

> undertake work in this area still seem underwhelming.

I would like to join this point of view.

> lot of extensions because they had different local needs.  In the same

The problem here is that either the proposed work has to lean itself
towards a particular segment of the registration/domain industry or it
has to be so flexible (extensible, if you wish) that the outcome might
be a framework only where the gory details happen in local customizations
all over the place.

> The IETF is not the ICANN protocol-definition service.  I have no idea

Nicely put. Agree with this, except that I doubt ...

> go and develop it on its own.

... this is the right next step, depending on how "specific" it is.

First, i currently can't see we are really talking about protocol development,
  but rather data formats.
Second, external timelines don't play well with IETF process (or vice versa).
Third, it is still unclear to me _what_ ought to be dealt with, which needs
  to be defined before addressing any formats.  We've heard "technical
  registration data" to "anything that allows continuation or re-instatiation
  of services".

> different formats to be defined, we don't need an IETF WG: the

+1;

> the IETF is the right forum for it either.

Neither am I, but to emphasize: this is not to send anybody elsewhere
just to avoid the work being done in the IETF.  Finding the appropriate
venue is second to determining that there's standards work to do at all.
If that's positive, the IETF is probably not the worst candidate to look at.

-Peter

---

From: David Conrad <[email-masked]>
Date: Thu, 22 Apr 2010 11:55:23 -0700

On Apr 22, 2010, at 9:33 AM, Andrew Sullivan wrote:
> But _another_ way to look at the

This would appear to argue that the nice thing about standards is there are so many to choose from.  I believe the difference here is that extensions to EPP are done within a defined framework that was specified created to facilitate them.  The different escrow formats is, I believe, a function of organic growth without much thought as to what was being grown.

> So there
> format here.

So, the issue here is a bit subtle.  ICANN's interest in a data escrow format is because we require contracted parties to escrow data -- my impression is that we're trying to make lives easier for those parties.  ICANN (mostly) doesn't care about the format because we aren't the folks who need to generate and consume the data -- the contracted registries and registrars are.  However, I personally believe that if a generalized format was defined, other folks (non-contracted DNS registries, address registries, etc.) would see benefit in making use it.

> general-purpose escrow framework would be a good thing. 
> ...
> 2.  There is a serious interoperation issue here
> ...
> format here.

An interesting distinction and one I'm not sure I agree with.  Your observation would appear to disallow efforts such as NETCONF from being discussed within the IETF.  The IETF has a long, robust history of defining data formats from the master file format to IANA registries to IDN tables.  I'm not sure I see the difference.

Regards,
-drc

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 22 Apr 2010 15:20:25 -0400

> venue is second to determining that there's standards work to do at all.

I agree with this, but I do worry about the expertise issues.
Speaking as a recovering database geek, I actually find the "storage"
data formats that the IETF has previously come up with to be somewhat
awkward.  It would be awful nice to get real database eyes on any
escrow format (since the database people are going to have to produce
and consume it), and I have doubts we have a lot of those hereabouts.

A

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

---

From: David Conrad <[email-masked]>
Date: Thu, 22 Apr 2010 12:20:53 -0700

Peter,

> be a framework only where the gory details happen in local customizations

My impression is that core registration data is fairly consistent across pretty much everything that might be registered, e.g., name, address, contact information, expiration, etc.  Yes, extensions off that core can be wildly varying.

Regards,
-drc

---

From: "Michael Young" <[email-masked]>
Date: Thu, 22 Apr 2010 15:45:48 -0400

BTW some of the draft work submitted for consideration was done by Chris
Browne - so that's at least one!

-----Original Message-----
From: Andrew Sullivan [mailto:[email-masked]] 
Sent: April-22-10 3:20 PM
To: [email-masked]
Subject: Re: [ire] Prodding by one of the chairs

A