<<<
Chronological Index
>>> <<<
Thread Index
>>>
Re: [gnso-thickwhoispdp-wg] in preparation for the call tomorrow
- To: "Neuman, Jeff" <Jeff.Neuman@xxxxxxxxxx>, "'Rick Wesson'" <rick@xxxxxxxxxxxxxxxxxxxxxxxx>, Avri Doria <avri@xxxxxxx>
- Subject: Re: [gnso-thickwhoispdp-wg] in preparation for the call tomorrow
- From: Volker Greimann <vgreimann@xxxxxxxxxxxxxxx>
- Date: Fri, 18 Oct 2013 15:19:22 +0200
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Hi Jeff,<br>
<br>
thank you for this detailed information which confirmed our basic
assumptions leading up to our report. Very helpful!<br>
<br>
Best regards,<br>
<br>
Volker<br>
<br>
<br>
</div>
<blockquote
cite="mid:AA2CD321EE9B1F4D99ECFC1A2B0342322405B0@xxxxxxxxxxxxxxxxxxxxxxxxxx"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta name="Generator" content="Microsoft Word 14 (filtered
medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]-->
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Cambria;
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:Garamond;
panose-1:2 2 4 4 3 3 1 1 8 3;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
h4
{mso-style-priority:9;
mso-style-link:"Heading 4 Char";
margin-top:6.0pt;
margin-right:0in;
margin-bottom:6.0pt;
margin-left:1.0in;
text-align:justify;
text-indent:-1.0in;
page-break-after:avoid;
font-size:12.0pt;
font-family:"Tahoma","sans-serif";
letter-spacing:-.2pt;
font-style:italic;}
h5
{mso-style-priority:9;
mso-style-link:"Heading 5 Char";
margin-top:10.0pt;
margin-right:0in;
margin-bottom:0in;
margin-left:0in;
margin-bottom:.0001pt;
page-break-after:avoid;
font-size:12.0pt;
font-family:"Cambria","serif";
color:#243F60;
font-weight:normal;}
p.MsoBodyText, li.MsoBodyText, div.MsoBodyText
{mso-style-priority:99;
mso-style-link:"Body Text Char";
margin-top:6.0pt;
margin-right:0in;
margin-bottom:6.0pt;
margin-left:0in;
text-align:justify;
font-size:11.0pt;
font-family:"Garamond","serif";
letter-spacing:-.2pt;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";}
span.hoenzb
{mso-style-name:hoenzb;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.BodyTextChar
{mso-style-name:"Body Text Char";
mso-style-priority:99;
mso-style-link:"Body Text";
font-family:"Garamond","serif";
letter-spacing:-.2pt;}
span.Heading4Char
{mso-style-name:"Heading 4 Char";
mso-style-priority:9;
mso-style-link:"Heading 4";
font-family:"Tahoma","sans-serif";
letter-spacing:-.2pt;
font-weight:bold;
font-style:italic;}
p.tablehead2, li.tablehead2, div.tablehead2
{mso-style-name:tablehead2;
margin-top:3.0pt;
margin-right:0in;
margin-bottom:3.0pt;
margin-left:0in;
text-align:center;
background:#D9D9D9;
font-size:10.0pt;
font-family:"Tahoma","sans-serif";
letter-spacing:-.2pt;
font-weight:bold;}
p.tablehead1, li.tablehead1, div.tablehead1
{mso-style-name:tablehead1;
margin-top:3.0pt;
margin-right:0in;
margin-bottom:3.0pt;
margin-left:0in;
text-align:center;
background:#CCCCCC;
border:none;
padding:0in;
font-size:12.0pt;
font-family:"Tahoma","sans-serif";
letter-spacing:-.2pt;
font-weight:bold;}
p.tabletextbullet, li.tabletextbullet, div.tabletextbullet
{mso-style-name:tabletextbullet;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:12.6pt;
margin-bottom:.0001pt;
text-indent:-12.6pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";
letter-spacing:-.2pt;}
p.tabletext, li.tabletext, div.tabletext
{mso-style-name:tabletext;
margin:0in;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";
letter-spacing:-.2pt;}
p.BodyTextBullets, li.BodyTextBullets, div.BodyTextBullets
{mso-style-name:BodyTextBullets;
margin-top:6.0pt;
margin-right:0in;
margin-bottom:6.0pt;
margin-left:.25in;
text-align:justify;
text-indent:-.25in;
font-size:11.0pt;
font-family:"Garamond","serif";
letter-spacing:-.2pt;}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";}
span.Heading5Char
{mso-style-name:"Heading 5 Char";
mso-style-priority:9;
mso-style-link:"Heading 5";
font-family:"Cambria","serif";
color:#243F60;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="WordSection1">
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Rick
is right about the discussion of thick vs. thin. It took
place way before ICANN got involved. In fact, the first
thick registries (.biz and .info) voluntarily chose to be
thick in their applications in 2000. We chose this because
we believed there was greater security in thick registries,
better back-up (at a time when no registrar did data
escrow), and help to the transfer process. I believe it was
built in some of the early models of EPP (which we called
XRP back then) before it was a standard. <o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">More
trivia…back then it was called a politically incorrect “<b>fat
model</b>” as opposed to “thick”.
<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">From
our .biz proposal in 2000 (<a moz-do-not-send="true"
href="http://archive.icann.org/en/tlds/biz4/TechCapPlanBiz.htm";>http://archive.icann.org/en/tlds/biz4/TechCapPlanBiz.htm</a>):
<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"
style="mso-margin-top-alt:6.0pt;margin-right:0in;margin-bottom:6.0pt;margin-left:0in;text-align:justify"><span
style="font-size:11.0pt;font-family:"Garamond","serif";letter-spacing:-.2pt">“JVTeam
proposes moving to a
</span><span
style="font-size:11.0pt;font-family:"Tahoma","sans-serif";letter-spacing:-.2pt">�</span><span
style="font-size:11.0pt;font-family:"Garamond","serif";letter-spacing:-.2pt">fat
registry</span><span
style="font-size:11.0pt;font-family:"Tahoma","sans-serif";letter-spacing:-.2pt">�</span><span
style="font-size:11.0pt;font-family:"Garamond","serif";letter-spacing:-.2pt">
model, with contact and authentication details stored
centrally at the Registry.</span><span
style="font-size:11.0pt;font-family:"Tahoma","sans-serif";letter-spacing:-.2pt">�</span><span
style="font-size:11.0pt;font-family:"Garamond","serif";letter-spacing:-.2pt">
Under this model, the business relationships would be
unchanged: registrants would still deal with the registrar,
and the registrars with the registry.</span><span
style="font-size:11.0pt;font-family:"Tahoma","sans-serif";letter-spacing:-.2pt">�</span><span
style="font-size:11.0pt;font-family:"Garamond","serif";letter-spacing:-.2pt">
The value of the proposed change is its ability to solve
many of the problems currently experienced on a daily basis
by both Registrants and Registrars.<o:p></o:p></span></p>
<p class="MsoNormal"
style="mso-margin-top-alt:6.0pt;margin-right:0in;margin-bottom:6.0pt;margin-left:0in;text-align:justify"><span
style="font-size:11.0pt;font-family:"Garamond","serif";letter-spacing:-.2pt">As
part of its fat-registry proposal, JVTeam proposes to
introduce a new protocol, the eXtensible Registry Protocol
(XRP), which will overcome the limitations of the current
RRP protocol (RFC2832).</span><span
style="font-size:11.0pt;font-family:"Tahoma","sans-serif";letter-spacing:-.2pt">�</span><span
style="font-size:11.0pt;font-family:"Garamond","serif";letter-spacing:-.2pt">
The XRP protocol will accommodate both thin and fat registry
models.</span><span
style="font-size:11.0pt;font-family:"Tahoma","sans-serif";letter-spacing:-.2pt">�</span><span
style="font-size:11.0pt;font-family:"Garamond","serif";letter-spacing:-.2pt">
We do not anticipate introducing the XRP protocol until
after the </span><span
style="font-size:11.0pt;font-family:"Tahoma","sans-serif";letter-spacing:-.2pt">�</span><span
style="font-size:11.0pt;font-family:"Garamond","serif";letter-spacing:-.2pt">land
rush</span><span
style="font-size:11.0pt;font-family:"Tahoma","sans-serif";letter-spacing:-.2pt">�</span><span
style="font-size:11.0pt;font-family:"Garamond","serif";letter-spacing:-.2pt">
period has ended.”<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"
style="mso-margin-top-alt:6.0pt;margin-right:0in;margin-bottom:6.0pt;margin-left:1.0in;text-align:justify;text-indent:-1.0in;page-break-after:avoid"><b><i><span
style="font-family:"Tahoma","sans-serif";letter-spacing:-.2pt">III.2.2.1
</span></i></b><b><i><span
style="font-family:"Tahoma","sans-serif";letter-spacing:-.2pt">�����</span></i></b><b><i><span
style="font-family:"Tahoma","sans-serif";letter-spacing:-.2pt">Problems
With The Current Model and its Supporting Protocol
(RRP)<o:p></o:p></span></i></b></p>
<p class="MsoNormal"
style="mso-margin-top-alt:6.0pt;margin-right:0in;margin-bottom:6.0pt;margin-left:0in;text-align:justify"><span
style="font-size:11.0pt;font-family:"Garamond","serif";letter-spacing:-.2pt">The
current TLD is based on a thin registry model and the RRP
protocol.</span><span
style="font-size:11.0pt;font-family:"Tahoma","sans-serif";letter-spacing:-.2pt">�</span><span
style="font-size:11.0pt;font-family:"Garamond","serif";letter-spacing:-.2pt">
Problems with the system cause confusion for registrants and
have added costs (and risk) to registrars because of the
need for manual processing or the breakdown of automated
processes.</span><span
style="font-size:11.0pt;font-family:"Tahoma","sans-serif";letter-spacing:-.2pt">�</span><span
style="font-size:11.0pt;font-family:"Garamond","serif";letter-spacing:-.2pt">
The following table lists issues with the current model and
RRP and gives example relating to these
issues:<o:p></o:p></span></p>
<table class="MsoNormalTable"
style="margin-left:5.4pt;border-collapse:collapse;border:none"
border="1" cellpadding="0" cellspacing="0">
<thead>
<tr>
<td colspan="2" style="width:7.0in;border:solid windowtext
1.0pt;padding:0in 5.4pt 0in 5.4pt" valign="top"
width="672">
<div style="mso-element:para-border-div;border:solid
windowtext 1.0pt;padding:1.0pt 4.0pt 1.0pt
4.0pt;background:#CCCCCC">
<p class="MsoNormal"
style="mso-margin-top-alt:3.0pt;margin-right:0in;margin-bottom:3.0pt;margin-left:0in;text-align:center;background:#CCCCCC;border:none;padding:0in"
align="center">
<b><span
style="font-family:"Tahoma","sans-serif";letter-spacing:-.2pt">Deficiencies
of the current registry/registrar model and
protocol<o:p></o:p></span></b></p>
</div>
</td>
</tr>
<tr style="height:16.15pt">
<td style="width:166.5pt;border:solid windowtext
1.0pt;border-top:none;padding:0in 5.4pt 0in
5.4pt;height:16.15pt" valign="top" width="222">
<p class="MsoNormal"
style="mso-margin-top-alt:3.0pt;margin-right:0in;margin-bottom:3.0pt;margin-left:0in;text-align:center;background:#D9D9D9"
align="center">
<b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif";letter-spacing:-.2pt">Issue<o:p></o:p></span></b></p>
</td>
<td
style="width:337.5pt;border-top:none;border-left:none;border-bottom:solid
windowtext 1.0pt;border-right:solid windowtext
1.0pt;padding:0in 5.4pt 0in 5.4pt;height:16.15pt"
valign="top" width="450">
<p class="MsoNormal"
style="mso-margin-top-alt:3.0pt;margin-right:0in;margin-bottom:3.0pt;margin-left:0in;text-align:center;background:#D9D9D9"
align="center">
<b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif";letter-spacing:-.2pt">Result<o:p></o:p></span></b></p>
</td>
</tr>
</thead>
<tbody>
<tr>
<td style="width:166.5pt;border:solid windowtext
1.0pt;border-top:none;padding:0in 5.4pt 0in 5.4pt"
valign="top" width="222">
<p class="MsoNormal"><span
style="font-size:8.0pt;font-family:"Tahoma","sans-serif";letter-spacing:-.2pt">Protocol
not extensible<o:p></o:p></span></p>
</td>
<td
style="width:337.5pt;border-top:none;border-left:none;border-bottom:solid
windowtext 1.0pt;border-right:solid windowtext
1.0pt;padding:0in 5.4pt 0in 5.4pt" valign="top"
width="450">
<p class="MsoNormal"
style="margin-left:12.6pt;text-indent:-12.6pt"><span
style="font-size:8.0pt;font-family:Symbol;letter-spacing:-.2pt">�</span><span
style="font-size:7.0pt;letter-spacing:-.2pt">
</span><span
style="font-size:8.0pt;font-family:"Tahoma","sans-serif";letter-spacing:-.2pt">No
ability to authenticate registrants
<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-left:12.6pt;text-indent:-12.6pt"><span
style="font-size:8.0pt;font-family:Symbol;letter-spacing:-.2pt">�</span><span
style="font-size:7.0pt;letter-spacing:-.2pt">
</span><span
style="font-size:8.0pt;font-family:"Tahoma","sans-serif";letter-spacing:-.2pt">Not
designed for fat registry model<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-left:12.6pt;text-indent:-12.6pt"><span
style="font-size:8.0pt;font-family:Symbol;letter-spacing:-.2pt">�</span><span
style="font-size:7.0pt;letter-spacing:-.2pt">
</span><span
style="font-size:8.0pt;font-family:"Tahoma","sans-serif";letter-spacing:-.2pt">Not
designed using a naturally extensible technology,
such as XML<o:p></o:p></span></p>
</td>
</tr>
<tr>
<td style="width:166.5pt;border:solid windowtext
1.0pt;border-top:none;padding:0in 5.4pt 0in 5.4pt"
valign="top" width="222">
<p class="MsoNormal"><span
style="font-size:8.0pt;font-family:"Tahoma","sans-serif";letter-spacing:-.2pt">Protocol
not complete<o:p></o:p></span></p>
</td>
<td
style="width:337.5pt;border-top:none;border-left:none;border-bottom:solid
windowtext 1.0pt;border-right:solid windowtext
1.0pt;padding:0in 5.4pt 0in 5.4pt" valign="top"
width="450">
<p class="MsoNormal"
style="margin-left:12.6pt;text-indent:-12.6pt"><span
style="font-size:8.0pt;font-family:Symbol;letter-spacing:-.2pt">�</span><span
style="font-size:7.0pt;letter-spacing:-.2pt">
</span><span
style="font-size:8.0pt;font-family:"Tahoma","sans-serif";letter-spacing:-.2pt">Not
all data exposed (e.g., registrar details and status
not exposed)<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-left:12.6pt;text-indent:-12.6pt"><span
style="font-size:8.0pt;font-family:Symbol;letter-spacing:-.2pt">�</span><span
style="font-size:7.0pt;letter-spacing:-.2pt">
</span><span
style="font-size:8.0pt;font-family:"Tahoma","sans-serif";letter-spacing:-.2pt">No
ability to query transfer status<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-left:12.6pt;text-indent:-12.6pt"><span
style="font-size:8.0pt;font-family:Symbol;letter-spacing:-.2pt">�</span><span
style="font-size:7.0pt;letter-spacing:-.2pt">
</span><span
style="font-size:8.0pt;font-family:"Tahoma","sans-serif";letter-spacing:-.2pt">No
date/time of registration and
expiration<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-left:12.6pt;text-indent:-12.6pt"><span
style="font-size:8.0pt;font-family:Symbol;letter-spacing:-.2pt">�</span><span
style="font-size:7.0pt;letter-spacing:-.2pt">
</span><span
style="font-size:8.0pt;font-family:"Tahoma","sans-serif";letter-spacing:-.2pt">No
status on domains linked to another
registrar<o:p></o:p></span></p>
</td>
</tr>
<tr>
<td style="width:166.5pt;border:solid windowtext
1.0pt;border-top:none;padding:0in 5.4pt 0in 5.4pt"
valign="top" width="222">
<p class="MsoNormal"><span
style="font-size:8.0pt;font-family:"Tahoma","sans-serif";letter-spacing:-.2pt">Different
protocols used for Whois<o:p></o:p></span></p>
</td>
<td
style="width:337.5pt;border-top:none;border-left:none;border-bottom:solid
windowtext 1.0pt;border-right:solid windowtext
1.0pt;padding:0in 5.4pt 0in 5.4pt" valign="top"
width="450">
<p class="MsoNormal"
style="margin-left:12.6pt;text-indent:-12.6pt"><span
style="font-size:8.0pt;font-family:Symbol;letter-spacing:-.2pt">�</span><span
style="font-size:7.0pt;letter-spacing:-.2pt">
</span><span
style="font-size:8.0pt;font-family:"Tahoma","sans-serif";letter-spacing:-.2pt">No
uniform Whois standard (registrars can use web
interface)<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-left:12.6pt;text-indent:-12.6pt"><span
style="font-size:8.0pt;font-family:Symbol;letter-spacing:-.2pt">�</span><span
style="font-size:7.0pt;letter-spacing:-.2pt">
</span><span
style="font-size:8.0pt;font-family:"Tahoma","sans-serif";letter-spacing:-.2pt">Not
all registrars use Whois on Port 43<o:p></o:p></span></p>
</td>
</tr>
<tr>
<td style="width:166.5pt;border:solid windowtext
1.0pt;border-top:none;padding:0in 5.4pt 0in 5.4pt"
valign="top" width="222">
<p class="MsoNormal"><span
style="font-size:8.0pt;font-family:"Tahoma","sans-serif";letter-spacing:-.2pt">No
standard Whois fields
<o:p></o:p></span></p>
</td>
<td
style="width:337.5pt;border-top:none;border-left:none;border-bottom:solid
windowtext 1.0pt;border-right:solid windowtext
1.0pt;padding:0in 5.4pt 0in 5.4pt" valign="top"
width="450">
<p class="MsoNormal"
style="margin-left:12.6pt;text-indent:-12.6pt"><span
style="font-size:8.0pt;font-family:Symbol;letter-spacing:-.2pt">�</span><span
style="font-size:7.0pt;letter-spacing:-.2pt">
</span><span
style="font-size:8.0pt;font-family:"Tahoma","sans-serif";letter-spacing:-.2pt">Each
registrar has implemented Whois differently.�
Differences include:<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-left:12.6pt;text-indent:-12.6pt"><span
style="font-size:8.0pt;font-family:Symbol;letter-spacing:-.2pt">�</span><span
style="font-size:7.0pt;letter-spacing:-.2pt">
</span><span
style="font-size:8.0pt;font-family:"Tahoma","sans-serif";letter-spacing:-.2pt">Some
registrars have additional registrant contact
information<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-left:12.6pt;text-indent:-12.6pt"><span
style="font-size:8.0pt;font-family:Symbol;letter-spacing:-.2pt">�</span><span
style="font-size:7.0pt;letter-spacing:-.2pt">
</span><span
style="font-size:8.0pt;font-family:"Tahoma","sans-serif";letter-spacing:-.2pt">No
standards exist for technical and/or zone
contact<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-left:12.6pt;text-indent:-12.6pt"><span
style="font-size:8.0pt;font-family:Symbol;letter-spacing:-.2pt">�</span><span
style="font-size:7.0pt;letter-spacing:-.2pt">
</span><span
style="font-size:8.0pt;font-family:"Tahoma","sans-serif";letter-spacing:-.2pt">Some
registrars have one address line; others, two
lines<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-left:12.6pt;text-indent:-12.6pt"><span
style="font-size:8.0pt;font-family:Symbol;letter-spacing:-.2pt">�</span><span
style="font-size:7.0pt;letter-spacing:-.2pt">
</span><span
style="font-size:8.0pt;font-family:"Tahoma","sans-serif";letter-spacing:-.2pt">Some
registrars don�t expose all fields in the
Whois<o:p></o:p></span></p>
</td>
</tr>
<tr>
<td style="width:166.5pt;border:solid windowtext
1.0pt;border-top:none;padding:0in 5.4pt 0in 5.4pt"
valign="top" width="222">
<p class="MsoNormal"><span
style="font-size:8.0pt;font-family:"Tahoma","sans-serif";letter-spacing:-.2pt">Different
data formatting in Whois services<o:p></o:p></span></p>
</td>
<td
style="width:337.5pt;border-top:none;border-left:none;border-bottom:solid
windowtext 1.0pt;border-right:solid windowtext
1.0pt;padding:0in 5.4pt 0in 5.4pt" valign="top"
width="450">
<p class="MsoNormal"
style="margin-left:12.6pt;text-indent:-12.6pt"><span
style="font-size:8.0pt;font-family:Symbol;letter-spacing:-.2pt">�</span><span
style="font-size:7.0pt;letter-spacing:-.2pt">
</span><span
style="font-size:8.0pt;font-family:"Tahoma","sans-serif";letter-spacing:-.2pt">Data
is presented differently; i.e., Phone: 99999 or
Phone Number: (999) 999<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-left:12.6pt;text-indent:-12.6pt"><span
style="font-size:8.0pt;font-family:Symbol;letter-spacing:-.2pt">�</span><span
style="font-size:7.0pt;letter-spacing:-.2pt">
</span><span
style="font-size:8.0pt;font-family:"Tahoma","sans-serif";letter-spacing:-.2pt">Different
ordering of fields<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-left:12.6pt;text-indent:-12.6pt"><span
style="font-size:8.0pt;font-family:Symbol;letter-spacing:-.2pt">�</span><span
style="font-size:7.0pt;letter-spacing:-.2pt">
</span><span
style="font-size:8.0pt;font-family:"Tahoma","sans-serif";letter-spacing:-.2pt">Different
lengths of fields
<o:p></o:p></span></p>
</td>
</tr>
<tr>
<td style="width:166.5pt;border:solid windowtext
1.0pt;border-top:none;padding:0in 5.4pt 0in 5.4pt"
valign="top" width="222">
<p class="MsoNormal"><span
style="font-size:8.0pt;font-family:"Tahoma","sans-serif";letter-spacing:-.2pt">No
real-time update of Whois and zone
file<o:p></o:p></span></p>
</td>
<td
style="width:337.5pt;border-top:none;border-left:none;border-bottom:solid
windowtext 1.0pt;border-right:solid windowtext
1.0pt;padding:0in 5.4pt 0in 5.4pt" valign="top"
width="450">
<p class="MsoNormal"
style="margin-left:12.6pt;text-indent:-12.6pt"><span
style="font-size:8.0pt;font-family:Symbol;letter-spacing:-.2pt">�</span><span
style="font-size:7.0pt;letter-spacing:-.2pt">
</span><span
style="font-size:8.0pt;font-family:"Tahoma","sans-serif";letter-spacing:-.2pt">Registry
updates Whois and root servers only every 12
hours<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-left:12.6pt;text-indent:-12.6pt"><span
style="font-size:8.0pt;font-family:Symbol;letter-spacing:-.2pt">�</span><span
style="font-size:7.0pt;letter-spacing:-.2pt">
</span><span
style="font-size:8.0pt;font-family:"Tahoma","sans-serif";letter-spacing:-.2pt">Causes
confusion for Registrants, adds support cost to
Registrars<o:p></o:p></span></p>
</td>
</tr>
<tr>
<td style="width:166.5pt;border:solid windowtext
1.0pt;border-top:none;padding:0in 5.4pt 0in 5.4pt"
valign="top" width="222">
<p class="MsoNormal"><span
style="font-size:8.0pt;font-family:"Tahoma","sans-serif";letter-spacing:-.2pt">Timing
inconsistencies (when adding, deleting, transferring
registrar, etc)<o:p></o:p></span></p>
</td>
<td
style="width:337.5pt;border-top:none;border-left:none;border-bottom:solid
windowtext 1.0pt;border-right:solid windowtext
1.0pt;padding:0in 5.4pt 0in 5.4pt" valign="top"
width="450">
<p class="MsoNormal"
style="margin-left:12.6pt;text-indent:-12.6pt"><span
style="font-size:8.0pt;font-family:Symbol;letter-spacing:-.2pt">�</span><span
style="font-size:7.0pt;letter-spacing:-.2pt">
</span><span
style="font-size:8.0pt;font-family:"Tahoma","sans-serif";letter-spacing:-.2pt">Registry
Whois server updated before or after Registrar
database, causing inconsistency between the
two<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-left:12.6pt;text-indent:-12.6pt"><span
style="font-size:8.0pt;font-family:Symbol;letter-spacing:-.2pt">�</span><span
style="font-size:7.0pt;letter-spacing:-.2pt">
</span><span
style="font-size:8.0pt;font-family:"Tahoma","sans-serif";letter-spacing:-.2pt">Two
registrars� databases can be updated at different
times, causing inconsistency<o:p></o:p></span></p>
</td>
</tr>
<tr>
<td style="width:166.5pt;border:solid windowtext
1.0pt;border-top:none;padding:0in 5.4pt 0in 5.4pt"
valign="top" width="222">
<p class="MsoNormal"><span
style="font-size:8.0pt;font-family:"Tahoma","sans-serif";letter-spacing:-.2pt">No
machine-readable Whois format<o:p></o:p></span></p>
</td>
<td
style="width:337.5pt;border-top:none;border-left:none;border-bottom:solid
windowtext 1.0pt;border-right:solid windowtext
1.0pt;padding:0in 5.4pt 0in 5.4pt" valign="top"
width="450">
<p class="MsoNormal"
style="margin-left:12.6pt;text-indent:-12.6pt"><span
style="font-size:8.0pt;font-family:Symbol;letter-spacing:-.2pt">�</span><span
style="font-size:7.0pt;letter-spacing:-.2pt">
</span><span
style="font-size:8.0pt;font-family:"Tahoma","sans-serif";letter-spacing:-.2pt">No
automated parsing of Whois data by non-registrar
community (Need XML-based Whois
format)<o:p></o:p></span></p>
</td>
</tr>
<tr>
<td style="width:166.5pt;border:solid windowtext
1.0pt;border-top:none;padding:0in 5.4pt 0in 5.4pt"
valign="top" width="222">
<p class="MsoNormal"><span
style="font-size:8.0pt;font-family:"Tahoma","sans-serif";letter-spacing:-.2pt">No
registrar extensibility<o:p></o:p></span></p>
</td>
<td
style="width:337.5pt;border-top:none;border-left:none;border-bottom:solid
windowtext 1.0pt;border-right:solid windowtext
1.0pt;padding:0in 5.4pt 0in 5.4pt" valign="top"
width="450">
<p class="MsoNormal"
style="margin-left:12.6pt;text-indent:-12.6pt"><span
style="font-size:8.0pt;font-family:Symbol;letter-spacing:-.2pt">�</span><span
style="font-size:7.0pt;letter-spacing:-.2pt">
</span><span
style="font-size:8.0pt;font-family:"Tahoma","sans-serif";letter-spacing:-.2pt">No
provisions for registrars to add custom fields to
registry database except after revising the protocol
<o:p></o:p></span></p>
</td>
</tr>
<tr>
<td style="width:166.5pt;border:solid windowtext
1.0pt;border-top:none;padding:0in 5.4pt 0in 5.4pt"
valign="top" width="222">
<p class="MsoNormal"><span
style="font-size:8.0pt;font-family:"Tahoma","sans-serif";letter-spacing:-.2pt">No
ability to broadcast events to
registrars<o:p></o:p></span></p>
</td>
<td
style="width:337.5pt;border-top:none;border-left:none;border-bottom:solid
windowtext 1.0pt;border-right:solid windowtext
1.0pt;padding:0in 5.4pt 0in 5.4pt" valign="top"
width="450">
<p class="MsoNormal"
style="margin-left:12.6pt;text-indent:-12.6pt"><span
style="font-size:8.0pt;font-family:Symbol;letter-spacing:-.2pt">�</span><span
style="font-size:7.0pt;letter-spacing:-.2pt">
</span><span
style="font-size:8.0pt;font-family:"Tahoma","sans-serif";letter-spacing:-.2pt">Registry
cannot automatically notify Registrars of important
events (e.g., �Transfer of Registrar� request or
renaming of a name server host name); must use
email<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-left:12.6pt;text-indent:-12.6pt"><span
style="font-size:8.0pt;font-family:Symbol;letter-spacing:-.2pt">�</span><span
style="font-size:7.0pt;letter-spacing:-.2pt">
</span><span
style="font-size:8.0pt;font-family:"Tahoma","sans-serif";letter-spacing:-.2pt">Cannot
accommodate registrars� need to add �listeners� to
certain important events<o:p></o:p></span></p>
</td>
</tr>
<tr>
<td style="width:166.5pt;border:solid windowtext
1.0pt;border-top:none;padding:0in 5.4pt 0in 5.4pt"
valign="top" width="222">
<p class="MsoNormal"><span
style="font-size:8.0pt;font-family:"Tahoma","sans-serif";letter-spacing:-.2pt">No
registrant authentication<o:p></o:p></span></p>
</td>
<td
style="width:337.5pt;border-top:none;border-left:none;border-bottom:solid
windowtext 1.0pt;border-right:solid windowtext
1.0pt;padding:0in 5.4pt 0in 5.4pt" valign="top"
width="450">
<p class="MsoNormal"
style="margin-left:12.6pt;text-indent:-12.6pt"><span
style="font-size:8.0pt;font-family:Symbol;letter-spacing:-.2pt">�</span><span
style="font-size:7.0pt;letter-spacing:-.2pt">
</span><span
style="font-size:8.0pt;font-family:"Tahoma","sans-serif";letter-spacing:-.2pt">Cannot
determine whether a registrant�s �Transfer of
Registrar� request is authentic.� The registrar must
make a subjective decision about whether the
registrant is the one represented in the losing
Registrar�s Whois<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-left:12.6pt;text-indent:-12.6pt"><span
style="font-size:8.0pt;font-family:Symbol;letter-spacing:-.2pt">�</span><span
style="font-size:7.0pt;letter-spacing:-.2pt">
</span><span
style="font-size:8.0pt;font-family:"Tahoma","sans-serif";letter-spacing:-.2pt">No
standard method for authenticating deletions,
changes of ownership, re-delegations, name-server
maintenance, etc<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-left:12.6pt;text-indent:-12.6pt"><span
style="font-size:8.0pt;font-family:Symbol;letter-spacing:-.2pt">�</span><span
style="font-size:7.0pt;letter-spacing:-.2pt">
</span><span
style="font-size:8.0pt;font-family:"Tahoma","sans-serif";letter-spacing:-.2pt">TLD
security sinks lowest common (registrar)
denominator, because a registrar with poor security
could perform an incorrect Transfer of Registrar,
giving the registrant control of the wrong domain
name.� Potential for �hijacked� domain names creates
huge stability problems to the
Internet.<o:p></o:p></span></p>
</td>
</tr>
<tr>
<td style="width:166.5pt;border:solid windowtext
1.0pt;border-top:none;padding:0in 5.4pt 0in 5.4pt"
valign="top" width="222">
<p class="MsoNormal"><span
style="font-size:8.0pt;font-family:"Tahoma","sans-serif";letter-spacing:-.2pt">No
rollback support for some operations<o:p></o:p></span></p>
</td>
<td
style="width:337.5pt;border-top:none;border-left:none;border-bottom:solid
windowtext 1.0pt;border-right:solid windowtext
1.0pt;padding:0in 5.4pt 0in 5.4pt" valign="top"
width="450">
<p class="MsoNormal"
style="margin-left:12.6pt;text-indent:-12.6pt"><span
style="font-size:8.0pt;font-family:Symbol;letter-spacing:-.2pt">�</span><span
style="font-size:7.0pt;letter-spacing:-.2pt">
</span><span
style="font-size:8.0pt;font-family:"Tahoma","sans-serif";letter-spacing:-.2pt">Not
all operations can be reversed by a separate
counteraction (although some can: e.g.,� �Register
domain name� can be reversed by �Cancel domain name�
command within 5 days)<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-left:12.6pt;text-indent:-12.6pt"><span
style="font-size:8.0pt;font-family:Symbol;letter-spacing:-.2pt">�</span><span
style="font-size:7.0pt;letter-spacing:-.2pt">
</span><span
style="font-size:8.0pt;font-family:"Tahoma","sans-serif";letter-spacing:-.2pt">Operations
like Registrar Transfer cannot be �rolled-back� via
the protocol in the case of error<o:p></o:p></span></p>
</td>
</tr>
<tr>
<td style="width:166.5pt;border:solid windowtext
1.0pt;border-top:none;padding:0in 5.4pt 0in 5.4pt"
valign="top" width="222">
<p class="MsoNormal"><span
style="font-size:8.0pt;font-family:"Tahoma","sans-serif";letter-spacing:-.2pt">No
support for IPv6<o:p></o:p></span></p>
</td>
<td
style="width:337.5pt;border-top:none;border-left:none;border-bottom:solid
windowtext 1.0pt;border-right:solid windowtext
1.0pt;padding:0in 5.4pt 0in 5.4pt" valign="top"
width="450">
<p class="MsoNormal"
style="margin-left:12.6pt;text-indent:-12.6pt"><span
style="font-size:8.0pt;font-family:Symbol;letter-spacing:-.2pt">�</span><span
style="font-size:7.0pt;letter-spacing:-.2pt">
</span><span
style="font-size:8.0pt;font-family:"Tahoma","sans-serif";letter-spacing:-.2pt">Does
not support important, currently deployed
technology<o:p></o:p></span></p>
</td>
</tr>
</tbody>
</table>
<p class="MsoNormal"
style="mso-margin-top-alt:6.0pt;margin-right:0in;margin-bottom:6.0pt;margin-left:1.0in;text-align:justify;text-indent:-1.0in;page-break-after:avoid"><b><i><span
style="font-family:"Tahoma","sans-serif";letter-spacing:-.2pt">III.2.2.2
����Features of the Fat Registry Model
<o:p></o:p></span></i></b></p>
<p class="MsoNormal"
style="mso-margin-top-alt:6.0pt;margin-right:0in;margin-bottom:6.0pt;margin-left:0in;text-align:justify"><span
style="font-size:11.0pt;font-family:"Garamond","serif";letter-spacing:-.2pt">As
the beginning of this proposal paragraph (III.2.2) states,
JVTeam proposes deploying a
</span><span
style="font-size:11.0pt;font-family:"Tahoma","sans-serif";letter-spacing:-.2pt">�</span><span
style="font-size:11.0pt;font-family:"Garamond","serif";letter-spacing:-.2pt">fat
registry</span><span
style="font-size:11.0pt;font-family:"Tahoma","sans-serif";letter-spacing:-.2pt">�</span><span
style="font-size:11.0pt;font-family:"Garamond","serif";letter-spacing:-.2pt">
model, with contact and authentication details stored
centrally at the Registry.</span><span
style="font-size:11.0pt;font-family:"Tahoma","sans-serif";letter-spacing:-.2pt">�</span><span
style="font-size:11.0pt;font-family:"Garamond","serif";letter-spacing:-.2pt">
Exhibit III.2-7 illustrates the fat registry model.</span><span
style="font-size:11.0pt;font-family:"Tahoma","sans-serif";letter-spacing:-.2pt">��</span><span
style="font-size:11.0pt;font-family:"Garamond","serif";letter-spacing:-.2pt">
<o:p></o:p></span></p>
<p class="MsoNormal"
style="mso-margin-top-alt:6.0pt;margin-right:0in;margin-bottom:6.0pt;margin-left:0in;text-align:justify"><span
style="font-size:11.0pt;font-family:"Garamond","serif";letter-spacing:-.2pt">JVTeam
prepared the following list of design features for our
proposed XRP protocol:<o:p></o:p></span></p>
<p class="MsoNormal"
style="mso-margin-top-alt:6.0pt;margin-right:0in;margin-bottom:6.0pt;margin-left:.25in;text-align:justify;text-indent:-.25in"><span
style="font-size:11.0pt;font-family:Symbol;letter-spacing:-.2pt">�</span><span
style="font-size:7.0pt;letter-spacing:-.2pt">
</span><span
style="font-size:11.0pt;font-family:"Garamond","serif";letter-spacing:-.2pt">Extensible
protocol based on XML<o:p></o:p></span></p>
<p class="MsoNormal"
style="mso-margin-top-alt:6.0pt;margin-right:0in;margin-bottom:6.0pt;margin-left:.25in;text-align:justify;text-indent:-.25in"><span
style="font-size:11.0pt;font-family:Symbol;letter-spacing:-.2pt">�</span><span
style="font-size:7.0pt;letter-spacing:-.2pt">
</span><span
style="font-size:11.0pt;font-family:"Garamond","serif";letter-spacing:-.2pt">Support
for both fat and thin registry models
<o:p></o:p></span></p>
<p class="MsoNormal"
style="mso-margin-top-alt:6.0pt;margin-right:0in;margin-bottom:6.0pt;margin-left:.25in;text-align:justify;text-indent:-.25in"><span
style="font-size:11.0pt;font-family:Symbol;letter-spacing:-.2pt">�</span><span
style="font-size:7.0pt;letter-spacing:-.2pt">
</span><span
style="font-size:11.0pt;font-family:"Garamond","serif";letter-spacing:-.2pt">Support
for centralized contact information / centralized
Whois<o:p></o:p></span></p>
<p class="MsoNormal"
style="mso-margin-top-alt:6.0pt;margin-right:0in;margin-bottom:6.0pt;margin-left:.25in;text-align:justify;text-indent:-.25in"><span
style="font-size:11.0pt;font-family:Symbol;letter-spacing:-.2pt">�</span><span
style="font-size:7.0pt;letter-spacing:-.2pt">
</span><span
style="font-size:11.0pt;font-family:"Garamond","serif";letter-spacing:-.2pt">Standardized
Whois service (same fields regardless of registrar</span><span
style="font-size:11.0pt;font-family:"Tahoma","sans-serif";letter-spacing:-.2pt">�</span><span
style="font-size:11.0pt;font-family:"Garamond","serif";letter-spacing:-.2pt">s
web site)<o:p></o:p></span></p>
<p class="MsoNormal"
style="mso-margin-top-alt:6.0pt;margin-right:0in;margin-bottom:6.0pt;margin-left:.25in;text-align:justify;text-indent:-.25in"><span
style="font-size:11.0pt;font-family:Symbol;letter-spacing:-.2pt">�</span><span
style="font-size:7.0pt;letter-spacing:-.2pt">
</span><span
style="font-size:11.0pt;font-family:"Garamond","serif";letter-spacing:-.2pt">Machine
readable Whois format (when specified)<o:p></o:p></span></p>
<span
style="font-size:11.0pt;font-family:"Garamond","serif";letter-spacing:-.2pt;mso-fareast-language:EN-US"><br
style="page-break-before:always" clear="all">
</span>
<p class="MsoNormal"
style="mso-margin-top-alt:6.0pt;margin-right:0in;margin-bottom:6.0pt;margin-left:0in;text-align:justify"><span
style="font-size:11.0pt;font-family:"Garamond","serif";letter-spacing:-.2pt"><img
id="Picture_x0020_1"
src="cid:part2.01090507.00090902@key-systems.net"
alt="131.ICANN" width="608" height="817" border="0"></span><span
style="font-size:11.0pt;font-family:"Garamond","serif";letter-spacing:-.2pt"><o:p></o:p></span></p>
<span
style="font-size:11.0pt;font-family:"Garamond","serif";letter-spacing:-.2pt;mso-fareast-language:EN-US"><br
style="page-break-before:always" clear="all">
</span>
<p class="MsoNormal"
style="mso-margin-top-alt:6.0pt;margin-right:0in;margin-bottom:6.0pt;margin-left:.25in;text-align:justify;text-indent:-.25in"><span
style="font-size:11.0pt;font-family:Symbol;letter-spacing:-.2pt">�</span><span
style="font-size:7.0pt;letter-spacing:-.2pt">
</span><span
style="font-size:11.0pt;font-family:"Garamond","serif";letter-spacing:-.2pt">Extensible
data-field support (registrars can add custom fields to
Whois following standardized fields)<o:p></o:p></span></p>
<p class="MsoNormal"
style="mso-margin-top-alt:6.0pt;margin-right:0in;margin-bottom:6.0pt;margin-left:.25in;text-align:justify;text-indent:-.25in"><span
style="font-size:11.0pt;font-family:Symbol;letter-spacing:-.2pt">�</span><span
style="font-size:7.0pt;letter-spacing:-.2pt">
</span><span
style="font-size:11.0pt;font-family:"Garamond","serif";letter-spacing:-.2pt">Functionally
complete (exposing all registry data via one
interface)<o:p></o:p></span></p>
<p class="MsoNormal"
style="mso-margin-top-alt:6.0pt;margin-right:0in;margin-bottom:6.0pt;margin-left:.25in;text-align:justify;text-indent:-.25in"><span
style="font-size:11.0pt;font-family:Symbol;letter-spacing:-.2pt">�</span><span
style="font-size:7.0pt;letter-spacing:-.2pt">
</span><span
style="font-size:11.0pt;font-family:"Garamond","serif";letter-spacing:-.2pt">Secure<o:p></o:p></span></p>
<p class="MsoNormal"
style="mso-margin-top-alt:6.0pt;margin-right:0in;margin-bottom:6.0pt;margin-left:.25in;text-align:justify;text-indent:-.25in"><span
style="font-size:11.0pt;font-family:Symbol;letter-spacing:-.2pt">�</span><span
style="font-size:7.0pt;letter-spacing:-.2pt">
</span><span
style="font-size:11.0pt;font-family:"Garamond","serif";letter-spacing:-.2pt">Non-repudiation
(No deniability)<o:p></o:p></span></p>
<p class="MsoNormal"
style="mso-margin-top-alt:6.0pt;margin-right:0in;margin-bottom:6.0pt;margin-left:.25in;text-align:justify;text-indent:-.25in"><span
style="font-size:11.0pt;font-family:Symbol;letter-spacing:-.2pt">�</span><span
style="font-size:7.0pt;letter-spacing:-.2pt">
</span><span
style="font-size:11.0pt;font-family:"Garamond","serif";letter-spacing:-.2pt">Fault
tolerant (Duplicate requests have no adverse
effect)<o:p></o:p></span></p>
<p class="MsoNormal"
style="mso-margin-top-alt:6.0pt;margin-right:0in;margin-bottom:6.0pt;margin-left:.25in;text-align:justify;text-indent:-.25in"><span
style="font-size:11.0pt;font-family:Symbol;letter-spacing:-.2pt">�</span><span
style="font-size:7.0pt;letter-spacing:-.2pt">
</span><span
style="font-size:11.0pt;font-family:"Garamond","serif";letter-spacing:-.2pt">Real-time
XRP functions (check, register, etc)<o:p></o:p></span></p>
<p class="MsoNormal"
style="mso-margin-top-alt:6.0pt;margin-right:0in;margin-bottom:6.0pt;margin-left:.25in;text-align:justify;text-indent:-.25in"><span
style="font-size:11.0pt;font-family:Symbol;letter-spacing:-.2pt">�</span><span
style="font-size:7.0pt;letter-spacing:-.2pt">
</span><span
style="font-size:11.0pt;font-family:"Garamond","serif";letter-spacing:-.2pt">Real-time
DNS and Whois updates<o:p></o:p></span></p>
<p class="MsoNormal"
style="mso-margin-top-alt:6.0pt;margin-right:0in;margin-bottom:6.0pt;margin-left:.25in;text-align:justify;text-indent:-.25in"><span
style="font-size:11.0pt;font-family:Symbol;letter-spacing:-.2pt">�</span><span
style="font-size:7.0pt;letter-spacing:-.2pt">
</span><span
style="font-size:11.0pt;font-family:"Garamond","serif";letter-spacing:-.2pt">Support
for IPv6 IP addresses<o:p></o:p></span></p>
<p class="MsoNormal"
style="mso-margin-top-alt:6.0pt;margin-right:0in;margin-bottom:6.0pt;margin-left:.25in;text-align:justify;text-indent:-.25in"><span
style="font-size:11.0pt;font-family:Symbol;letter-spacing:-.2pt">�</span><span
style="font-size:7.0pt;letter-spacing:-.2pt">
</span><span
style="font-size:11.0pt;font-family:"Garamond","serif";letter-spacing:-.2pt">Standard,
centralized registrant-authentication method<o:p></o:p></span></p>
<p class="MsoNormal"
style="mso-margin-top-alt:6.0pt;margin-right:0in;margin-bottom:6.0pt;margin-left:.25in;text-align:justify;text-indent:-.25in"><span
style="font-size:11.0pt;font-family:Symbol;letter-spacing:-.2pt">�</span><span
style="font-size:7.0pt;letter-spacing:-.2pt">
</span><span
style="font-size:11.0pt;font-family:"Garamond","serif";letter-spacing:-.2pt">Extensible
registrant-authentication methods (support for digital
certificates, etc)<o:p></o:p></span></p>
<p class="MsoNormal"
style="mso-margin-top-alt:6.0pt;margin-right:0in;margin-bottom:6.0pt;margin-left:.25in;text-align:justify;text-indent:-.25in"><span
style="font-size:11.0pt;font-family:Symbol;letter-spacing:-.2pt">�</span><span
style="font-size:7.0pt;letter-spacing:-.2pt">
</span><span
style="font-size:11.0pt;font-family:"Garamond","serif";letter-spacing:-.2pt">Simple
account transfer (between registrars, using centralized
authentication)<o:p></o:p></span></p>
<p class="MsoNormal"
style="mso-margin-top-alt:6.0pt;margin-right:0in;margin-bottom:6.0pt;margin-left:.25in;text-align:justify;text-indent:-.25in"><span
style="font-size:11.0pt;font-family:Symbol;letter-spacing:-.2pt">�</span><span
style="font-size:7.0pt;letter-spacing:-.2pt">
</span><span
style="font-size:11.0pt;font-family:"Garamond","serif";letter-spacing:-.2pt">Event
broadcasting (ability for registrars to place
</span><span
style="font-size:11.0pt;font-family:"Tahoma","sans-serif";letter-spacing:-.2pt">�</span><span
style="font-size:11.0pt;font-family:"Garamond","serif";letter-spacing:-.2pt">listeners</span><span
style="font-size:11.0pt;font-family:"Tahoma","sans-serif";letter-spacing:-.2pt">�</span><span
style="font-size:11.0pt;font-family:"Garamond","serif";letter-spacing:-.2pt">
on registry events)<o:p></o:p></span></p>
<p class="MsoNormal"
style="mso-margin-top-alt:6.0pt;margin-right:0in;margin-bottom:6.0pt;margin-left:.25in;text-align:justify;text-indent:-.25in"><span
style="font-size:11.0pt;font-family:Symbol;letter-spacing:-.2pt">�</span><span
style="font-size:7.0pt;letter-spacing:-.2pt">
</span><span
style="font-size:11.0pt;font-family:"Garamond","serif";letter-spacing:-.2pt">Rollback
support (i.e., rollback registrar transfer; not necessarily
transactional).<o:p></o:p></span></p>
<p class="MsoNormal"
style="mso-margin-top-alt:6.0pt;margin-right:0in;margin-bottom:6.0pt;margin-left:0in;text-align:justify"><span
style="font-size:11.0pt;font-family:"Garamond","serif";letter-spacing:-.2pt">JVTeam
firmly believes that the industry needs a new extensible
protocol that addresses all of the above points, and that
the selected protocol should become the industry
standard.</span><span
style="font-size:11.0pt;font-family:"Tahoma","sans-serif";letter-spacing:-.2pt">�</span><span
style="font-size:11.0pt;font-family:"Garamond","serif";letter-spacing:-.2pt">
JVTeam</span><span
style="font-size:11.0pt;font-family:"Tahoma","sans-serif";letter-spacing:-.2pt">�</span><span
style="font-size:11.0pt;font-family:"Garamond","serif";letter-spacing:-.2pt">s
position is that there is infinite room to innovate in many
other aspects of domain-registry systems, but competition at
the protocol level merely fragments the
domain-name-registration industry.</span><span
style="font-size:11.0pt;font-family:"Tahoma","sans-serif";letter-spacing:-.2pt">�</span><span
style="font-size:11.0pt;font-family:"Garamond","serif";letter-spacing:-.2pt">
Conversely, the industry will gain significantly in
efficiency if it adopts a standard protocol that addresses
the listed requirements, particularly in supporting both fat
and thin Registry models.</span><span
style="font-size:11.0pt;font-family:"Tahoma","sans-serif";letter-spacing:-.2pt">�</span><span
style="font-size:11.0pt;font-family:"Garamond","serif";letter-spacing:-.2pt">
<o:p></o:p></span></p>
<p class="MsoNormal"
style="mso-margin-top-alt:6.0pt;margin-right:0in;margin-bottom:6.0pt;margin-left:0in;text-align:justify"><span
style="font-size:11.0pt;font-family:"Garamond","serif";letter-spacing:-.2pt">JVTeam</span><span
style="font-size:11.0pt;font-family:"Tahoma","sans-serif";letter-spacing:-.2pt">�</span><span
style="font-size:11.0pt;font-family:"Garamond","serif";letter-spacing:-.2pt">s
proposed XRP protocol addresses each of the above
points.</span><span
style="font-size:11.0pt;font-family:"Tahoma","sans-serif";letter-spacing:-.2pt">�</span><span
style="font-size:11.0pt;font-family:"Garamond","serif";letter-spacing:-.2pt">
We will present a draft XRP to the IETF as the basis for an
industry standard in Q4 2000, and will invite comments and
suggestions from registrars, registries, and other concerned
individuals and organizations.</span><span
style="font-size:11.0pt;font-family:"Tahoma","sans-serif";letter-spacing:-.2pt">�</span><span
style="font-size:11.0pt;font-family:"Garamond","serif";letter-spacing:-.2pt">
Rather than holding XRP as proprietary, we will undertake
all reasonable measures to obtain consensus on making the
proposed protocol an open industry standard.<o:p></o:p></span></p>
<p class="MsoNormal"
style="mso-margin-top-alt:6.0pt;margin-right:0in;margin-bottom:6.0pt;margin-left:1.0in;text-align:justify;text-indent:-1.0in;page-break-after:avoid"><b><i><span
style="font-family:"Tahoma","sans-serif";letter-spacing:-.2pt">III.2.2.3
�����Benefits of Proposed XRP
Solution<o:p></o:p></span></i></b></p>
<p class="MsoNormal"
style="mso-margin-top-alt:6.0pt;margin-right:0in;margin-bottom:6.0pt;margin-left:0in;text-align:justify"><span
style="font-size:11.0pt;font-family:"Garamond","serif";letter-spacing:-.2pt">JVTeam</span><span
style="font-size:11.0pt;font-family:"Tahoma","sans-serif";letter-spacing:-.2pt">�</span><span
style="font-size:11.0pt;font-family:"Garamond","serif";letter-spacing:-.2pt">s
proposed XRP Solution and fat-registry model will preserve
the current relationships that are familiar to both
registrants and registrars.</span><span
style="font-size:11.0pt;font-family:"Tahoma","sans-serif";letter-spacing:-.2pt">�</span><span
style="font-size:11.0pt;font-family:"Garamond","serif";letter-spacing:-.2pt">
Simultaneously, they will solve the many problems with the
current RRP-based model that is raising costs for registrars
and distressing registrants.</span><span
style="font-size:11.0pt;font-family:"Tahoma","sans-serif";letter-spacing:-.2pt">��</span><span
style="font-size:11.0pt;font-family:"Garamond","serif";letter-spacing:-.2pt">
Nonetheless, despite the fat-registry model</span><span
style="font-size:11.0pt;font-family:"Tahoma","sans-serif";letter-spacing:-.2pt">�</span><span
style="font-size:11.0pt;font-family:"Garamond","serif";letter-spacing:-.2pt">s
obvious advantages, we are willing to consider
alternatives.</span><span
style="font-size:11.0pt;font-family:"Tahoma","sans-serif";letter-spacing:-.2pt">�</span><span
style="font-size:11.0pt;font-family:"Garamond","serif";letter-spacing:-.2pt">
<o:p></o:p></span></p>
<p class="MsoNormal"
style="mso-margin-top-alt:6.0pt;margin-right:0in;margin-bottom:6.0pt;margin-left:0in;text-align:justify"><span
style="font-size:11.0pt;font-family:"Garamond","serif";letter-spacing:-.2pt">On
the one hand it is theoretically possible retain the current
thin-registry model and place more stringent technical
requirements on registrars (while closely policing
compliance). On the other hand, JVTeam believes that a more
practical solution</span><span
style="font-size:11.0pt;font-family:"Tahoma","sans-serif";letter-spacing:-.2pt">�</span><span
style="font-size:11.0pt;font-family:"Garamond","serif";letter-spacing:-.2pt">the
only solution that introduces true stability and domain
security into the market</span><span
style="font-size:11.0pt;font-family:"Tahoma","sans-serif";letter-spacing:-.2pt">�</span><span
style="font-size:11.0pt;font-family:"Garamond","serif";letter-spacing:-.2pt">is
moving to a fat-registry model with a new XML-based protocol
that supports the many enhancements previously listed.</span><span
style="font-size:11.0pt;font-family:"Tahoma","sans-serif";letter-spacing:-.2pt">�</span><span
style="font-size:11.0pt;font-family:"Garamond","serif";letter-spacing:-.2pt">
The XRP protocol</span><span
style="font-size:11.0pt;font-family:"Tahoma","sans-serif";letter-spacing:-.2pt">�</span><span
style="font-size:11.0pt;font-family:"Garamond","serif";letter-spacing:-.2pt">indeed,
any new protocol</span><span
style="font-size:11.0pt;font-family:"Tahoma","sans-serif";letter-spacing:-.2pt">�</span><span
style="font-size:11.0pt;font-family:"Garamond","serif";letter-spacing:-.2pt">must
be designed to fix all the problems with the current model
and protocol.<o:p></o:p></span></p>
<p class="MsoNormal"
style="mso-margin-top-alt:6.0pt;margin-right:0in;margin-bottom:6.0pt;margin-left:0in;text-align:justify"><span
style="font-size:11.0pt;font-family:"Garamond","serif";letter-spacing:-.2pt">To
facilitate the transit in 2001 for current registrars,
JVTeam will provide an open-source version of the registrar
toolkit.</span><span
style="font-size:11.0pt;font-family:"Tahoma","sans-serif";letter-spacing:-.2pt">�</span><span
style="font-size:11.0pt;font-family:"Garamond","serif";letter-spacing:-.2pt">
This enhanced toolkit will simplify the migration efforts of
registrars that currently use the RRP toolkit
only.<o:p></o:p></span></p>
<p class="MsoNormal"
style="mso-margin-top-alt:6.0pt;margin-right:0in;margin-bottom:6.0pt;margin-left:0in;text-align:justify"><span
style="font-size:11.0pt;font-family:"Garamond","serif";letter-spacing:-.2pt">JVTeam
is well qualified to take a lead position in the process of
developing and standardizing the specification for a new
protocol.</span><span
style="font-size:11.0pt;font-family:"Tahoma","sans-serif";letter-spacing:-.2pt">�</span><span
style="font-size:11.0pt;font-family:"Garamond","serif";letter-spacing:-.2pt">
In preparing our proposal for building a modern, extensible
protocol, we relied heavily on the extensive prior
experience that Melbourne IT brought to JVTeam.</span><span
style="font-size:11.0pt;font-family:"Tahoma","sans-serif";letter-spacing:-.2pt">�</span><span
style="font-size:11.0pt;font-family:"Garamond","serif";letter-spacing:-.2pt">
Research groups at Melbourne IT have been using XML for more
than two years, and have developed two XML-based
domain-name-registration interfaces.</span><span
style="font-size:11.0pt;font-family:"Tahoma","sans-serif";letter-spacing:-.2pt">�</span><span
style="font-size:11.0pt;font-family:"Garamond","serif";letter-spacing:-.2pt">
Further, the company currently has XML-based interfaces in
production.</span><span
style="font-size:11.0pt;font-family:"Tahoma","sans-serif";letter-spacing:-.2pt">�</span><span
style="font-size:11.0pt;font-family:"Garamond","serif";letter-spacing:-.2pt">
<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">From:
<a moz-do-not-send="true"
href="http://archive.icann.org/en/tlds/biz4/TLDPolicyPropbiz.htm";>http://archive.icann.org/en/tlds/biz4/TLDPolicyPropbiz.htm</a>
<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<h5>How will complete, up-to-date, reliable, and conveniently
provided Whois data be maintained, updated, and accessed
concerning registrations in the TLD?<o:p></o:p></h5>
<p class="MsoBodyText">JVTeam plans to operate as a <span
style="font-family:"Tahoma","sans-serif"">
�</span>fat<span
style="font-family:"Tahoma","sans-serif"">�</span>
registry in that it will maintain all relevant databases for
the registry in a centralized fashion.<span
style="font-family:"Tahoma","sans-serif"">�</span>
This approach increases stability, security and fault
tolerance of the registry.<span
style="font-family:"Tahoma","sans-serif"">�</span>
JVTeam will backup and escrow all data to ensure its
integrity.<span
style="font-family:"Tahoma","sans-serif"">�</span>
The Whois database will be updated on a real-time basis and
access will be provided subject to strict data privacy and
security requirements.<o:p></o:p></p>
<p class="MsoBodyText">In order to ensure up-to-date Whois data,
included in the registrar Code of Conduct discussed above will
be a provision requiring registrars to make
<span
style="font-family:"Tahoma","sans-serif"">�</span>best
commercial efforts<span
style="font-family:"Tahoma","sans-serif"">�</span>
to maintain up-to-date registrant data.<span
style="font-family:"Tahoma","sans-serif"">�</span>
In addition, JVTeam intends to explore with the registrars the
development of a 3-month Whois data update reminder system.<span
style="font-family:"Tahoma","sans-serif"">�</span>
Registrants would be asked every three months whether their
Whois data remains accurate and would be provided with an
update link if data were out of date.<span
style="font-family:"Tahoma","sans-serif"">�</span>
Moreover, JVTeam will design the registration system to only
complete a registration if all registration data is
complete.<o:p></o:p></p>
<p class="MsoBodyText">A more detailed discussion and
description of Whois services can be found in Registry
Operator<span
style="font-family:"Tahoma","sans-serif"">�</span>s
Proposal Section III.2.8 of this proposal.<o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"
style="margin-top:6.0pt;mso-margin-bottom-alt:auto"><b><span
style="font-size:9.0pt;font-family:"Arial","sans-serif";color:#1F497D">Jeffrey
J. Neuman</span></b><b><span
style="font-size:9.0pt;font-family:"Arial","sans-serif";color:#3366FF"><br>
</span></b><b><span
style="font-size:9.0pt;font-family:"Arial","sans-serif";color:#068658">Neustar,
Inc. / Vice President, Business Affairs</span></b><span
style="font-size:8.5pt;font-family:"Arial","sans-serif";color:#7D7D7D"><br>
<br>
</span><span
style="font-size:8.5pt;font-family:"Arial","sans-serif";color:gray"><o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">
<a class="moz-txt-link-abbreviated"
href="mailto:owner-gnso-thickwhoispdp-wg@xxxxxxxxx";>owner-gnso-thickwhoispdp-wg@xxxxxxxxx</a>
[<a class="moz-txt-link-freetext"
href="mailto:owner-gnso-thickwhoispdp-wg@xxxxxxxxx";>mailto:owner-gnso-thickwhoispdp-wg@xxxxxxxxx</a>]
<b>On Behalf Of </b>Rick Wesson<br>
<b>Sent:</b> Thursday, October 17, 2013 7:11 PM<br>
<b>To:</b> Avri Doria<br>
<b>Cc:</b> Thick Whois WG<br>
<b>Subject:</b> Re: [gnso-thickwhoispdp-wg] in preparation
for the call tomorrow<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal"><span style="font-family:"Courier
New"">Lets see, there was discussion about thick /
thin for many years, first, in the IETF. Then during the
development of EPP. Several new whois replacements were
designed in the intervening years and that discussion to
place mainly at ICANN events. Within the registrar
community it was discussed and within the
GNSO.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Courier
New""><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Courier
New"">Certainly before deciding the color of the
draperies became a PDP we discussed thick -vs- thin
whois models from both a technical and privacy
perspectives.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Courier
New""><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Courier
New"">Just because you didn't participate back in
2002 does not mean the community didn't think about the
issue. There was great discussion on the role of thick
-vs- thin and how EPP would facilitate a thick
registry.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Courier
New""><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Courier
New"">remember, thick registries and EPP were an
invention of the ICANN community. We thought a lot about
it. <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Courier
New""><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Courier
New"">I feel your comments below ignore these facts
and as such I have pressed DELETE. Thanks for playing
ICANN trivia =)<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Courier
New""><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Courier
New"">-rick<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Courier
New""><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Courier
New""><o:p> </o:p></span></p>
</div>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On Thu, Oct 17, 2013 at 3:47 PM, Avri
Doria <<a moz-do-not-send="true"
href="mailto:avri@xxxxxxx"; target="_blank">avri@xxxxxxx</a>>
wrote:<o:p></o:p></p>
<p class="MsoNormal">Hi,<br>
<br>
I don't think we ever had that choice. The board decided
top-down style, that all new gTLDs would be thick. There
never was a PDP on that that I recall, it is just one of
those things that were decided for us by the Board. It
certainly was not a recommendation made by the new gTLD
program, but using the operational philosophy that if we
didn't discuss it, they get to do what they wish, they
decided all new gTLD MUST be thick. So thick they will
be. This was one of the earliest instances of unilateral
decisions with regard to new gTLDs to be made by the Board
and Staff. (though the one to essentially exclude
applicants from previous rounds from contesting without
paying most of a new fee, probably precedes the thick
decision.<br>
<br>
This group has the choice of deciding whether incumbents
need to become thick.<br>
<br>
And this group, I beleive, was charter to discuss about
the details of the thickness requirement for all gTLDs.<br>
<br>
Personally I beleive that if this group had not decided to
impose thickness on the incumbents, the Board and Sr.
Staff would have overruled us and would have done it
anyway. But I can't prove that either.<br>
<span style="color:#888888"><br>
<br>
<span class="hoenzb">avri</span></span><o:p></o:p></p>
<div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
<br>
<br>
On 17 Oct 2013, at 02:34, Alan Greenberg wrote:<br>
<br>
> Not quite how I understood it.<br>
><br>
> I thought (and think) that we have a binary
decision.<br>
><br>
> 1. All gTLDs should be thick.<br>
><br>
> 2. All gTLDs need not be thick.<br>
><br>
> In the latter case, nothing would change today,
and should we have a new round of gTLDs, a decision
would need to be made on thick vs thin if that
distinction is indeed still applicable.<br>
><br>
> Alan<br>
><br>
> At 16/10/2013 09:11 AM, Don Blumenthal wrote:<br>
>> Rick,<br>
>><br>
>> Thick registries for new gTLDs applies only
to the current round, not any future open calls. Part
of the WG's job was to examine if the requirement
should carry forward.<br>
>><br>
>> Don<br>
>><br>
>> From: Rick Wesson < <a
moz-do-not-send="true"
href="mailto:Rick@xxxxxxxxxxxxxxxxxxxxxxxx";>Rick@xxxxxxxxxxxxxxxxxxxxxxxx</a>><br>
>> Date: Tuesday, October 15, 2013 7:30 PM<br>
>> To: Amr Elsadr <<a moz-do-not-send="true"
href="mailto:aelsadr@xxxxxxxxxxx";>aelsadr@xxxxxxxxxxx</a>><br>
>> Cc: Thick Thin PDP < <a
moz-do-not-send="true"
href="mailto:gnso-thickwhoispdp-wg@xxxxxxxxx";>gnso-thickwhoispdp-wg@xxxxxxxxx</a>><br>
>> Subject: Re: [gnso-thickwhoispdp-wg] in
preparation for the call tomorrow<br>
>><br>
>> Amr<br>
>><br>
>> All new gTLDs are thick by design. If you
want to reexamine this, we would need to reexamine the
ticck model which IMNSHO has been settled and is not
within the scope of our current charter. We are to
examin transition only.<br>
>><br>
>> The data is published, the only relevant
issue is the location of the entity doing the
publishing.<br>
>><br>
>> -rick<br>
>><br>
>><br>
>><br>
>> On Tue, Oct 15, 2013 at 6:47 AM, Amr Elsadr
<<a moz-do-not-send="true"
href="mailto:aelsadr@xxxxxxxxxxx";>aelsadr@xxxxxxxxxxx</a>>
wrote:<br>
>> Hi Steve,<br>
>><br>
>> I agree with most of your assessment except
on what the question that needs answering. The way I
see it is that we shouldn't be asking about exposure
of a registrants registration data by Registrar in
country A as opposed to exposure via Registry in
country B. It's about the cross jurisdictional
transfer of the data…, not the exposure. The exposure
is the result of the transfer.<br>
>><br>
>> The relevance of your question is significant
for existing .com registrants (for example), but this
PDP will also affect all future new gTLDs beyond the
current round of new ones, and will probably affect
new registrants who do not yet exist.<br>
>><br>
>> Addressing the transfer of the registration
data instead of the exposure covers both scenarios;
the rights afforded to both existing and future
registrants by legal/privacy protections.<br>
>><br>
>> Thanks.<br>
>><br>
>> Amr<br>
>><br>
>> On Oct 14, 2013, at 11:25 PM, "Metalitz,
Steven" <<a moz-do-not-send="true"
href="mailto:met@xxxxxxx";>met@xxxxxxx</a>> wrote:<br>
>><br>
>>> I have some concerns about this approach.
The registries (especially the ones that would
actually be undergoing the transition!) and the
registrars are big boys and girls. They have been on
notice for a long time that this transition was under
consideration, and indeed several of them have
participated actively in our working group. Their
consistent support for the transition speaks volumes.
As our report states, “the fact that it [the WG] can
find no public objections from the registry or
registrar community indicates that no problems have
been identified.”<br>
>>><br>
>>> In any event, it is not ICANN’s job to
look out for the legal interests of registries and
registrars. Its focus should be on looking out for
registrants (it goes without saying that ICANN will
look out for ICANN and any potential corporate
liabilities—which is in itself a reason why Alan’s
proposal may not be viable). So if any legal review
needs to be specified, the main question ought to
whether a registrant whose Whois data is currently
made publicly available through a registrar in
country A would suffer any incremental legal harm or
exposure if the same data were also made publicly
available through a (thick) registry in the US, as is
the case now with all registrations in US-based thick
registries that are sponsored by non-US registrars.
The review should also consider whether the current
contractual framework can be used to ameliorate any
harms found or whether it needs to be adjusted to
accommodate this. For example, as an implementation
matter, it could be useful for ICANN to provide
guidance on how the long-standing contractual
requirement that registrars give notice to, and obtain
consent, from each registrant for uses of any
personally identifiable data submitted by the
registrant should apply to registrations involved in
the transition. See sections 3.7.7.4 through 3.7.7.6
of the RAA (not changed from the 2009 to 2013
versions).<br>
>>><br>
>>> Steve<br>
>>><br>
>>><br>
>>> From: <a moz-do-not-send="true"
href="mailto:owner-gnso-thickwhoispdp-wg@xxxxxxxxx";>owner-gnso-thickwhoispdp-wg@xxxxxxxxx</a>
[ mailto:<a moz-do-not-send="true"
href="mailto:owner-gnso-thickwhoispdp-wg@xxxxxxxxx";>owner-gnso-thickwhoispdp-wg@xxxxxxxxx</a>]
On Behalf Of Alan Greenberg<br>
>>> Sent: Monday, October 14, 2013 3:42 PM<br>
>>> To: Volker Greimann; Rick Wesson<br>
>>> Cc: Mike O'Connor; Thick Whois WG<br>
>>> Subject: Re: [gnso-thickwhoispdp-wg] in
preparation for the call tomorrow<br>
>>><br>
>>> Let me try to describe what *I* think
that we need from the "legal review". I make no claim
that it would satisfy NCSG not that it is viable
(although I think it is).<br>
>>><br>
>>> We want a high degree of comfort that
ICANN, the registry involved, and the registrars
involved will not be in violation of privacy
legislation if a transition from thick to thin WHOIS
is carried out. A sample of registrar should include
those sponsoring large a plurality of the applicable
registrations as well as a sampling of the larger
registrants in jurisdictions with particularly
stringent privacy laws (perhaps selected EU countries,
Canada, selected Asia-Pacific countries). For
registries and registrars, I would suggest that such a
comfort level could be reached by consulting with the
selected registry and registrars, with the presumption
that they will consult their own legal counsels if
needed.<br>
>>><br>
>>> I use term "high degree of comfort"
because I do not believe that we can get an iron-clad
guarantee - the privacy world is too complex. But I
believe that it is sufficient for going forward.<br>
>>><br>
>>> Should the WG and ICANN staff agree, I
would be pleased to try to put this into more formal
language.<br>
>>><br>
>>> Alan<br>
>>><br>
>>> At 14/10/2013 01:45 PM, Volker Greimann
wrote:<br>
>>><br>
>>> Rich,<br>
>>><br>
>>> I think you are arguing a different issue
here. The only issue we (and therefore the legal
review) need to be concerned with is the rights of the
parties listed in the whois in their own private
details and how they may be affected in a move of
their data from whereever they are stored now to the
US, not third party rights. This is a greatly reduced
scope from whe indeed lunatic scenario you depict.<br>
>>><br>
>>> Questions that need to be answered are:<br>
>>> Do the general registration terms of most
registrars cover such a move? I would argue they do
already for any registrar I have seen.<br>
>>> What are the data protection requirements
that the registry operator must meet prior to being
able to receive the data?<br>
>>><br>
>>> Best,<br>
>>><br>
>>> Volker<br>
>>><br>
>>><br>
>>><br>
>>> Mike,<br>
>>><br>
>>> Having spent some time in the IETF I find
it hard to apply those rules you outlined belwo, here.
Our consensus is not about technical issues.<br>
>>><br>
>>> Take for instance, the idea that a public
record being published in jurisdiction A is now
published (publicly) in jurisdiction B and a third
party takes issue with the move, though this 3rd party
has no relationship to the domain, registrant, nor
registrar A or B. Finally a 4th party takes issue with
the rights the 3rd party might have should the
publishing of this record change from A to B that they
incest that ICANN review all 209 international laws on
privacy and show how the 3rd party might be effected
should A or B land in any one of those places -- and
provide a report to the GNSO describing the 3rd
parties effected rights.<br>
>>><br>
>>> In the IETF we would have ignored such
lunacy, because its not technical. someone from the
working group, probably the chair, would have sat
these folks down and asked them to focus one a more
productive side of the problems at hand. A good chair
probably would have pushed for a binary answer to the
issue at hand. So that those consuming our work
product would have an answer -- preferably in binary.<br>
>>><br>
>>> Since this is not the IETF, we might
check our charter, which makes no mention of rough
consensus though many of the terms you defined are
defined at http ://<a moz-do-not-send="true"
href="http://gnso.icann.org/en/issues/thick-whois-charter-08oct12-en.pdf";
target="_blank">gnso.icann.org/en/issues/thick-whois-charter-08oct12-en.pdf</a><br>
>>><br>
>>><br>
>>> Finally, I'd like to point out that the
IETF way you suggested is orthoginal to the
designations in our charter and I advise you remind
the working group of the charter and to follow those
rules we have agreed to.<br>
>>><br>
>>> -rick<br>
>>><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>> On Mon, Oct 14, 2013 at 9:39 AM, Mike
O'Connor <<a moz-do-not-send="true"
href="mailto:mike@xxxxxxxxxx";>mike@xxxxxxxxxx</a>>
wrote:<br>
>>><br>
>>> hi all,<br>
>>><br>
>>> i've been reflecting on where we're at
and have arrived at two key words i want us to focus
on in preparation for the call tomorrow --
"objections" and "precision"<br>
>>><br>
>>> we've heard back from the General Counsel
that they would like to see more precision in our
request for a legal review. i wrote a response on the
spur of the moment that i'm regretting now.<br>
>>><br>
>>> homework assignment: try to come up with
language that clarifies what we are asking the GC to
do, and also come up with language that limits the
scope of that effort to something that is achievable
within reasonable time and budget.<br>
>>><br>
>>> i'm feeling the need to draw this part of
the conversation to a close and am hoping that we can
get this last visit to the privacy issue completed on
the call tomorrow. if, at the end of the call, we
still are not there, i'm going to ask the group's
permission to go off and do the duty of the Chair,
which is to reflect on the state of our work with the
following structure in mind.<br>
>>><br>
>>> IETF - Consensus<br>
>>><br>
>>> Credo<br>
>>> Do's<br>
>>> decisions are made by (more or
less) consent of all participants<br>
>>><br>
>>> the actual products of engineering
trump theoretical designs<br>
>>> Don'ts<br>
>>> we don't let a single individual
make the decisions<br>
>>> nor do we let the majority dictate
decisions<br>
>>><br>
>>> nor do we allow decisions to be
made in a vacuum without practical experience<br>
>>> Require rough, not full consensus<br>
>>> If the chair of a working group
determines that a technical issue brought forward by
an objector has been truly considered by the working
group, and<br>
>>> the working group has made an
informed decision that the objection has been answered
or is not enough of a technical problem to prevent
moving forward,<br>
>>><br>
>>> the chair can declare that there
is rough consensus to go forward, the objection
notwithstanding.<br>
>>> Lack of disagreement is more important
than agreement<br>
>>> _determining_ consensus and _coming to_
consensus are different things than _having_ consensus<br>
>>> Consensus is not when everyone is
happy and agrees that the chosen solution is the best
one<br>
>>> Consensus is when everyone is
sufficiently satisfied with the chosen solution, such
that they no longer have specific objections to it<br>
>>><br>
>>> Engineering always involves a set of
tradeoffs. It is almost certain that any time
engineering choices need to be made, there will be
options that appeal to some people that are not
appealing to some others. The key is to separate
those choices that are simply unappealing from those
that are truly problematic.<br>
>>><br>
>>> this outline is lifted from an IETF draft
which seems like a good guideline. the full draft can
be found here.<br>
>>><br>
>>> <a moz-do-not-send="true"
href="http://tools.ietf.org/html/draft-resnick-on-consensus-05";
target="_blank">
http://tools.ietf.org/html/draft-resnick-on-consensus-05</a><br>
>>><br>
>>> this is why i want us to focus on
"objections" and "precision" on our call.<br>
>>><br>
>>> mikey<br>
>>><br>
>>> PHONE: <a moz-do-not-send="true"
href="tel:651-647-6109">651-647-6109</a>, FAX: <a
moz-do-not-send="true" href="tel:866-280-2356">
866-280-2356</a>, WEB: <a moz-do-not-send="true"
href="http://www.haven2.com";
target="_blank">www.haven2.com</a>,
HANDLE: OConnorStP (ID for Twitter, Facebook,
LinkedIn, etc.)<br>
>>><br>
>>><br>
>>><br>
>>><br>
>>> --<br>
>>><br>
>>><br>
>>> Bei weiteren Fragen stehen wir Ihnen
gerne zur<br>
>>> Verfügung.<br>
>>><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>> Mit freundlichen Grüßen,<br>
>>><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>> Volker A. Greimann<br>
>>><br>
>>><br>
>>> - Rechtsabteilung -<br>
>>><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>> Key-Systems GmbH<br>
>>><br>
>>><br>
>>> Im Oberen Werk 1<br>
>>><br>
>>><br>
>>> 66386 St. Ingbert<br>
>>><br>
>>><br>
>>> Tel.:<br>
>>> +49<br>
>>> (0) 6894 - 9396 901<br>
>>><br>
>>><br>
>>><br>
>>> Fax.:<br>
>>> +49<br>
>>> (0) 6894 - 9396 851<br>
>>><br>
>>><br>
>>><br>
>>> Email:<br>
>>><br>
>>><br>
>>><br>
>>> <a moz-do-not-send="true"
href="mailto:vgreimann@xxxxxxxxxxxxxxx";>vgreimann@xxxxxxxxxxxxxxx</a><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>> Web:<br>
>>><br>
>>> <a moz-do-not-send="true"
href="http://www.key-systems.net";
target="_blank">www.key-systems.net</a><br>
>>><br>
>>> /<br>
>>><br>
>>><br>
>>><br>
>>><br>
>>> <a moz-do-not-send="true"
href="http://www.RRPproxy.net";
target="_blank">www.RRPproxy.net</a><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>> <a moz-do-not-send="true"
href="http://www.domaindiscount24.com";
target="_blank">www.domaindiscount24.com</a><br>
>>> /<br>
>>><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>> <a moz-do-not-send="true"
href="http://www.BrandShelter.com";
target="_blank">www.BrandShelter.com</a><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>> Folgen Sie uns bei Twitter oder werden
Sie unser Fan bei<br>
>>> Facebook:<br>
>>><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>> <a moz-do-not-send="true"
href="http://www.facebook.com/KeySystems";
target="_blank">www.facebook.com/KeySystems</a><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>> <a moz-do-not-send="true"
href="http://www.twitter.com/key_systems";
target="_blank">www.twitter.com/key_systems</a><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>> Geschäftsführer: Alexander Siffrin<br>
>>><br>
>>><br>
>>> Handelsregister Nr.: HR B 18835 -
Saarbruecken<br>
>>><br>
>>><br>
>>> Umsatzsteuer ID.: DE211006534<br>
>>><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>> Member of the KEYDRIVE GROUP<br>
>>><br>
>>><br>
>>> <a moz-do-not-send="true"
href="http://www.keydrive.lu";
target="_blank">www.keydrive.lu</a><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>> Der Inhalt dieser Nachricht ist
vertraulich und nur für den<br>
>>> angegebenen<br>
>>><br>
>>><br>
>>><br>
>>> Empfänger bestimmt. Jede Form der
Kenntnisgabe, Veröffentlichung<br>
>>> oder<br>
>>><br>
>>><br>
>>><br>
>>> Weitergabe an Dritte durch den Empfänger
ist unzulässig. Sollte<br>
>>> diese<br>
>>><br>
>>><br>
>>><br>
>>> Nachricht nicht für Sie bestimmt sein, so
bitten wir Sie, sich<br>
>>> mit uns<br>
>>><br>
>>><br>
>>><br>
>>> per E-Mail oder telefonisch in Verbindung
zu<br>
>>> setzen.<br>
>>><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>>
--------------------------------------------<br>
>>><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>> Should you have any further questions,
please do not hesitate to<br>
>>> contact<br>
>>><br>
>>><br>
>>><br>
>>> us.<br>
>>><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>> Best regards,<br>
>>><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>> Volker A. Greimann<br>
>>><br>
>>><br>
>>> - legal department -<br>
>>><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>> Key-Systems GmbH<br>
>>><br>
>>><br>
>>> Im Oberen Werk 1<br>
>>><br>
>>><br>
>>> 66386 St. Ingbert<br>
>>><br>
>>><br>
>>> Tel.:<br>
>>> +49<br>
>>> (0) 6894 - 9396 901<br>
>>><br>
>>><br>
>>><br>
>>> Fax.:<br>
>>> +49<br>
>>> (0) 6894 - 9396 851<br>
>>><br>
>>><br>
>>><br>
>>> Email:<br>
>>><br>
>>><br>
>>><br>
>>> <a moz-do-not-send="true"
href="mailto:vgreimann@xxxxxxxxxxxxxxx";>vgreimann@xxxxxxxxxxxxxxx</a><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>> Web:<br>
>>><br>
>>> <a moz-do-not-send="true"
href="http://www.key-systems.net";
target="_blank">www.key-systems.net</a><br>
>>><br>
>>> /<br>
>>><br>
>>><br>
>>><br>
>>><br>
>>> <a moz-do-not-send="true"
href="http://www.RRPproxy.net";
target="_blank">www.RRPproxy.net</a><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>> <a moz-do-not-send="true"
href="http://www.domaindiscount24.com";
target="_blank">www.domaindiscount24.com</a><br>
>>> /<br>
>>><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>> <a moz-do-not-send="true"
href="http://www.BrandShelter.com";
target="_blank">www.BrandShelter.com</a><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>> Follow us on Twitter or join our fan
community on Facebook and<br>
>>> stay<br>
>>><br>
>>><br>
>>><br>
>>> updated:<br>
>>><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>> <a moz-do-not-send="true"
href="http://www.facebook.com/KeySystems";
target="_blank">www.facebook.com/KeySystems</a><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>> <a moz-do-not-send="true"
href="http://www.twitter.com/key_systems";
target="_blank">www.twitter.com/key_systems</a><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>> CEO: Alexander Siffrin<br>
>>><br>
>>><br>
>>> Registration No.: HR B 18835 -
Saarbruecken<br>
>>><br>
>>><br>
>>> V.A.T. ID.: DE211006534<br>
>>><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>> Member of the KEYDRIVE GROUP<br>
>>><br>
>>><br>
>>> <a moz-do-not-send="true"
href="http://www.keydrive.lu";
target="_blank">www.keydrive.lu</a><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>> This e-mail and its attachments is
intended only for the person<br>
>>> to whom<br>
>>><br>
>>><br>
>>><br>
>>> it is addressed. Furthermore it is not
permitted to publish any<br>
>>> content<br>
>>><br>
>>><br>
>>><br>
>>> of this email. You must not use,
disclose, copy, print or rely<br>
>>> on this<br>
>>><br>
>>><br>
>>><br>
>>> e-mail. If an addressing or transmission
error has misdirected<br>
>>> this<br>
>>><br>
>>><br>
>>><br>
>>> e-mail, kindly notify the author by
replying to this e-mail or<br>
>>> contacting<br>
>>><br>
>>><br>
>>><br>
>>> us by telephone.<br>
>>><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>><br>
>><o:p></o:p></p>
</div>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung.
Mit freundlichen Grüßen,
Volker A. Greimann
- Rechtsabteilung -
Key-Systems GmbH
Im Oberen Werk 1
66386 St. Ingbert
Tel.: +49 (0) 6894 - 9396 901
Fax.: +49 (0) 6894 - 9396 851
Email: <a class="moz-txt-link-abbreviated"
href="mailto:vgreimann@xxxxxxxxxxxxxxx";>vgreimann@xxxxxxxxxxxxxxx</a>
Web: <a class="moz-txt-link-abbreviated"
href="http://www.key-systems.net";>www.key-systems.net</a> / <a
class="moz-txt-link-abbreviated"
href="http://www.RRPproxy.net";>www.RRPproxy.net</a>
<a class="moz-txt-link-abbreviated"
href="http://www.domaindiscount24.com";>www.domaindiscount24.com</a> / <a
class="moz-txt-link-abbreviated"
href="http://www.BrandShelter.com";>www.BrandShelter.com</a>
Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook:
<a class="moz-txt-link-abbreviated"
href="http://www.facebook.com/KeySystems";>www.facebook.com/KeySystems</a>
<a class="moz-txt-link-abbreviated"
href="http://www.twitter.com/key_systems";>www.twitter.com/key_systems</a>
Geschäftsführer: Alexander Siffrin
Handelsregister Nr.: HR B 18835 - Saarbruecken
Umsatzsteuer ID.: DE211006534
Member of the KEYDRIVE GROUP
<a class="moz-txt-link-abbreviated"
href="http://www.keydrive.lu";>www.keydrive.lu</a>
Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen
Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder
Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht
nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder
telefonisch in Verbindung zu setzen.
--------------------------------------------
Should you have any further questions, please do not hesitate to contact us.
Best regards,
Volker A. Greimann
- legal department -
Key-Systems GmbH
Im Oberen Werk 1
66386 St. Ingbert
Tel.: +49 (0) 6894 - 9396 901
Fax.: +49 (0) 6894 - 9396 851
Email: <a class="moz-txt-link-abbreviated"
href="mailto:vgreimann@xxxxxxxxxxxxxxx";>vgreimann@xxxxxxxxxxxxxxx</a>
Web: <a class="moz-txt-link-abbreviated"
href="http://www.key-systems.net";>www.key-systems.net</a> / <a
class="moz-txt-link-abbreviated"
href="http://www.RRPproxy.net";>www.RRPproxy.net</a>
<a class="moz-txt-link-abbreviated"
href="http://www.domaindiscount24.com";>www.domaindiscount24.com</a> / <a
class="moz-txt-link-abbreviated"
href="http://www.BrandShelter.com";>www.BrandShelter.com</a>
Follow us on Twitter or join our fan community on Facebook and stay updated:
<a class="moz-txt-link-abbreviated"
href="http://www.facebook.com/KeySystems";>www.facebook.com/KeySystems</a>
<a class="moz-txt-link-abbreviated"
href="http://www.twitter.com/key_systems";>www.twitter.com/key_systems</a>
CEO: Alexander Siffrin
Registration No.: HR B 18835 - Saarbruecken
V.A.T. ID.: DE211006534
Member of the KEYDRIVE GROUP
<a class="moz-txt-link-abbreviated"
href="http://www.keydrive.lu";>www.keydrive.lu</a>
This e-mail and its attachments is intended only for the person to whom it is
addressed. Furthermore it is not permitted to publish any content of this
email. You must not use, disclose, copy, print or rely on this e-mail. If an
addressing or transmission error has misdirected this e-mail, kindly notify the
author by replying to this e-mail or contacting us by telephone.
</pre>
</body>
</html>
<<<
Chronological Index
>>> <<<
Thread Index
>>>
|