From JGould@verisign.com Wed May 1 05:33:16 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C86721F9789 for ; Wed, 1 May 2013 05:33:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ReybE5bUUDgl for ; Wed, 1 May 2013 05:33:11 -0700 (PDT) Received: from exprod6og127.obsmtp.com (exprod6og127.obsmtp.com [64.18.1.78]) by ietfa.amsl.com (Postfix) with ESMTP id CAE2A21F976B for ; Wed, 1 May 2013 05:33:00 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob127.postini.com ([64.18.5.12]) with SMTP ID DSNKUYELfLi6u1o16PJ4TbLZEXKrcJZTUwWZ@postini.com; Wed, 01 May 2013 05:33:00 PDT Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id r41CWv3V006489 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 1 May 2013 08:32:59 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Wed, 1 May 2013 08:32:56 -0400 From: "Gould, James" To: "EPP Provreg (provreg@ietf.org)" Thread-Topic: Launch Phase EPP Extension Version 10 Thread-Index: AQHORmgC76piG2RBeE2BJXZKE2THBg== Date: Wed, 1 May 2013 12:32:56 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.173.152.4] Content-Type: multipart/alternative; boundary="_000_CDA682A04EB73jgouldverisigncom_" MIME-Version: 1.0 Subject: [provreg] Launch Phase EPP Extension Version 10 X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2013 12:33:16 -0000 --_000_CDA682A04EB73jgouldverisigncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Wil Tan, Gavin Brown and I have updated the Launch Phase EPP Extension Mapping to Version 10. You can find the draft at the URL http://tools.ietf= .org/html/draft-tan-epp-launchphase-10. This version includes the following changes: 1. Changed noticeIDType from base64Binary to token to be compatible wit= h draft-lozano-tmch-func-spec-05. 2. Changed codeType from base64Binary to token to be more generic. 3. Updated based on feedback from Alexander Mayrhofer, which include: 1. Changed "extension to the domain name extension" to "extension to the domain name mapping". 2. Changed use of 2004 return code to 2306 return code when phase passed mismatches active phase and sub-phase. 3. Changed description of "allocated" and "rejected" statuses. 4. Moved sentence on a synchronous command without the use of an intermediate application, then an Application Identifier MAY not be needed to the Application Identifier section. 5. Restructured the Mark Validation Models section to include the " element" sub-section, the " element" sub-section, and the Digital Signature sub- section. 6. Changed "Registries may" to "Registries MAY". 7. Changed "extensed" to "extended" in "Availability Check Form" section. 8. Broke the mix of create forms in the "EPP Command" section to a fourth "Mixed Create Form" with its own sub- section. 9. Removed "displayed or" from "displayed or accepted" in the description. 10. Replaced "given domain name is supported" with "given domain name are supported" in the "Create Response" section. 11. Changed the reference of 2303 (object does not exist) in the "Security Considerations" section to 2201 (authorization error). 12. Added arrow from "invalid" status to "pendingValidation" status and "pendingAllocation" status to "rejected" status in the State Transition Diagram. 4. Added the "C:" and "S:" example prefixes and related text in the "Conventions Used in This Document" section. We are hoping that the draft stabilizes with this version. Please reply with any feedback. Thanks, JG James F. Gould Verisign "This message (including any attachments) is intended only for the use of t= he individual or entity to which it is addressed, and may contain informati= on that is non-public, proprietary, privileged, confidential and exempt fro= m disclosure under applicable law or may be constituted as attorney work pr= oduct. If you are not the intended recipient, you are hereby notified that = any use, dissemination, distribution, or copying of this communication is s= trictly prohibited. If you have received this message in error, notify send= er immediately and delete this message immediately." --_000_CDA682A04EB73jgouldverisigncom_ Content-Type: text/html; charset="us-ascii" Content-ID: <5E40BC27D29A564B9BE518BC541EF837@verisign.com> Content-Transfer-Encoding: quoted-printable
Wil Tan, Gavin Brown and I have updated the Launch Phase EPP Extension=
Mapping to Version 10.  You can find the draft at the URL&nb= sp;http= ://tools.ietf.org/html/draft-tan-epp-launchphase-10.  This ve= rsion
includes the following changes:

   1.  Changed noti=
ceIDType from base64Binary to token to be compatible with
       draft-lozano-tmch-func-spec-05.
   2.  Changed codeType from base64Binary to token to be more generic.
   3.  Updated based on feedback from Alexander Mayrhofer, which
       include:
       1.   Changed "extension to the domain name extension" to
            "extension to the domain name mapping".
       2.   Changed use of 2004 return code to 2306 return code when
            phase passed mismatches active phase and sub-phase.
       3.   Changed description of "allocated" and "rejected=
" statuses.
       4.   Moved sentence on a synchronous <domain:create> command
            without the use of an intermediate application, then an
            Application Identifier MAY not be needed to the Application
            Identifier section.
       5.   Restructured the Mark Validation Models section to include
            the "<launch:codeMark> element" sub-section, th=
e "<mark:
            mark> element" sub-section, and the Digital Signature s=
ub-
            section.
       6.   Changed "Registries may" to "Registries MAY"=
;.
       7.   Changed "extensed" to "extended" in "A=
vailability Check
            Form" section.
       8.   Broke the mix of create forms in the "EPP <create> C=
ommand"
            section to a fourth "Mixed Create Form" with its own =
sub-
            section.
       9.   Removed "displayed or" from "displayed or accept=
ed" in the
            <launch:acceptedDate> description.
       10.  Replaced "given domain name is supported" with "=
given domain
            name are supported" in the "Create Response" sec=
tion.
       11.  Changed the reference of 2303 (object does not exist) in the
            "Security Considerations" section to 2201 (authorizat=
ion
            error).
       12.  Added arrow from "invalid" status to "pendingVal=
idation"
            status and "pendingAllocation" status to "reject=
ed" status
            in the State Transition Diagram.
   4.  Added the "C:" and "S:" example prefixes and rel=
ated text in the
       "Conventions Used in This Document" section.


We are hoping that the draft = stabilizes with this version.  Please reply
with any feedback.

Thanks,

JG

James F. Gould
Verisign




“This message (including any attachments) is= intended only for the use of the individual or entity to which it is addre= ssed, and may contain information that is non-public, proprietary, privileg= ed, confidential and exempt from disclosure under applicable law or may be constituted as attorney work product. If yo= u are not the intended recipient, you are hereby notified that any use, dis= semination, distribution, or copying of this communication is strictly proh= ibited. If you have received this message in error, notify sender immediately and delete this message immedi= ately.”
--_000_CDA682A04EB73jgouldverisigncom_-- From Benoit.Levac@demandmedia.com Fri May 3 09:42:55 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8914F21F8EC2 for ; Fri, 3 May 2013 09:42:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.691 X-Spam-Level: * X-Spam-Status: No, score=1.691 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_EQ_STATIC=1.172, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, J_CHICKENPOX_66=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3QiRmmgMEoKS for ; Fri, 3 May 2013 09:42:49 -0700 (PDT) Received: from SMOBarracuda01.demandmedia.com (63-234-250-132.dia.static.qwest.net [63.234.250.132]) by ietfa.amsl.com (Postfix) with ESMTP id 1902921F97B9 for ; Fri, 3 May 2013 08:46:20 -0700 (PDT) X-ASG-Debug-ID: 1367595969-0511250f001ad480001-ybujJl Received: from smo92wexca02.corp.dm.local ([10.45.16.67]) by SMOBarracuda01.demandmedia.com with ESMTP id we1MRp61xiaYLlND; Fri, 03 May 2013 08:46:09 -0700 (PDT) X-Barracuda-Envelope-From: Benoit.Levac@demandmedia.com X-ASG-Whitelist: Client Received: from SMO92WEXVS01.corp.dm.local ([10.45.16.21]) by smo92wexca02.corp.dm.local ([10.45.16.67]) with mapi; Fri, 3 May 2013 08:46:10 -0700 From: Ben Levac To: "Gould, James" , "EPP Provreg (provreg@ietf.org)" Date: Fri, 3 May 2013 08:46:08 -0700 Thread-Topic: Launch Phase EPP Extension Version 10 X-ASG-Orig-Subj: RE: Launch Phase EPP Extension Version 10 Thread-Index: AQHORmgC76piG2RBeE2BJXZKE2THBpjzkspA Message-ID: <1DC00B9E9F0BAB44A146755EE8B1642D62E2F4BA87@SMO92WEXVS01.corp.dm.local> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_1DC00B9E9F0BAB44A146755EE8B1642D62E2F4BA87SMO92WEXVS01c_" MIME-Version: 1.0 X-Barracuda-Connect: UNKNOWN[10.45.16.67] X-Barracuda-Start-Time: 1367595969 X-Barracuda-URL: http://10.45.16.24:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at demandmedia.com X-Barracuda-BRTS-Status: 1 Subject: Re: [provreg] Launch Phase EPP Extension Version 10 X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 16:42:55 -0000 --_000_1DC00B9E9F0BAB44A146755EE8B1642D62E2F4BA87SMO92WEXVS01c_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable James, I do have some questions, specifically around how the proposed model handle= s simultaneous phases. 1 - The first question is around the handling of overlapping claims and lan= drush (which will most likely be the case for us). If I understood section= 2.2 of the requirement, a landrush application that was NOT subject to a c= laim would pass the launch:create extension with just the phase like this: landrush While a landrush application that WAS subject to a claims would pass the fo= llowing extension: claims ... COMMENT: This means that we can't judge the phase based only the value of t= he phase element, but we also have to base it off the name which seems a bi= t awkward. 2 - In the case where we are running a special custom "sunrise 2" to restri= ct registration to a specific group, it's not clear to me whether we should= follow the proposed landrush from 2.2: Without claim: custom With claim: claims ... Or whether we should use a custom phase sort of as is proposed in section 3= .3.4: Without claim: custom With claim: custom ... 3 - Finally there might be a scenario where we might want to run 2 concurre= nt custom phases. Say that there are some domains which will require mark = data to be registered, even in a custom sunrise or landrush. We would expe= ct a "custom" phase with mark information to be passed. But if this happen= s during a custom sunrise, then I can't think of a good way to handle this= , other than creating a hybrid custom phase, so you would use either: custom custom 4 - COMMENT: Given 1, 2 and 3, wouldn't it be better if we allowed someone = to send multiple independent phases? Different scenarios include completel= y different launch:create extensions, one for each phase with the data requ= ired for that phase. Or just allowing multiple phase elements inside the = single extension? There are other options that could be cleaner such as tu= rning the launch:create into a collection, but that would be a big schema c= hange at this point in the game... 5 - My next question is regarding the INFO command specified in 3.2: If the application/registration was created as part of a claim request, wou= ld the info response ever show the claims information? So for example, if = I created a landrush domain that had a claim against it with what I assume = is the proposed method: claims ... Then what INFO command extension phase information would the registrar have= to send to get information back on this domain? And what phase informatio= n would the server return to him in the response? 6 - Is phase information really required for INFO requests? I assume that = application IDs are unique to the registry? So if you pass it in, then we = would return information regarding the application including the phase. Ot= herwise, we are infoing a registration. In this case, I'm not sure why we = would want to send in the extension? Sorry for the long list of questions this late in the process, but I just w= ant to make sure that we (and everyone on the list) have a clear understand= ing of the mechanisms, especially around concurrent phases which does tend = to get a bit more complicated. Cheers, Ben From: provreg-bounces@ietf.org [mailto:provreg-bounces@ietf.org] On Behalf = Of Gould, James Sent: Wednesday, May 01, 2013 5:33 AM To: EPP Provreg (provreg@ietf.org) Subject: [provreg] Launch Phase EPP Extension Version 10 Wil Tan, Gavin Brown and I have updated the Launch Phase EPP Extension Mapping to Version 10. You can find the draft at the URL http://tools.ietf= .org/html/draft-tan-epp-launchphase-10. This version includes the following changes: 1. Changed noticeIDType from base64Binary to token to be compatible wit= h draft-lozano-tmch-func-spec-05. 2. Changed codeType from base64Binary to token to be more generic. 3. Updated based on feedback from Alexander Mayrhofer, which include: 1. Changed "extension to the domain name extension" to "extension to the domain name mapping". 2. Changed use of 2004 return code to 2306 return code when phase passed mismatches active phase and sub-phase. 3. Changed description of "allocated" and "rejected" statuses. 4. Moved sentence on a synchronous command without the use of an intermediate application, then an Application Identifier MAY not be needed to the Application Identifier section. 5. Restructured the Mark Validation Models section to include the " element" sub-section, the " element" sub-section, and the Digital Signature sub- section. 6. Changed "Registries may" to "Registries MAY". 7. Changed "extensed" to "extended" in "Availability Check Form" section. 8. Broke the mix of create forms in the "EPP Command" section to a fourth "Mixed Create Form" with its own sub- section. 9. Removed "displayed or" from "displayed or accepted" in the description. 10. Replaced "given domain name is supported" with "given domain name are supported" in the "Create Response" section. 11. Changed the reference of 2303 (object does not exist) in the "Security Considerations" section to 2201 (authorization error). 12. Added arrow from "invalid" status to "pendingValidation" status and "pendingAllocation" status to "rejected" status in the State Transition Diagram. 4. Added the "C:" and "S:" example prefixes and related text in the "Conventions Used in This Document" section. We are hoping that the draft stabilizes with this version. Please reply with any feedback. Thanks, JG James F. Gould Verisign "This message (including any attachments) is intended only for the use of t= he individual or entity to which it is addressed, and may contain informati= on that is non-public, proprietary, privileged, confidential and exempt fro= m disclosure under applicable law or may be constituted as attorney work pr= oduct. If you are not the intended recipient, you are hereby notified that = any use, dissemination, distribution, or copying of this communication is s= trictly prohibited. If you have received this message in error, notify send= er immediately and delete this message immediately." ________________________________ Please NOTE: This electronic message, including any attachments, may includ= e privileged, confidential and/or inside information owned by Demand Media,= Inc. Any distribution or use of this communication by anyone other than th= e intended recipient(s) is strictly prohibited and may be unlawful. If you = are not the intended recipient, please notify the sender by replying to thi= s message and then delete it from your system. Thank you. --_000_1DC00B9E9F0BAB44A146755EE8B1642D62E2F4BA87SMO92WEXVS01c_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

James,<= /p>

 <= /p>

I do have some questions,= specifically around how the proposed model handles simultaneous phases.

 <= /p>

1 – The first quest= ion is around the handling of overlapping claims and landrush (which will m= ost likely be the case for us).  If I understood section 2.2 of the requirement, a landrush application that was NOT subject to a claim wo= uld pass the launch:create extension with just the phase like this:

 <= /p>

<launch:create xmlns:l= aunch=3D"urn:ietf:params:xml:ns:launch-1.0" type=3D"applicat= ion">

    &= nbsp;           <launc= h:phase>landrush</launch:phase>

</launch:create>

 

While a landrush applicat= ion that WAS subject to a claims would pass the following extension:

 <= /p>

<launch:create xmlns:l= aunch=3D"urn:ietf:params:xml:ns:launch-1.0">=

  <launch:phase n= ame=3D”landrush”>claims</launch:phase>

  <launch:notice&= gt;

  …=

  </launch:notice= >

</launch:create>

 <= /p>

COMMENT: This means that we can’t judge the phase bas= ed only the value of the phase element, but we also have to base it off the name which= seems a bit awkward.

 <= /p>

2 – In the case whe= re we are running a special custom “sunrise 2” to restrict regi= stration to a specific group, it’s not clear to me whether we should = follow the proposed landrush from 2.2:

 <= /p>

Without claim:

 <= /p>

<launch:create xmlns:l= aunch=3D"urn:ietf:params:xml:ns:launch-1.0" type=3D"applicat= ion">

    &= nbsp;           <launc= h:phase name=3D”sunrise 2”>custom</launch:phase><= /o:p>

</launch:create>

 <= /p>

With claim:=

 <= /p>

<launch:create xmlns:l= aunch=3D"urn:ietf:params:xml:ns:launch-1.0">=

  <launch:phase n= ame=3D”sunrise 2”>claims</launch:phase>

  <launch:notice&= gt;

  …=

  </launch:notice= >

</launch:create>

 <= /p>

Or whether we should use a custom phase sort of as is propo= sed in section 3.3.4:

 <= /p>

Without claim:

 <= /p>

<launch:create xmlns:l= aunch=3D"urn:ietf:params:xml:ns:launch-1.0" type=3D"applicat= ion">

    &= nbsp;           <launc= h:phase name=3D”sunrise 2”>custom</launch:phase><= /o:p>

</launch:create>

 <= /p>

With claim:=

 <= /p>

<launch:create xmlns:l= aunch=3D"urn:ietf:params:xml:ns:launch-1.0">=

  <launch:phase n= ame=3D”sunrise 2 - claims”>custom</launch:phase><= /o:p>

  <launch:notice&= gt;

  …=

  </launch:notice= >

</launch:create>

 <= /p>

3 – Finally there m= ight be a scenario where we might want to run 2 concurrent custom phases.&n= bsp; Say that there are some domains which will require mark data to be registered, even in a custom sunrise or landrush.  We would expect= a “custom” phase with mark information to be passed.  But= if this happens during a custom sunrise,  then I can’t think of= a good way to handle this, other than creating a hybrid custom phase, so you would use either:

 <= /p>

<launch:phase name=3D&= #8221;special”>custom</launch:phase>

<launch:phase name=3D&= #8221;sunrise2 - special”>custom</launch:phase>

 <= /p>

4 – COMMENT: Given 1, 2 and 3, wouldn’t it be better if we allowed= someone to send multiple independent phases?  Different scenarios inc= lude completely different launch:create extensions, one for each phase with= the data required for that phase.   Or just allowing multiple phase elements inside the single extension?  There = are other options that could be cleaner such as turning the launch:create i= nto a collection, but that would be a big schema change at this point in th= e game…

 <= /p>

5 – My next questio= n is regarding the INFO command specified in 3.2:

 <= /p>

If the application/regist= ration was created as part of a claim request, would the info response ever= show the claims information?  So for example, if I created a landrush domain that had a claim against it with what I assume is the pr= oposed method:

 <= /p>

<launch:create xmlns:l= aunch=3D"urn:ietf:params:xml:ns:launch-1.0">=

  <launch:phase n= ame=3D”landrush”>claims</launch:phase>

  <launch:notice&= gt;

  …=

  </launch:notice= >

</launch:create>

 <= /p>

Then what INFO command ex= tension phase information would the registrar have to send to get informati= on back on this domain?  And what phase information would the server return to him in the response?

 <= /p>

6 – Is phase inform= ation really required for INFO requests?  I assume that application ID= s are unique to the registry?  So if you pass it in, then we would return information regarding the application including the phase.  Ot= herwise, we are infoing a registration.  In this case, I’m not s= ure why we would want to send in the extension?

 <= /p>

Sorry for the long list o= f questions this late in the process, but I just want to make sure that we = (and everyone on the list) have a clear understanding of the mechanisms, especially around concurrent phases which does tend to get= a bit more complicated.

 <= /p>

Cheers,=

 <= /p>

Ben

 <= /p>

From: provreg-= bounces@ietf.org [mailto:provreg-bounces@ietf.org] On Behalf Of Gould, James
Sent: Wednesday, May 01, 2013 5:33 AM
To: EPP Provreg (provreg@ietf.org)
Subject: [provreg] Launch Phase EPP Extension Version 10<= /span>

 

Wil Tan= , Gavin Brown and I have updated the Launch Phase EPP Extension<= /span>

Mapping= to Version 10.  You can find the draft at the URL http://tools.i= etf.org/html/draft-tan-epp-launchphase-10.  This version=

include= s the following changes:

&n= bsp;

 &nbs=
p; 1.  Changed noticeIDType from base64Binary to token to be compatibl=
e with
 &nbs=
p;     draft-lozano-tmch-func-spec-05.=

 &nbs=
p; 2.  Changed codeType from base64Binary to token to be more generic.=

  &nb=
sp;3.  Updated based on feedback from Alexander Mayrhofer, which<=
/o:p>
 &nbs=
p;     include:
 &nbs=
p;     1.   Changed "extension to the do=
main name extension" to
 &nbs=
p;          "extension to=
 the domain name mapping".
 &nbs=
p;     2.   Changed use of 2004 return code t=
o 2306 return code when
 &nbs=
p;          phase passed misma=
tches active phase and sub-phase.
 &nbs=
p;     3.   Changed description of "allo=
cated" and "rejected" statuses.
 &nbs=
p;     4.   Moved sentence on a synchronous &=
lt;domain:create> command
 &nbs=
p;          without the use of=
 an intermediate application, then an
 &nbs=
p;          Application Identi=
fier MAY not be needed to the Application
 &nbs=
p;          Identifier section=
.
 &nbs=
p;     5.   Restructured the Mark Validation =
Models section to include
 &nbs=
p;          the "<laun=
ch:codeMark> element" sub-section, the "<mark:
 &nbs=
p;          mark> element&q=
uot; sub-section, and the Digital Signature sub-
 &nbs=
p;          section.
 &nbs=
p;     6.   Changed "Registries may"=
; to "Registries MAY".
 &nbs=
p;     7.   Changed "extensed" to &=
quot;extended" in "Availability Check
 &nbs=
p;          Form" section=
.
 &nbs=
p;     8.   Broke the mix of create forms in =
the "EPP <create> Command"
 &nbs=
p;          section to a fourt=
h "Mixed Create Form" with its own sub-
 &nbs=
p;          section.
 &nbs=
p;     9.   Removed "displayed or" =
from "displayed or accepted" in the
 &nbs=
p;          <launch:accepte=
dDate> description.
 &nbs=
p;     10.  Replaced "given domain name is su=
pported" with "given domain
 &nbs=
p;          name are supported=
" in the "Create Response" section.
 &nbs=
p;     11.  Changed the reference of 2303 (object =
does not exist) in the
 &nbs=
p;          "Security Con=
siderations" section to 2201 (authorization
 &nbs=
p;          error).=

 &nbs=
p;     12.  Added arrow from "invalid" s=
tatus to "pendingValidation"
 &nbs=
p;          status and "p=
endingAllocation" status to "rejected" status
 &nbs=
p;          in the State Trans=
ition Diagram.
 &nbs=
p; 4.  Added the "C:" and "S:" example prefixes an=
d related text in the
 &nbs=
p;     "Conventions Used in This Document" se=
ction.

&n= bsp;

 

We are hoping that the draf= t stabilizes with this version.  Please reply

with any feedback.

 

Thanks,

 

JG

 

James F. Gould

Verisign<= /p>

 

 

 

 

“This message (including any attachmen= ts) is intended only for the use of the individual or entity to which it is= addressed, and may contain information that is non-public, proprietary, pr= ivileged, confidential and exempt from disclosure under applicable law or may be constituted as attorney work product. If yo= u are not the intended recipient, you are hereby notified that any use, dis= semination, distribution, or copying of this communication is strictly proh= ibited. If you have received this message in error, notify sender immediately and delete this message immedi= ately.”

Please NOTE: This electronic= message, including any attachments, may include privileged, confidential a= nd/or inside information owned by Demand Media, Inc. Any distribution or us= e of this communication by anyone other than the intended recipient(s) is strictly prohibited and may be unlawful.= If you are not the intended recipient, please notify the sender by replyin= g to this message and then delete it from your system. Thank you.
 --_000_1DC00B9E9F0BAB44A146755EE8B1642D62E2F4BA87SMO92WEXVS01c_-- From JGould@verisign.com Fri May 3 11:39:55 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3403121F9657 for ; Fri, 3 May 2013 11:39:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_50=0.001, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mrKosdtgHRjS for ; Fri, 3 May 2013 11:39:46 -0700 (PDT) Received: from exprod6og127.obsmtp.com (exprod6og127.obsmtp.com [64.18.1.78]) by ietfa.amsl.com (Postfix) with ESMTP id E797021F90AC for ; Fri, 3 May 2013 11:39:41 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob127.postini.com ([64.18.5.12]) with SMTP ID DSNKUYQEZb9OgPmmLlldu0gYFlI+zTBGSqDo@postini.com; Fri, 03 May 2013 11:39:46 PDT Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02.vcorp.ad.vrsn.com [10.173.152.206]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id r43IdUsG024196 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 3 May 2013 14:39:30 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Fri, 3 May 2013 14:39:29 -0400 From: "Gould, James" To: Ben Levac , "EPP Provreg (provreg@ietf.org)" Thread-Topic: Launch Phase EPP Extension Version 10 Thread-Index: AQHORmgC76piG2RBeE2BJXZKE2THBpjzkspAgAA7bwA= Date: Fri, 3 May 2013 18:39:29 +0000 Message-ID: In-Reply-To: <1DC00B9E9F0BAB44A146755EE8B1642D62E2F4BA87@SMO92WEXVS01.corp.dm.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.173.152.4] Content-Type: multipart/related; boundary="_004_CDA955EA4ED83jgouldverisigncom_"; type="multipart/alternative" MIME-Version: 1.0 Subject: Re: [provreg] Launch Phase EPP Extension Version 10 X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 18:39:57 -0000 --_004_CDA955EA4ED83jgouldverisigncom_ Content-Type: multipart/alternative; boundary="_000_CDA955EA4ED83jgouldverisigncom_" --_000_CDA955EA4ED83jgouldverisigncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Ben, My feedback is below. To note, these are suggestions on how I might go abo= ut it, but I'm sure there are other ways to skin the cat. -- JG [cid:E227949C-4E01-4691-A42F-9B9073413501] James Gould Principal Software Engineer jgould@verisign.com 703-948-3271 (Office) 12061 Bluemont Way Reston, VA 20190 VerisignInc.com From: Ben Levac > Date: Friday, May 3, 2013 11:46 AM To: James Gould >, EPP Prov= reg > Subject: RE: Launch Phase EPP Extension Version 10 James, I do have some questions, specifically around how the proposed model handle= s simultaneous phases. 1 =96 The first question is around the handling of overlapping claims and l= andrush (which will most likely be the case for us). If I understood secti= on 2.2 of the requirement, a landrush application that was NOT subject to a= claim would pass the launch:create extension with just the phase like this= : landrush The phase that is being passed should match the phase that the server is ac= tivitly running, which is "claims" with the sub-phase "landrush". It would= look like the following in General Create Form according to the overlap ha= ndling defined in section 2.2 "Launch Phase": claims While a landrush application that WAS subject to a claims would pass the fo= llowing extension: claims =85 COMMENT: This means that we can=92t judge the phase based only the value of= the phase element, but we also have to base it off the name which seems a = bit awkward. The phases would be exactly the same for this use case, except the notice w= ould be included: claims =85 2 =96 In the case where we are running a special custom =93sunrise 2=94 to = restrict registration to a specific group, it=92s not clear to me whether w= e should follow the proposed landrush from 2.2: Without claim: custom With claim: claims =85 Does the "sunrise 2" overlap with the "claims" phase and does it proceed th= e "landrush" phase? If so, I would recommend always specifying "claims" as= the phase and "sunrise 2" or "landrush" as a sub-phase for both the Genera= l Create Form and the Claims Create Form as in: claims claims =85 Or whether we should use a custom phase sort of as is proposed in section 3= .3.4: Without claim: custom With claim: custom =85 I do not believe there is the need for a custom phase. 3 =96 Finally there might be a scenario where we might want to run 2 concur= rent custom phases. Say that there are some domains which will require mar= k data to be registered, even in a custom sunrise or landrush. We would ex= pect a =93custom=94 phase with mark information to be passed. But if this = happens during a custom sunrise, then I can=92t think of a good way to han= dle this, other than creating a hybrid custom phase, so you would use eithe= r: custom custom I always view the server being in a single active phase, where in this use = case the active phase will require mark data for a subset of the domains. = The phase value passed can be identical, where it could be a single custom = phase (e.g. custom), and the = passing of the required mark data would be up to the client to pass based o= n I'm guessing a known set of domains that would require it. The server wo= uld match the custom phase and would apply the server logic for the differe= nt groups of domains (requiring the mark data or not). If this phase overl= aps with the "claims" phase, then the same use of a sub-phase would apply t= hat was discussed in the prior use cases. 4 =96 COMMENT: Given 1, 2 and 3, wouldn=92t it be better if we allowed some= one to send multiple independent phases? Different scenarios include compl= etely different launch:create extensions, one for each phase with the data = required for that phase. Or just allowing multiple phase elements inside = the single extension? There are other options that could be cleaner such a= s turning the launch:create into a collection, but that would be a big sche= ma change at this point in the game=85 I believe that you can accomplish this using a combination of the phase and= sub-phases with the option of passing the notice and the mark information.= The key is not to make it so custom that it will make it too challenging = for the client to now what to do. 5 =96 My next question is regarding the INFO command specified in 3.2: If the application/registration was created as part of a claim request, wou= ld the info response ever show the claims information? So for example, if = I created a landrush domain that had a claim against it with what I assume = is the proposed method: claims =85 Then what INFO command extension phase information would the registrar have= to send to get information back on this domain? And what phase informatio= n would the server return to him in the response? The phase of the info is based on the context of when the application or re= gistration was created. The only applicable information returned in the ex= tension to the info response during the claims phase is the application inf= ormation (e.g. status). The info response does not support the returning o= f the claims information. 6 =96 Is phase information really required for INFO requests? I assume tha= t application IDs are unique to the registry? So if you pass it in, then w= e would return information regarding the application including the phase. = Otherwise, we are infoing a registration. In this case, I=92m not sure why= we would want to send in the extension? The draft does not specify that the application ID's are unique, but I beli= eve they should be. The phase defines the context of the query and the app= lication ID defines the specific application without the phase; although I = don't see why an application ID can not be unique across phases. Outside su= nrise, the extension to the info command / response is focused on the appli= cation status. Sorry for the long list of questions this late in the process, but I just w= ant to make sure that we (and everyone on the list) have a clear understand= ing of the mechanisms, especially around concurrent phases which does tend = to get a bit more complicated. Hopefully my suggestions help. Cheers, Ben From: provreg-bounces@ietf.org [mailto:pro= vreg-bounces@ietf.org] On Behalf Of Gould, James Sent: Wednesday, May 01, 2013 5:33 AM To: EPP Provreg (provreg@ietf.org) Subject: [provreg] Launch Phase EPP Extension Version 10 Wil Tan, Gavin Brown and I have updated the Launch Phase EPP Extension Mapping to Version 10. You can find the draft at the URL http://tools.ietf= .org/html/draft-tan-epp-launchphase-10. This version includes the following changes: 1. Changed noticeIDType from base64Binary to token to be compatible wit= h draft-lozano-tmch-func-spec-05. 2. Changed codeType from base64Binary to token to be more generic. 3. Updated based on feedback from Alexander Mayrhofer, which include: 1. Changed "extension to the domain name extension" to "extension to the domain name mapping". 2. Changed use of 2004 return code to 2306 return code when phase passed mismatches active phase and sub-phase. 3. Changed description of "allocated" and "rejected" statuses. 4. Moved sentence on a synchronous command without the use of an intermediate application, then an Application Identifier MAY not be needed to the Application Identifier section. 5. Restructured the Mark Validation Models section to include the " element" sub-section, the " element" sub-section, and the Digital Signature sub- section. 6. Changed "Registries may" to "Registries MAY". 7. Changed "extensed" to "extended" in "Availability Check Form" section. 8. Broke the mix of create forms in the "EPP Command" section to a fourth "Mixed Create Form" with its own sub- section. 9. Removed "displayed or" from "displayed or accepted" in the description. 10. Replaced "given domain name is supported" with "given domain name are supported" in the "Create Response" section. 11. Changed the reference of 2303 (object does not exist) in the "Security Considerations" section to 2201 (authorization error). 12. Added arrow from "invalid" status to "pendingValidation" status and "pendingAllocation" status to "rejected" status in the State Transition Diagram. 4. Added the "C:" and "S:" example prefixes and related text in the "Conventions Used in This Document" section. We are hoping that the draft stabilizes with this version. Please reply with any feedback. Thanks, JG James F. Gould Verisign =93This message (including any attachments) is intended only for the use of= the individual or entity to which it is addressed, and may contain informa= tion that is non-public, proprietary, privileged, confidential and exempt f= rom disclosure under applicable law or may be constituted as attorney work = product. If you are not the intended recipient, you are hereby notified tha= t any use, dissemination, distribution, or copying of this communication is= strictly prohibited. If you have received this message in error, notify se= nder immediately and delete this message immediately.=94 ________________________________ Please NOTE: This electronic message, including any attachments, may includ= e privileged, confidential and/or inside information owned by Demand Media,= Inc. Any distribution or use of this communication by anyone other than th= e intended recipient(s) is strictly prohibited and may be unlawful. If you = are not the intended recipient, please notify the sender by replying to thi= s message and then delete it from your system. Thank you. --_000_CDA955EA4ED83jgouldverisigncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Ben,

My feedback is below.  To note, these are suggestions on how I mi= ght go about it, but I'm sure there are other ways to skin the cat.  <= /div>

<= font face=3D"Calibri" size=3D"3">-- 

<= font face=3D"Calibri" size=3D"3"> 

<= font face=3D"Calibri" size=3D"3">JG

<= font face=3D"Calibri" size=3D"3"> 

<= font face=3D"Calibri" size=3D"3">

<= font face=3D"Calibri" size=3D"3"> 

<= font face=3D"Calibri" size=3D"3">= James Gould

<= font face=3D"Calibri" size=3D"3">P= rincipal Software Engineer

<= font face=3D"Calibri" size=3D"3">jg= ould@verisign.com

<= font face=3D"Calibri" size=3D"3">&= nbsp;

<= font face=3D"Calibri" size=3D"3">7= 03-948-3271 (Office)

<= font face=3D"Calibri" size=3D"3">1= 2061 Bluemont Way

<= font face=3D"Calibri" size=3D"3">R= eston, VA 20190

<= span style=3D"color: rgb(13, 44, 118); ">= VerisignInc.com


From: Ben Levac <Benoit.Levac@demandmedia.com>
Date: Friday, May 3, 2013 11:46 AM<= br> To: James Gould <jgould@verisign.com>, EPP Provreg <provreg@ietf.org>
Subject: RE: Launch Phase EPP Exten= sion Version 10

James,

 

I do have some questions, specific= ally around how the proposed model handles simultaneous phases.<= /span>

 

1 =96 The first question is around= the handling of overlapping claims and landrush (which will most likely be= the case for us).  If I understood section 2.2 of the requirement, a landrush application that was NOT subject to a c= laim would pass the launch:create extension with just the phase like this:<= o:p>

 

<launch:create xmlns:launch=3D&= quot;urn:ietf:params:xml:ns:launch-1.0" type=3D"application"= >

     &nbs= p;          <launch:phase&g= t;landrush</launch:phase>

</launch:create><= /span>

 

The phase that is being passed should match the phase that the server is ac= tivitly running, which is "claims" with the sub-phase "landr= ush".  It would look like the following in General Create Form ac= cording to the overlap handling defined in section 2.2 "Launch Phase":

<launch:create xmlns:launch=3D"urn:ietf:params:xml:= ns:launch-1.0" type=3D"application">

          = ;      <launch:phase name=3D"landrush"= ;>claims</launch:phase>

</launch:create>



While a landrush application that = WAS subject to a claims would pass the following extension:

 

<launch:create xmlns:launch=3D&= quot;urn:ietf:params:xml:ns:launch-1.0">

  <launch:phase name=3D=94= landrush=94>claims</launch:phase>

  <launch:notice><= /o:p>

  =85

  </launch:notice>=

</launch:create><= /span>

 

COMMENT: This means that we can=92t judge the phase based only the value of the phase element, but we also have to b= ase it off the name which seems a bit awkward.

 

The phases would be exactly the same for this use case, except the notice w= ould be included:

<lau= nch:create xmlns:launch=3D"urn:ietf:params:xml:ns:launch-1.0" typ= e=3D"application">

 &= nbsp;           &nbs= p;  <launch:phase name=3D"landrush">claims</launch:= phase>

 &= nbsp; <launch:notice>

=85

</launch:notice>

</la= unch:create>



2 =96 In the case where we are run= ning a special custom =93sunrise 2=94 to restrict registration to a specifi= c group, it=92s not clear to me whether we should follow the proposed landrush from 2.2:

 

Without claim:

 

<launch:create xmlns:launch=3D&= quot;urn:ietf:params:xml:ns:launch-1.0" type=3D"application"= >

     &nbs= p;          <launch:phase n= ame=3D=94sunrise 2=94>custom</launch:phase>

</launch:create><= /span>

 

With claim:

 

<launch:create xmlns:launch=3D&= quot;urn:ietf:params:xml:ns:launch-1.0">

  <launch:phase name=3D=94= sunrise 2=94>claims</launch:phase>

  <launch:notice><= /o:p>

  =85

  </launch:notice>=

</launch:create><= /span>

 

Does the "sunrise 2" overlap with the "claims" pha= se and does it proceed the "landrush" phase?  If so, I would= recommend always specifying "claims" as the phase and "sunr= ise 2" or "landrush" as a sub-phase for both the General Cre= ate Form and the Claims Create Form as in:

<launch:create xmlns:launch=3D"urn:ietf:params:xml:= ns:launch-1.0" type=3D"application">

          = ;      <launch:phase name=3D"sunrise 2&quo= t;>claims</launch:phase>

</launch:create>

<launch:create xmlns:launch=3D"ur= n:ietf:params:xml:ns:launch-1.0" type=3D"application">

       = ;         <launch:phase name=3D&= quot;landrush">claims</launch:phase>

   <launch:notice>

=85

</launch:notice>

</launch:create><= /p>



Or= whether we should use a custom phase sort of as is proposed in section 3.3.4:

 

Without claim:

 

<launch:create xmlns:launch=3D&= quot;urn:ietf:params:xml:ns:launch-1.0" type=3D"application"= >

     &nbs= p;          <launch:phase n= ame=3D=94sunrise 2=94>custom</launch:phase>

</launch:create><= /span>

 

With claim:

 

<launch:create xmlns:launch=3D&= quot;urn:ietf:params:xml:ns:launch-1.0">

  <launch:phase name=3D=94= sunrise 2 - claims=94>custom</launch:phase>

  <launch:notice><= /o:p>

  =85

  </launch:notice>=

</launch:create><= /span>

 

I do not believe there is the need for a custom phase.

3 =96 Finally there might be a sce= nario where we might want to run 2 concurrent custom phases.  Say that= there are some domains which will require mark data to be registered, even in a custom sunrise or landrush.  We= would expect a =93custom=94 phase with mark information to be passed. = ; But if this happens during a custom sunrise,  then I can=92t think o= f a good way to handle this, other than creating a hybrid custom phase, so you would use either:

 

<launch:phase name=3D=94special= =94>custom</launch:phase>

<launch:phase name=3D=94sunrise= 2 - special=94>custom</launch:phase>

I always view the server being in a single active phase, where in this= use case the active phase will require mark data for a subset of the domai= ns.  The phase value passed can be identical, where it could be a sing= le custom phase (e.g. <launch:phase name=3D"special">custom= </launch:phase>), and the passing of the required mark data would be up to the client to pas= s based on I'm guessing a known set of domains that would require it.  = ;The server would match the custom phase and would apply the server logic f= or the different groups of domains (requiring the mark data or not).  If this phase overlaps with the "claims&= quot; phase, then the same use of a sub-phase would apply that was discusse= d in the prior use cases.

 

4 =96 COMMENT: Given 1, 2 and 3, wouldn=92t it be better if we allowed som= eone to send multiple independent phases?  Different scenarios include= completely different launch:create extensions, one for each phase with the= data required for that phase.   Or just allowing multiple phase elements inside the single extension?  There = are other options that could be cleaner such as turning the launch:create i= nto a collection, but that would be a big schema change at this point in th= e game=85

 

I believe that you can accomplish this using a combination of the phas= e and sub-phases with the option of passing the notice and the mark informa= tion.  The key is not to make it so custom that it will make it too ch= allenging for the client to now what to do.

5 =96 My next question is regardin= g the INFO command specified in 3.2:

 

If the application/registration wa= s created as part of a claim request, would the info response ever show the= claims information?  So for example, if I created a landrush domain that had a claim against it with what I ass= ume is the proposed method:

 

<launch:create xmlns:launch=3D&= quot;urn:ietf:params:xml:ns:launch-1.0">

  <launch:phase name=3D=94= landrush=94>claims</launch:phase>

  <launch:notice><= /o:p>

  =85

  </launch:notice>=

</launch:create><= /span>

 

Then what INFO command extension p= hase information would the registrar have to send to get information back o= n this domain?  And what phase information would the server return to him in the response?

 

The phase of the info is based on the context of when the application = or registration was created.  The only applicable information returned= in the extension to the info response during the claims phase is the appli= cation information (e.g. status).  The info response does not support the returning of the claims information. &n= bsp; 

6 =96 Is phase information really = required for INFO requests?  I assume that application IDs are unique = to the registry?  So if you pass it in, then we would return information regarding the application including the phase.=   Otherwise, we are infoing a registration.  In this case, I=92m = not sure why we would want to send in the extension?

 

The draft does not specify that the application ID's are unique, but I= believe they should be.  The phase defines the context of the query a= nd the application ID defines the specific application without the phase; a= lthough I don't see why an application ID can not be unique across phases. Outside sunrise, the extension to the = info command / response is focused on the application status.  

Sorry for the long list of questio= ns this late in the process, but I just want to make sure that we (and ever= yone on the list) have a clear understanding of the mechanisms, especially around concurrent phases which does tend to = get a bit more complicated.

Hopefully my suggestions help.  

 

Cheers,

 

Ben

 

From: provreg-bounces@ietf.org [<= a href=3D"mailto:provreg-bounces@ietf.org">mailto:provreg-bounces@ietf.org<= /a>] On Behalf Of Gould, James
Sent: Wednesday, May 01, 2013 5:33 AM
To: EPP Provreg (provreg@ietf.or= g)
Subject: [provreg] Launch Phase EPP Extension Version 10<= /span>

 

Wil Tan= , Gavin Brown and I have updated the Launch Phase EPP Extension<= /span>

Mapping= to Version 10.  You can find the draft at the URL http://tools.i= etf.org/html/draft-tan-epp-launchphase-10.  This version=

include= s the following changes:

&n= bsp;

   1.  Chan=
ged noticeIDType from base64Binary to token to be compatible with
    &n=
bsp;  draft-lozano-tmch-func-spec-05.
   2.  Chan=
ged codeType from base64Binary to token to be more generic.
   3.  Upda=
ted based on feedback from Alexander Mayrhofer, which

    &n=
bsp;  include:


    &n=
bsp;  1.   Changed "extension to the domain name extens=
ion" to


    &n=
bsp;       "extension to the domain name=
 mapping".


    &n=
bsp;  2.   Changed use of 2004 return code to 2306 return co=
de when


    &n=
bsp;       phase passed mismatches active pha=
se and sub-phase.


    &n=
bsp;  3.   Changed description of "allocated" and =
"rejected" statuses.


    &n=
bsp;  4.   Moved sentence on a synchronous <domain:create=
> command


    &n=
bsp;       without the use of an intermediate=
 application, then an


    &n=
bsp;       Application Identifier MAY not be =
needed to the Application


    &n=
bsp;       Identifier section.


    &n=
bsp;  5.   Restructured the Mark Validation Models section t=
o include


    &n=
bsp;       the "<launch:codeMark> =
element" sub-section, the "<mark:


    &n=
bsp;       mark> element" sub-section=
, and the Digital Signature sub-


    &n=
bsp;       section.


    &n=
bsp;  6.   Changed "Registries may" to "Regis=
tries MAY".


    &n=
bsp;  7.   Changed "extensed" to "extended&qu=
ot; in "Availability Check


    &n=
bsp;       Form" section.


    &n=
bsp;  8.   Broke the mix of create forms in the "EPP &l=
t;create> Command"


    &n=
bsp;       section to a fourth "Mixed Cr=
eate Form" with its own sub-


    &n=
bsp;       section.


    &n=
bsp;  9.   Removed "displayed or" from "displ=
ayed or accepted" in the


    &n=
bsp;       <launch:acceptedDate> descri=
ption.


    &n=
bsp;  10.  Replaced "given domain name is supported" wi=
th "given domain


    &n=
bsp;       name are supported" in the &q=
uot;Create Response" section.


    &n=
bsp;  11.  Changed the reference of 2303 (object does not exist) =
in the


    &n=
bsp;       "Security Considerations"=
; section to 2201 (authorization


    &n=
bsp;       error).


    &n=
bsp;  12.  Added arrow from "invalid" status to "p=
endingValidation"


    &n=
bsp;       status and "pendingAllocation=
" status to "rejected" status


    &n=
bsp;       in the State Transition Diagram.


   4.  Adde=
d the "C:" and "S:" example prefixes and related text i=
n the


    &n=
bsp;  "Conventions Used in This Document" section.

&n= bsp;

 

We are hoping that the draft stabilizes wit= h this version.  Please reply

with any feedback.

 

Thanks,

 

JG

 

James F. Gould

Verisign

 

 

 

 

=93This message (including any attachments) = is intended only for the use of the individual or entity to which it is add= ressed, and may contain information that is non-public, proprietary, privil= eged, confidential and exempt from disclosure under applicable law or may be constituted as attorney work product. If yo= u are not the intended recipient, you are hereby notified that any use, dis= semination, distribution, or copying of this communication is strictly proh= ibited. If you have received this message in error, notify sender immediately and delete this message immedi= ately.=94

Please NOTE: This electronic= message, including any attachments, may include privileged, confidential a= nd/or inside information owned by Demand Media, Inc. Any distribution or us= e of this communication by anyone other than the intended recipient(s) is strictly prohibited and may be unlawful.= If you are not the intended recipient, please notify the sender by replyin= g to this message and then delete it from your system. Thank you.
 --_000_CDA955EA4ED83jgouldverisigncom_-- --_004_CDA955EA4ED83jgouldverisigncom_ Content-Type: image/png; name="8A7A655D-9ED0-4D38-898D-E9E8B754666E[123].png" Content-Description: 8A7A655D-9ED0-4D38-898D-E9E8B754666E[123].png Content-Disposition: inline; filename="8A7A655D-9ED0-4D38-898D-E9E8B754666E[123].png"; size=4109; creation-date="Fri, 03 May 2013 18:39:28 GMT"; modification-date="Fri, 03 May 2013 18:39:28 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAEkAAABACAIAAADZHs1DAAAP1ElEQVRoBe2aa3CU1RnHN3vLJtmQ hEtiwlUBtZUUCiU6tU7wVhinjOB0xmJnFIdpO1Y6DY586Iwdo36gLc4Iip3pVAL9IKjTDnhDEEWC 1GoICHLRctEkXHIPuZHr7qa/c553T152N9lsNvnWM5nDec97Ls//+T+X854lZWBgwDFuRRaXOiUl hX2kHrcNr1vYfd1T0g/ACIVCQV0CgQD/8miwOZ1Ol8vldrupKTyOK9QU2ThpUA4w9Pf39/X19fT0 UCsYYHA6QcLiYKCwF2MEMNh8Pp/X6/V4PAxOXoDoFcYAG7ICplsXNvClpSFvipAimGy1wQmrMgV4 aUzxekEbLV8yPUlhE66u6YJkqT6fMjKDyjRs2GgaeNKA587OTqZnZGSMLYejx4biEautrQ3eUlNT LUiCx6AyjWHhAbKrqwuEwMNQxYyTYUzmjhIbboMo7e3tyIwoMYA5nZ+duXiyur6ju88u5ZL5s+ff mJ+TmUan4JUGNVbQ2tqKNvx+PwTaZ42uPRpseBeoYMygUvRoijp7AnuPXdhz9PyeyvPI7khxqtoU yTcDofk35j1674LH7luY7U8zVsoo2qgMc5gwYQIeaOaNrpEwNoCBqraujgBALDeoOnr6X9t/4rX9 x9t7gg6Xx+F0K1QEQOBRFKoBVYdCjoGgI6T+MtO9j9+74Nlf3gNChhiQHR0dwMvKykoSXmLYMEUY u3T5MoyxMZEDbJTK81fWlR242NrrcHsdToBpSBZpsKeps0gDocYWDDhC6i8zzbO9ZOWKH38/Ah5K hL1kjDMBbMQMDKa6pgaE6enpggp4r+z5cvOeLx0en6bLpRkTbIKKWjGnijoCgQ3qdB3sdwR6FcJg 8NF7Crc99XNeG/ZQIvkQ3xt1bhgpNrYhlMFYY0NDVna2Bczp/MPrh3dVVjncAHOrvxSwuSw3U3SF SVPIxDKpBVuYQOABMtg3f+aUA39aY/fApqYmLB89CmBZY+T1SA8EcIWb1dfXk8QIaFIUsKM1Dk+a w+1xuLQ1Ag9s1p9uC9rBTk2sUoRLq8Ojp6cy/UR100MvvK41oPkdGMjJySF3svXI8dhHjggbSDhD ED8wSxgTYLsqLihgbsRCULBp3gghBobyN5AY33NalKoeuA2rgInYs1rHU37m4rq/vW/gsReZk63Z 0S70CNsjwiakNTU2etxuAXax5dpf3juuuBJgFiQtPdgUKv3n1DZpPdrawFPDwvBoW/C8L79bceD4 eQOPcELMHB118bHhab29vYq0UIhjvGB77p+VHeRk7MpCIn5lgobRrHY5noCnQgrD5JX5sJJOPZ0Y q/h3rdn0NpsaePgbAkiPWXckjfjfOJytMHrcmngltnGsqqmyqllZUYozK82z4MY8tZNYmtnT6T5+ saWtV1DpXuARRYLB4ltyVWw0hZRA4VDS1Xfiu3pe1TR3vLDz4B9XLSGEAIlw0tzcTJ1oPoiPDXto uXoVzfkzM/kyQ4y/f3JW0QVpig3H7vXLJfkqEW3l4OlLd/95n7JbU0KB4rkTDz6z3HTYGyVlH5+o alTjQ6FtHx575hfFvAUeXodaESNRbHFsErWRQxsaGpRBpqRQX2ru/LKmRScxZZBtnd0lr31oF9G0 l9w2rfjmXJWppdDo79n+xL1mgL1RVd+6+f1jWmUq9dc0tb/z+TfsTmEYB2jEkLZ91vDtONgwQhgj ZavPaf1N/enZegUM3uTP7f3Hga8OnqyKuc323xQ7OH9ICQaefWjRrCkTYo5c/fK7yshlTXVkc739 +RlGanQDREvEEI+IOT1mZxxsBH0WlfO+uioIhQ6dbdSuhffrUI5Aqf7SNz6NuTpInl2xQHlXKJDl CZU8sCDmsN1fnC0/16wCiVqTU6jS3cGvqoUoakk87B9z+lCdcbChKoAJY7SBV9PUobMTE3VwQ9Me X/nXtds/Ph5zj5JlhVk+J2erTY/+JDvDF3tM2ceaNI41kjzw5BTMsrWzx8DD8caBt76+YEDZlaYt 1N4bUqo1fyBE39700rf+09rZHS16dkbqplWL5xf4Vy9Rp+HoUvrG4eo2/emgzmgUWVzBO/Fdrdgk vZjlGPPG0nClCVP1uXpIE6qtPKVBOtF6dUv3pt2faeEiK1Bt/+39kb36ufVaz6YPz6jEDf+WvvQL Mor+WhVsSozwfVnMdWJ2DpcDZF0MElj9+kKuvZuERdEJ16p1B/nAk/bcv46svn/RrLxs3XVdBaUp KzYoR7UX1IS7qg+I62+BLALVUGSQGQbkyM/N129m31jnFukQ3kBoey9bWhuTudWXmze9ZOsQ+aBw 1oN3znOkZTsyJg3+pecQh3QCDFvB4AaqR1NlgZI3IwfG+OGwqdda0xg6qRPjnJGdqveIAKb7OBx6 fG8frR4qH2xaXZzl12diuDJ/KjbiYNevqriytGboMsLooSOq4mBDT1wbWLwFgz5sx3xZyh1B2GaU fDqolJR9FHNn8kHJT2+77rRlH6ew8EUnqHRjYGD65Ex1Ka0Lyk2INJaLg43DzqRJk8BG4WQAgd/L y9ASKFfQsoWl4UH7z4lL7cPkg5k5sdKAAFPLWahYnNuU6ZMnWDFkYEBpOcIt9fbDVHGwyRcUVyNg 6+ntxeVmT0pVx6jBb2cjjd6FtOtJKyk7MFQ+KF35Qz6xBwViHWV++m9wzRD03nXrVIs09tZxUhxk cG68VhxsqIrEkpOdDWPwxi43TUzVt1TcC+g/uyHRxnncqW39rtK3hsgHxbfOn04g1WFJARNcRkE0 9LKh4AOL5hjSerq7EWOMecMSIC0/Px9UwOMzceE0/+QMtyUBcqg7Of5EOK1Jwo/Ht/m9So6/0Zol oVXVNmueBJidNFmKNdVF2LKFsxVvmjTUihhj7G8GG1KyC2dLEN4xw69ub7QEgyAlDIgT6qCijr9R pfTNf7f1Ch4YE1O0kabW5Nqr/+E7b8HfLN50Khh7bMjGVSQ2mX/DDRBHsEKFS+dOSHMNqAO+OgSL 74VVrkxUZUYss/ybuoh8UNXYvnnfaXUNQRkExly9iFpKX10G+p56sMgAQ6EYJGJEKSpORxx/YzZW zlf9DwoL+aUQeHyDp7oGfnW7/nYWNataY6OWBtN0UFm95QP7/qu37FUpnnAKfqWFsEbURI0KfQFs +aJpE/3GIFEoAiTqbEoE+95DtbGHvLy8adOmCTwunublehfc4NWWGWZPtG6FUO1Lbm91c9emdypk WT7DYVJhpoijGkiWjrilDMzLz/j9zxYpLwt7mvwEOZRsw/SPCBs649ejosWLyePA69W/jD6+aNL0 TKe+NhV42j5F/cKeTnelbx6WfKDcT04h8lZpQXOlv+5knUxP8K+/vl9QCTyiCVuPgjQwu0pLS4eB Lq+IKOQWNiDF1dXVYVB89fi8njtmZp6u62rvjfpk5IwiQcXh6O3rr2u6WtXQ/mZFtcKmStjBFHth eMFApjuwY+19N+XlMEIdwrjCCAYzMzPBlmhmU5uwAIqRVtyaKNLS0rJv//5Lly6xGT/iZPj9AYfr xU8bLnaElNzqRkDukuUTUx8TddxT0UUNIHnoqIizKfYEWBBVwdi2J+6bN30SK8tPKMjD3dbEiRPx iLiyxRyQADa0QH6rra19b88efkayw3v3m7aPLnQp0YmB6kssjA1IFKU+/cVptXUUUf7JlZ6y5x/N yN782J1ZGT4FTBcuDjP9fo57OFuiac3gTAAbc/ABAsmV2toP9u418Pgxghh9rrlv29Hmpi5NINjI 4NQUqa0NNWkqPMIbpAVmZPseL5774KJZYVBwlkLQz87Kys3NhTf6ramJ/5MYNtYHHj/ocM1sh+f2 eOTHpM8vdh3+ruPrhm7NXvhT2vqGYbZgA1VozpSMh4tmLl84w6CiweJYfu4UVYj7yQBjs4SxCTzY u3r16ifl5TU1NUigfkB1uVAzJkTIaekOfl3f9d/G3sbOvsZr/U3X1HVLps81c2J6flba3Dz/XTfn FWSnMYW5jBcM5DHaBfn5+FiSjLEdZTTYmCYK5grs9JkzlZWVJAaBh5QKIeda/R9nlNxadgEgtYUG VBqZOqeyXCgEpKkFBfJLt6DVEo6+GiU2NiS04PHYZ0Nj4+lTp85duECXoYIjEgg9/LcfQBqcNpaY TgEXMPhpG1Rgww6ZOOrgEaGG0WOThYRAEDa3tJw/f/7Ct98SCTQfihXT4AGcBApmCXtkTMATCfNy c/kNEVTEesZHyJfMY7LYZG/Uj7eQIQBZ39DAz6tkQvXY3W2HRxuLJeqo+D55MkdwIOGi/IgB4GRg xJw7NthkaTgUkPK5QI3R0kM/AwQkJgcSKKKmCIcxJUu+cyyxGWnEl4BEkTav8CIKCCnSNuPHqTEu 2MZJ1kSXHUvfTXTv8R7/f2zjreHxWT/hS4hkxLhy5QqHNVaYOnUqoX/4pS5wGNCFnE4CHH5wzLfu jS++eOXyZd5t2LBB9tu9e3d5eTk9a9as2bp1a/S0tWvXzp49+9VXXyVZ298iRFFR0dKlS+k0b196 6SUeQcVSJD0znpErV65kRzBs2bKF/mXLlsncYQYzbN26ddQFU6euf/ppGma6SLVz586TJ0/Sj/DO 24uKaFGki8Y5LTFJdt68efrNSCtE37t376lTp6InRABjQEVFxfPPP09+jxgMMKCKFpCBIoNf0fjN YPg4dOiQeTQNVIZRiHW4CwsLd+3axTtIWLx4Mad7oZF+M2HOnDlPPvmkeYxoGGY2btzIK4SOUAqq FVmLi4tXrFgBHlTAMFQbbZm8EskeeeQR5GFBoYKLtoh9GQmSiE4MyojqxpThFzzwtmrVKmNmdmxI tm/fPrOKWI55lAYGKQ2RLOKtPLIFPKBXZALkUGPoRyQBRhupMNdol2MjWImGZ5ZVsQSzZBBDsQex TCSw616MzcyJwIZr8UqYoQHJZqQ00KWoz74OW+BvBkDEFGEJecSm5C3jCwoKpM10BIZ8NBUx1zwq bMYsASa82UljgCjbzIloGKrpR4sYXsQAHn+3di0mhCeLwdODZDt27IjYyEzkrYyxLy6dMoaNkNau LDPXNBQ2Y5Zsb2aaETTQjTFie7+0MZivTp4UoQEW7UIyTJyNNmywkRjIZR2i7WsKIbzFaNmX6McY O3syWGgnRNkB29ehbZ1LltiUjedgRfZxfKoQD0xBOPtbTPShlSulJ1oI+omchEQizZEjR4hV9PCx J+ONl8ojtTAJIWVlZYL8iwrrZtqMkQZeE23/9jGKN4rdNuxteQsnkoLkMTpsogtmiUmDxO6rTEG1 ol2MUFaQGrvCZIyjSidWwDqMp6bYx0e3iaVoLbpfeixsGBI2I3qyR56YihH3jXBiHF0AIBDY7G8J GPDDecDIyiO7SEzCumQX4RC069evh38ZzFsEE6+jjdARg9GF/a0d5/8ActOtScHpPCkAAAAASUVO RK5CYII= --_004_CDA955EA4ED83jgouldverisigncom_-- From Benoit.Levac@demandmedia.com Sun May 5 16:14:04 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CC7C21F919D for ; Sun, 5 May 2013 16:14:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.664 X-Spam-Level: X-Spam-Status: No, score=-0.664 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_66=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W8t6OOfAoqSm for ; Sun, 5 May 2013 16:13:55 -0700 (PDT) Received: from BLVBarracuda01.enom.com (mail.enom.com [69.64.144.70]) by ietfa.amsl.com (Postfix) with ESMTP id 4464621F8FA3 for ; Sun, 5 May 2013 16:13:54 -0700 (PDT) X-ASG-Debug-ID: 1367796656-03ebeb190993d080001-ybujJl Received: from smo92wexca01.corp.dm.local ([10.45.16.66]) by BLVBarracuda01.enom.com with ESMTP id 471xvNYALM8QqptG; Sun, 05 May 2013 16:30:56 -0700 (PDT) X-Barracuda-Envelope-From: Benoit.Levac@demandmedia.com X-ASG-Whitelist: Client Received: from SMO11EXCA02.corp.dm.local (10.45.16.20) by smo92wexca01.corp.dm.local (10.45.16.66) with Microsoft SMTP Server (TLS) id 8.3.213.0; Sun, 5 May 2013 16:13:54 -0700 Received: from SMO92WEXVS01.corp.dm.local ([10.45.16.21]) by SMO11EXCA02.corp.dm.local ([10.45.16.20]) with mapi; Sun, 5 May 2013 16:13:54 -0700 From: Ben Levac To: "Gould, James" , "EPP Provreg (provreg@ietf.org)" Date: Sun, 5 May 2013 16:13:52 -0700 Thread-Topic: Launch Phase EPP Extension Version 10 X-ASG-Orig-Subj: RE: Launch Phase EPP Extension Version 10 Thread-Index: AQHORmgC76piG2RBeE2BJXZKE2THBpjzkspAgAA7bwCAAt7w4A== Message-ID: <1DC00B9E9F0BAB44A146755EE8B1642D62E2F4BAD9@SMO92WEXVS01.corp.dm.local> References: <1DC00B9E9F0BAB44A146755EE8B1642D62E2F4BA87@SMO92WEXVS01.corp.dm.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/related; boundary="_004_1DC00B9E9F0BAB44A146755EE8B1642D62E2F4BAD9SMO92WEXVS01c_"; type="multipart/alternative" MIME-Version: 1.0 X-Barracuda-Connect: UNKNOWN[10.45.16.66] X-Barracuda-Start-Time: 1367796656 X-Barracuda-URL: http://10.11.16.233:8000/cgi-mod/mark.cgi X-Barracuda-BRTS-Status: 1 X-Virus-Scanned: by bsmtpd at enom.com Subject: Re: [provreg] Launch Phase EPP Extension Version 10 X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 May 2013 23:14:04 -0000 --_004_1DC00B9E9F0BAB44A146755EE8B1642D62E2F4BAD9SMO92WEXVS01c_ Content-Type: multipart/alternative; boundary="_000_1DC00B9E9F0BAB44A146755EE8B1642D62E2F4BAD9SMO92WEXVS01c_" --_000_1DC00B9E9F0BAB44A146755EE8B1642D62E2F4BAD9SMO92WEXVS01c_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable James, Thank you for your answers. It certainly does clarifies what the vision be= hind some of the suggestions in the document. It seems that you are suggesting that if the claims and landrush phases ove= rlap, then the claims period is the principal phase? Since ICANN is curren= tly proposing the claims period for 90 days after sunrise, it is likely tha= t landrush and claims will overlap for a lot of registries. And what seems= awkward to me is that we would be asking registrars to send the following = phase information for every single application even though (I assume) few o= f them will ever actually need to pass actual claims notice information... claims Wouldn't it make more sense to ask them to provide the following, because t= o my previous comments on this topic in revision 08, I am most interested i= n validating their actual intention of submitting a landrush application (a= s opposed to a general registration). landrush >From a validation perspective, I'm not sure I care to validate the fact tha= t they passed in "claims" as a phase or sub-phase. I do however, want to v= alidate that they passed in valid claims notice information if the domain i= s part of the DNL list. And we would return an error message if they did n= ot. What I would also want to avoid is that if the landrush period does last lo= nger than the claims period, to have different phase values for landrush ap= plications. For example: 1 - Applications submitted before claim ends would have to return the follo= wing phase in the info response: claims 2 - While applications submitted after the claims period ends would have to= return the following in the response: landrush Because they are all landrush applications, I would only ever want to have = to return landrush in the info response, espec= ially since we never even return the claims information. I have a couple of questions about the following statement: JG>The draft does not specify that the application ID's are unique, but I b= elieve they should be. The phase defines the context of the query and the = application ID defines the specific application without the phase; although= I don't see why an application ID cannot be unique across phases. Outside = sunrise, the extension to the info command / response is focused on the app= lication status. 1 - What would the INFO response return if a registrar passed in a phase an= d no application ID? Would we return a validation error? If the domain wa= s registered in that phase, I would expect the INFO to return a regular INF= O response. If the domain created an application, I would expect the appli= cation ID to return information about it? 2 - If the INFO request did include the application ID, should we validate = the phase to make sure that it matched the phase of the application? Again= , that could get complicated if the phase of the application in landrush us= ed different values depending on overlapping periods. Cheers, Ben From: Gould, James [mailto:JGould@verisign.com] Sent: Friday, May 03, 2013 11:39 AM To: Ben Levac; EPP Provreg (provreg@ietf.org) Subject: Re: Launch Phase EPP Extension Version 10 Ben, My feedback is below. To note, these are suggestions on how I might go abo= ut it, but I'm sure there are other ways to skin the cat. -- JG [cid:image001.png@01CE4962.BE9520B0] James Gould Principal Software Engineer jgould@verisign.com 703-948-3271 (Office) 12061 Bluemont Way Reston, VA 20190 VerisignInc.com From: Ben Levac > Date: Friday, May 3, 2013 11:46 AM To: James Gould >, EPP Prov= reg > Subject: RE: Launch Phase EPP Extension Version 10 James, I do have some questions, specifically around how the proposed model handle= s simultaneous phases. 1 - The first question is around the handling of overlapping claims and lan= drush (which will most likely be the case for us). If I understood section= 2.2 of the requirement, a landrush application that was NOT subject to a c= laim would pass the launch:create extension with just the phase like this: landrush The phase that is being passed should match the phase that the server is ac= tivitly running, which is "claims" with the sub-phase "landrush". It would= look like the following in General Create Form according to the overlap ha= ndling defined in section 2.2 "Launch Phase": claims While a landrush application that WAS subject to a claims would pass the fo= llowing extension: claims ... COMMENT: This means that we can't judge the phase based only the value of t= he phase element, but we also have to base it off the name which seems a bi= t awkward. The phases would be exactly the same for this use case, except the notice w= ould be included: claims ... 2 - In the case where we are running a special custom "sunrise 2" to restri= ct registration to a specific group, it's not clear to me whether we should= follow the proposed landrush from 2.2: Without claim: custom With claim: claims ... Does the "sunrise 2" overlap with the "claims" phase and does it proceed th= e "landrush" phase? If so, I would recommend always specifying "claims" as= the phase and "sunrise 2" or "landrush" as a sub-phase for both the Genera= l Create Form and the Claims Create Form as in: claims claims ... Or whether we should use a custom phase sort of as is proposed in section 3= .3.4: Without claim: custom With claim: custom ... I do not believe there is the need for a custom phase. 3 - Finally there might be a scenario where we might want to run 2 concurre= nt custom phases. Say that there are some domains which will require mark = data to be registered, even in a custom sunrise or landrush. We would expe= ct a "custom" phase with mark information to be passed. But if this happen= s during a custom sunrise, then I can't think of a good way to handle this= , other than creating a hybrid custom phase, so you would use either: custom custom I always view the server being in a single active phase, where in this use = case the active phase will require mark data for a subset of the domains. = The phase value passed can be identical, where it could be a single custom = phase (e.g. custom), and the = passing of the required mark data would be up to the client to pass based o= n I'm guessing a known set of domains that would require it. The server wo= uld match the custom phase and would apply the server logic for the differe= nt groups of domains (requiring the mark data or not). If this phase overl= aps with the "claims" phase, then the same use of a sub-phase would apply t= hat was discussed in the prior use cases. 4 - COMMENT: Given 1, 2 and 3, wouldn't it be better if we allowed someone = to send multiple independent phases? Different scenarios include completel= y different launch:create extensions, one for each phase with the data requ= ired for that phase. Or just allowing multiple phase elements inside the = single extension? There are other options that could be cleaner such as tu= rning the launch:create into a collection, but that would be a big schema c= hange at this point in the game... I believe that you can accomplish this using a combination of the phase and= sub-phases with the option of passing the notice and the mark information.= The key is not to make it so custom that it will make it too challenging = for the client to now what to do. 5 - My next question is regarding the INFO command specified in 3.2: If the application/registration was created as part of a claim request, wou= ld the info response ever show the claims information? So for example, if = I created a landrush domain that had a claim against it with what I assume = is the proposed method: claims ... Then what INFO command extension phase information would the registrar have= to send to get information back on this domain? And what phase informatio= n would the server return to him in the response? The phase of the info is based on the context of when the application or re= gistration was created. The only applicable information returned in the ex= tension to the info response during the claims phase is the application inf= ormation (e.g. status). The info response does not support the returning o= f the claims information. 6 - Is phase information really required for INFO requests? I assume that = application IDs are unique to the registry? So if you pass it in, then we = would return information regarding the application including the phase. Ot= herwise, we are infoing a registration. In this case, I'm not sure why we = would want to send in the extension? The draft does not specify that the application ID's are unique, but I beli= eve they should be. The phase defines the context of the query and the app= lication ID defines the specific application without the phase; although I = don't see why an application ID can not be unique across phases. Outside su= nrise, the extension to the info command / response is focused on the appli= cation status. Sorry for the long list of questions this late in the process, but I just w= ant to make sure that we (and everyone on the list) have a clear understand= ing of the mechanisms, especially around concurrent phases which does tend = to get a bit more complicated. Hopefully my suggestions help. Cheers, Ben From: provreg-bounces@ietf.org [mailto:pro= vreg-bounces@ietf.org] On Behalf Of Gould, James Sent: Wednesday, May 01, 2013 5:33 AM To: EPP Provreg (provreg@ietf.org) Subject: [provreg] Launch Phase EPP Extension Version 10 Wil Tan, Gavin Brown and I have updated the Launch Phase EPP Extension Mapping to Version 10. You can find the draft at the URL http://tools.ietf= .org/html/draft-tan-epp-launchphase-10. This version includes the following changes: 1. Changed noticeIDType from base64Binary to token to be compatible wit= h draft-lozano-tmch-func-spec-05. 2. Changed codeType from base64Binary to token to be more generic. 3. Updated based on feedback from Alexander Mayrhofer, which include: 1. Changed "extension to the domain name extension" to "extension to the domain name mapping". 2. Changed use of 2004 return code to 2306 return code when phase passed mismatches active phase and sub-phase. 3. Changed description of "allocated" and "rejected" statuses. 4. Moved sentence on a synchronous command without the use of an intermediate application, then an Application Identifier MAY not be needed to the Application Identifier section. 5. Restructured the Mark Validation Models section to include the " element" sub-section, the " element" sub-section, and the Digital Signature sub- section. 6. Changed "Registries may" to "Registries MAY". 7. Changed "extensed" to "extended" in "Availability Check Form" section. 8. Broke the mix of create forms in the "EPP Command" section to a fourth "Mixed Create Form" with its own sub- section. 9. Removed "displayed or" from "displayed or accepted" in the description. 10. Replaced "given domain name is supported" with "given domain name are supported" in the "Create Response" section. 11. Changed the reference of 2303 (object does not exist) in the "Security Considerations" section to 2201 (authorization error). 12. Added arrow from "invalid" status to "pendingValidation" status and "pendingAllocation" status to "rejected" status in the State Transition Diagram. 4. Added the "C:" and "S:" example prefixes and related text in the "Conventions Used in This Document" section. We are hoping that the draft stabilizes with this version. Please reply with any feedback. Thanks, JG James F. Gould Verisign "This message (including any attachments) is intended only for the use of t= he individual or entity to which it is addressed, and may contain informati= on that is non-public, proprietary, privileged, confidential and exempt fro= m disclosure under applicable law or may be constituted as attorney work pr= oduct. If you are not the intended recipient, you are hereby notified that = any use, dissemination, distribution, or copying of this communication is s= trictly prohibited. If you have received this message in error, notify send= er immediately and delete this message immediately." ________________________________ Please NOTE: This electronic message, including any attachments, may includ= e privileged, confidential and/or inside information owned by Demand Media,= Inc. Any distribution or use of this communication by anyone other than th= e intended recipient(s) is strictly prohibited and may be unlawful. If you = are not the intended recipient, please notify the sender by replying to thi= s message and then delete it from your system. Thank you. ________________________________ Please NOTE: This electronic message, including any attachments, may includ= e privileged, confidential and/or inside information owned by Demand Media,= Inc. Any distribution or use of this communication by anyone other than th= e intended recipient(s) is strictly prohibited and may be unlawful. If you = are not the intended recipient, please notify the sender by replying to thi= s message and then delete it from your system. Thank you. --_000_1DC00B9E9F0BAB44A146755EE8B1642D62E2F4BAD9SMO92WEXVS01c_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

James,<= /p>

 <= /p>

Thank you for your answer= s.  It certainly does clarifies what the vision behind some of the sug= gestions in the document.

 <= /p>

It seems that you are sug= gesting that if the claims and landrush phases overlap, then the claims per= iod is the principal phase?  Since ICANN is currently proposing the claims period for 90 days after sunrise, it is likely that landrush an= d claims will overlap for a lot of registries.  And what seems awkward= to me is that we would be asking registrars to send the following phase in= formation for every single application even though (I assume) few of them will ever actually need to pass actual = claims notice information…

 <= /p>

<launch:phase name=3D&= #8221;landrush”>claims</launch:phase>

 <= /p>

Wouldn’t it make mo= re sense to ask them to provide the following, because to my previous comme= nts on this topic in revision 08, I am most interested in validating their actual intention of submitting a landrush application (as opposed to= a general registration).

 <= /p>

<launch:phase>landr= ush</launch:phase>

 <= /p>

From a validation perspec= tive, I’m not sure I care to validate the fact that they passed in &#= 8220;claims” as a phase or sub-phase.  I do however, want to val= idate that they passed in valid claims notice information if the domain is part = of the DNL list.  And we would return an error message if they did not= .

 <= /p>

What I would also want to= avoid is that if the landrush period does last longer than the claims peri= od, to have different phase values for landrush applications.  For example:

 <= /p>

1 - Applications submitte= d before claim ends would have to return the following phase in the info re= sponse: <launch:phase name=3D”landrush”>claims</launch= :phase>

2 – While applicati= ons submitted after the claims period ends would have to return the followi= ng in the response: <launch:phase>landrush</launch:phase><= /o:p>

 <= /p>

Because they are all land= rush applications, I would only ever want to have to return <launch:phas= e>landrush</launch:phase> in the info response, especially since we never even return the claims information.

 <= /p>

I have a couple of questi= ons about the following statement:

 <= /p>

JG>The draft does not specify that the applicatio= n ID's are unique, but I believe they should be.  The phase defines th= e context of the query and the application ID defines the specific applicat= ion without the phase; although I don't see why an application ID cannot be unique across phases. Outside sunrise, the= extension to the info command / response is focused on the application sta= tus.  

 <= /p>

1 – What would the = INFO response return if a registrar passed in a phase and no application ID= ?  Would we return a validation error?  If the domain was registe= red in that phase, I would expect the INFO to return a regular INFO response. =  If the domain created an application, I would expect the application = ID to return information about it?

2 – If the INFO req= uest did include the application ID, should we validate the phase to make s= ure that it matched the phase of the application?  Again, that could get complicated if the phase of the application in landrush used dif= ferent values depending on overlapping periods.

 <= /p>

Cheers,=

 <= /p>

Ben

 <= /p>

From: Gould, J= ames [mailto:JGould@verisign.com]
Sent: Friday, May 03, 2013 11:39 AM
To: Ben Levac; EPP Provreg (provreg@ietf.org)
Subject: Re: Launch Phase EPP Extension Version 10=

 

Ben,

 

My feedback is below.  = ;To note, these are suggestions on how I might go about it, but I'm sure th= ere are other ways to skin the cat.  

 

-- 

 

JG

 

 

James Gould

Principal Software Engineer<= /p>

jgould@verisign.c= om

 

703-948-3271 (Office)

12061 Bluemont Way

Reston, VA 20190

VerisignInc.com

 

From: Ben Levac <Benoit.Levac@demandmedia.com>
Date: Friday, May 3, 2013 11:46 AM
To: James Gould <jgould@ve= risign.com>, EPP Provreg <pro= vreg@ietf.org>
Subject: RE: Launch Phase EPP Extension Version 10=

 

James,

 

I do have some questions,= specifically around how the proposed model handles simultaneous phases.

 

1 – The first quest= ion is around the handling of overlapping claims and landrush (which will m= ost likely be the case for us).  If I understood section 2.2 of the requirement, a landrush application that was NOT subject to a claim wo= uld pass the launch:create extension with just the phase like this:<= span style=3D"color:black">

 

<launch:create xmlns:l= aunch=3D"urn:ietf:params:xml:ns:launch-1.0" type=3D"applicat= ion">

    &= nbsp;           <launc= h:phase>landrush</launch:phase>=

</launch:create>

 =

 

The phase that is being pas= sed should match the phase that the server is activitly running, which is &= quot;claims" with the sub-phase "landrush".  It would l= ook like the following in General Create Form according to the overlap handling def= ined in section 2.2 "Launch Phase":

 

<launch:create xmlns:launch=3D"= urn:ietf:params:xml:ns:launch-1.0" type=3D"application"><= /span>

      &nb= sp;         <launch:phase name= =3D"landrush">claims</launch:phase>

</launch:create>

 

 

While a landrush applicat= ion that WAS subject to a claims would pass the following extension:=

 

<launch:create xmlns:l= aunch=3D"urn:ietf:params:xml:ns:launch-1.0">

  <launch:phase n= ame=3D”landrush”>claims</launch:phase>

  <launch:notice&= gt;

  …

  </launch:notice= >

</launch:create>

 

COMMENT: This means that we can’t judge the phase bas= ed only the value of the phase element, but we also have to base it off the name which= seems a bit awkward.<= /p>

 

 

The phases would be exactly= the same for this use case, except the notice would be included:

 

<launch:create xmlns:launch=3D"= urn:ietf:params:xml:ns:launch-1.0" type=3D"application"><= /span>

      &nb= sp;         <launch:phase name= =3D"landrush">claims</launch:phase><= o:p>

  

<launch:notice>

…

</launch:notice>

</launch:create>

 

 

2 – In the case whe= re we are running a special custom “sunrise 2” to restrict regi= stration to a specific group, it’s not clear to me whether we should = follow the proposed landrush from 2.2:

 

Without claim:<= /b>

 

<launch:create xmlns:l= aunch=3D"urn:ietf:params:xml:ns:launch-1.0" type=3D"applicat= ion">

    &= nbsp;           <launc= h:phase name=3D”sunrise 2”>custom</launch:phase>

</launch:create>

 

With claim:=

 

<launch:create xmlns:l= aunch=3D"urn:ietf:params:xml:ns:launch-1.0">

  <launch:phase n= ame=3D”sunrise 2”>claims</launch:phase>

  <launch:notice&= gt;

  …

  </launch:notice= >

</launch:create>

 

 

Does the "sunrise 2" overlap with the &quo= t;claims" phase and does it proceed the "landrush" phase? &n= bsp;If so, I would recommend always specifying "claims" as the ph= ase and "sunrise 2" or "landrush" as a sub-phase for bo= th the General Create Form and the Claims Create Form as in:

 

<launch:create xmlns:launch=3D"= urn:ietf:params:xml:ns:launch-1.0" type=3D"application"><= /span>

      &nb= sp;         <launch:phase name= =3D"sunrise 2">claims</launch:phase>

</launch:create>

 

<launch:create xmlns:launch=3D"= urn:ietf:params:xml:ns:launch-1.0" type=3D"application"><= /span>

      &nb= sp;         <launch:phase name= =3D"landrush">claims</launch:phase><= o:p>

  

<launch:notice>

…

</launch:notice>

</launch:create>

 

 

Or whether we should use a custom phase sort of as is propo= sed in section 3.3.4:

 

Without claim:<= /b>

 

<launch:create xmlns:l= aunch=3D"urn:ietf:params:xml:ns:launch-1.0" type=3D"applicat= ion">

    &= nbsp;           <launc= h:phase name=3D”sunrise 2”>custom</launch:phase>

</launch:create>

 

With claim:=

 

<launch:create xmlns:l= aunch=3D"urn:ietf:params:xml:ns:launch-1.0">

  <launch:phase n= ame=3D”sunrise 2 - claims”>custom</launch:phase>

  <launch:notice&= gt;

  …

  </launch:notice= >

</launch:create>

 

 

I do not believe there is the need for a custom phas= e.

 

3 – Finally there m= ight be a scenario where we might want to run 2 concurrent custom phases.&n= bsp; Say that there are some domains which will require mark data to be registered, even in a custom sunrise or landrush.  We would expect= a “custom” phase with mark information to be passed.  But= if this happens during a custom sunrise,  then I can’t think of= a good way to handle this, other than creating a hybrid custom phase, so you would use either:

 

<launch:phase name=3D&= #8221;special”>custom</launch:phase>

<launch:phase name=3D&= #8221;sunrise2 - special”>custom</launch:phase>

 

I always view the server being in a single active ph= ase, where in this use case the active phase will require mark data for a s= ubset of the domains.  The phase value passed can be identical, where = it could be a single custom phase (e.g. <launch:phase name=3D"special">custom</launch:phase>= ), and the passing of the required mark data would be up to the client to p= ass based on I'm guessing a known set of domains that would require it. &nb= sp;The server would match the custom phase and would apply the server logic for the different groups of domains (requiring the mark data = or not).  If this phase overlaps with the "claims" phase, th= en the same use of a sub-phase would apply that was discussed in the prior = use cases.

 

 

4 – COMMENT: Given 1, 2 and 3, wouldn’t it be better if we allowed= someone to send multiple independent phases?  Different scenarios inc= lude completely different launch:create extensions, one for each phase with= the data required for that phase.   Or just allowing multiple phase elements inside the single extension?  There = are other options that could be cleaner such as turning the launch:create i= nto a collection, but that would be a big schema change at this point in th= e game…

 

 

I believe that you can accomplish this using a combi= nation of the phase and sub-phases with the option of passing the notice an= d the mark information.  The key is not to make it so custom that it w= ill make it too challenging for the client to now what to do.

 

5 – My next questio= n is regarding the INFO command specified in 3.2:

 

If the application/regist= ration was created as part of a claim request, would the info response ever= show the claims information?  So for example, if I created a landrush domain that had a claim against it with what I assume is the pr= oposed method:

 

<launch:create xmlns:l= aunch=3D"urn:ietf:params:xml:ns:launch-1.0">

  <launch:phase n= ame=3D”landrush”>claims</launch:phase>

  <launch:notice&= gt;

  …

  </launch:notice= >

</launch:create>

 

Then what INFO command ex= tension phase information would the registrar have to send to get informati= on back on this domain?  And what phase information would the server return to him in the response?

 

 

The phase of the info is based on the context of whe= n the application or registration was created.  The only applicable in= formation returned in the extension to the info response during the claims = phase is the application information (e.g. status).  The info response does not support the returning of the cla= ims information.   

 

6 – Is phase inform= ation really required for INFO requests?  I assume that application ID= s are unique to the registry?  So if you pass it in, then we would return information regarding the application including the phase.  Ot= herwise, we are infoing a registration.  In this case, I’m not s= ure why we would want to send in the extension?

 

 

The draft does not specify that the application ID's= are unique, but I believe they should be.  The phase defines the cont= ext of the query and the application ID defines the specific application wi= thout the phase; although I don't see why an application ID can not be unique across phases. Outside sunrise, the ex= tension to the info command / response is focused on the application status= .  

 

Sorry for the long list o= f questions this late in the process, but I just want to make sure that we = (and everyone on the list) have a clear understanding of the mechanisms, especially around concurrent phases which does tend to get= a bit more complicated.

 

Hopefully my suggestions help.  

 

 

Cheers,

 

Ben

 

From: provreg-bounces@ietf.org [<= a href=3D"mailto:provreg-bounces@ietf.org">mailto:provreg-bounces@ietf.org<= /a>] On Behalf Of Gould, James
Sent: Wednesday, May 01, 2013 5:33 AM
To: EPP Provreg (provreg@ietf.or= g)
Subject: [provreg] Launch Phase EPP Extension Version 10

 =

Wil Tan= , Gavin Brown and I have updated the Launch Phase EPP Extension

Mapping= to Version 10.  You can find the draft at the URL http://tools.i= etf.org/html/draft-tan-epp-launchphase-10.  This version

include= s the following changes:

 <= /span>

 &nbs=
p; 1.  Changed noticeIDType from base64Binary to token to be compatibl=
e with
 &nbs=
p;     draft-lozano-tmch-func-spec-05.
 &nbs=
p; 2.  Changed codeType from base64Binary to token to be more generic.=

  &nb=
sp;3.  Updated based on feedback from Alexander Mayrhofer, which
 &nbs=
p;     include:=

 &nbs=
p;     1.   Changed "extension to the do=
main name extension" to<=
/span>
 &nbs=
p;          "extension to=
 the domain name mapping".
 &nbs=
p;     2.   Changed use of 2004 return code t=
o 2306 return code when
 &nbs=
p;          phase passed misma=
tches active phase and sub-phase.
 &nbs=
p;     3.   Changed description of "allo=
cated" and "rejected" statuses.
 &nbs=
p;     4.   Moved sentence on a synchronous &=
lt;domain:create> command<=
/span>
 &nbs=
p;          without the use of=
 an intermediate application, then an
 &nbs=
p;          Application Identi=
fier MAY not be needed to the Application
 &nbs=
p;          Identifier section=
.
 &nbs=
p;     5.   Restructured the Mark Validation =
Models section to include
 &nbs=
p;          the "<laun=
ch:codeMark> element" sub-section, the "<mark:
 &nbs=
p;          mark> element&q=
uot; sub-section, and the Digital Signature sub-
 &nbs=
p;          section.
 &nbs=
p;     6.   Changed "Registries may"=
; to "Registries MAY".
 &nbs=
p;     7.   Changed "extensed" to &=
quot;extended" in "Availability Check
 &nbs=
p;          Form" section=
.
 &nbs=
p;     8.   Broke the mix of create forms in =
the "EPP <create> Command"
 &nbs=
p;          section to a fourt=
h "Mixed Create Form" with its own sub-
 &nbs=
p;          section.
 &nbs=
p;     9.   Removed "displayed or" =
from "displayed or accepted" in the
 &nbs=
p;          <launch:accepte=
dDate> description.=

 &nbs=
p;     10.  Replaced "given domain name is su=
pported" with "given domain
 &nbs=
p;          name are supported=
" in the "Create Response" section.
 &nbs=
p;     11.  Changed the reference of 2303 (object =
does not exist) in the=

 &nbs=
p;          "Security Con=
siderations" section to 2201 (authorization
 &nbs=
p;          error).
 &nbs=
p;     12.  Added arrow from "invalid" s=
tatus to "pendingValidation"
 &nbs=
p;          status and "p=
endingAllocation" status to "rejected" status
 &nbs=
p;          in the State Trans=
ition Diagram.
 &nbs=
p; 4.  Added the "C:" and "S:" example prefixes an=
d related text in the<=
/pre>

 &nbs=
p;     "Conventions Used in This Document" se=
ction.

 <= /span>

 

We are hoping that the draf= t stabilizes with this version.  Please reply

with any feedback.

 

Thanks,

 

JG

 

James F. Gould

Verisign

 

 

 

 

“This message (including any attachmen= ts) is intended only for the use of the individual or entity to which it is= addressed, and may contain information that is non-public, proprietary, pr= ivileged, confidential and exempt from disclosure under applicable law or may be constituted as attorney work product. If yo= u are not the intended recipient, you are hereby notified that any use, dis= semination, distribution, or copying of this communication is strictly proh= ibited. If you have received this message in error, notify sender immediately and delete this message immedi= ately.”

 

Please NOTE: This electronic me= ssage, including any attachments, may include privileged, confidential and/= or inside information owned by Demand Media, Inc. Any distribution or use of this communication by anyone other than the intended recipient(s= ) is strictly prohibited and may be unlawful. If you are not the intended r= ecipient, please notify the sender by replying to this message and then del= ete it from your system. Thank you.


Please NOTE: This electronic= message, including any attachments, may include privileged, confidential a= nd/or inside information owned by Demand Media, Inc. Any distribution or us= e of this communication by anyone other than the intended recipient(s) is strictly prohibited and may be unlawful.= If you are not the intended recipient, please notify the sender by replyin= g to this message and then delete it from your system. Thank you.
 --_000_1DC00B9E9F0BAB44A146755EE8B1642D62E2F4BAD9SMO92WEXVS01c_-- --_004_1DC00B9E9F0BAB44A146755EE8B1642D62E2F4BAD9SMO92WEXVS01c_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=4109; creation-date="Sun, 05 May 2013 23:13:53 GMT"; modification-date="Sun, 05 May 2013 23:13:53 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAEkAAABACAIAAADZHs1DAAAP1ElEQVRoBe2aa3CU1RnHN3vLJtmQ hEtiwlUBtZUUCiU6tU7wVhinjOB0xmJnFIdpO1Y6DY586Iwdo36gLc4Iip3pVAL9IKjTDnhDEEWC 1GoICHLRctEkXHIPuZHr7qa/c553T152N9lsNvnWM5nDec97Ls//+T+X854lZWBgwDFuRRaXOiUl hX2kHrcNr1vYfd1T0g/ACIVCQV0CgQD/8miwOZ1Ol8vldrupKTyOK9QU2ThpUA4w9Pf39/X19fT0 UCsYYHA6QcLiYKCwF2MEMNh8Pp/X6/V4PAxOXoDoFcYAG7ICplsXNvClpSFvipAimGy1wQmrMgV4 aUzxekEbLV8yPUlhE66u6YJkqT6fMjKDyjRs2GgaeNKA587OTqZnZGSMLYejx4biEautrQ3eUlNT LUiCx6AyjWHhAbKrqwuEwMNQxYyTYUzmjhIbboMo7e3tyIwoMYA5nZ+duXiyur6ju88u5ZL5s+ff mJ+TmUan4JUGNVbQ2tqKNvx+PwTaZ42uPRpseBeoYMygUvRoijp7AnuPXdhz9PyeyvPI7khxqtoU yTcDofk35j1674LH7luY7U8zVsoo2qgMc5gwYQIeaOaNrpEwNoCBqraujgBALDeoOnr6X9t/4rX9 x9t7gg6Xx+F0K1QEQOBRFKoBVYdCjoGgI6T+MtO9j9+74Nlf3gNChhiQHR0dwMvKykoSXmLYMEUY u3T5MoyxMZEDbJTK81fWlR242NrrcHsdToBpSBZpsKeps0gDocYWDDhC6i8zzbO9ZOWKH38/Ah5K hL1kjDMBbMQMDKa6pgaE6enpggp4r+z5cvOeLx0en6bLpRkTbIKKWjGnijoCgQ3qdB3sdwR6FcJg 8NF7Crc99XNeG/ZQIvkQ3xt1bhgpNrYhlMFYY0NDVna2Bczp/MPrh3dVVjncAHOrvxSwuSw3U3SF SVPIxDKpBVuYQOABMtg3f+aUA39aY/fApqYmLB89CmBZY+T1SA8EcIWb1dfXk8QIaFIUsKM1Dk+a w+1xuLQ1Ag9s1p9uC9rBTk2sUoRLq8Ojp6cy/UR100MvvK41oPkdGMjJySF3svXI8dhHjggbSDhD ED8wSxgTYLsqLihgbsRCULBp3gghBobyN5AY33NalKoeuA2rgInYs1rHU37m4rq/vW/gsReZk63Z 0S70CNsjwiakNTU2etxuAXax5dpf3juuuBJgFiQtPdgUKv3n1DZpPdrawFPDwvBoW/C8L79bceD4 eQOPcELMHB118bHhab29vYq0UIhjvGB77p+VHeRk7MpCIn5lgobRrHY5noCnQgrD5JX5sJJOPZ0Y q/h3rdn0NpsaePgbAkiPWXckjfjfOJytMHrcmngltnGsqqmyqllZUYozK82z4MY8tZNYmtnT6T5+ saWtV1DpXuARRYLB4ltyVWw0hZRA4VDS1Xfiu3pe1TR3vLDz4B9XLSGEAIlw0tzcTJ1oPoiPDXto uXoVzfkzM/kyQ4y/f3JW0QVpig3H7vXLJfkqEW3l4OlLd/95n7JbU0KB4rkTDz6z3HTYGyVlH5+o alTjQ6FtHx575hfFvAUeXodaESNRbHFsErWRQxsaGpRBpqRQX2ru/LKmRScxZZBtnd0lr31oF9G0 l9w2rfjmXJWppdDo79n+xL1mgL1RVd+6+f1jWmUq9dc0tb/z+TfsTmEYB2jEkLZ91vDtONgwQhgj ZavPaf1N/enZegUM3uTP7f3Hga8OnqyKuc323xQ7OH9ICQaefWjRrCkTYo5c/fK7yshlTXVkc739 +RlGanQDREvEEI+IOT1mZxxsBH0WlfO+uioIhQ6dbdSuhffrUI5Aqf7SNz6NuTpInl2xQHlXKJDl CZU8sCDmsN1fnC0/16wCiVqTU6jS3cGvqoUoakk87B9z+lCdcbChKoAJY7SBV9PUobMTE3VwQ9Me X/nXtds/Ph5zj5JlhVk+J2erTY/+JDvDF3tM2ceaNI41kjzw5BTMsrWzx8DD8caBt76+YEDZlaYt 1N4bUqo1fyBE39700rf+09rZHS16dkbqplWL5xf4Vy9Rp+HoUvrG4eo2/emgzmgUWVzBO/Fdrdgk vZjlGPPG0nClCVP1uXpIE6qtPKVBOtF6dUv3pt2faeEiK1Bt/+39kb36ufVaz6YPz6jEDf+WvvQL Mor+WhVsSozwfVnMdWJ2DpcDZF0MElj9+kKuvZuERdEJ16p1B/nAk/bcv46svn/RrLxs3XVdBaUp KzYoR7UX1IS7qg+I62+BLALVUGSQGQbkyM/N129m31jnFukQ3kBoey9bWhuTudWXmze9ZOsQ+aBw 1oN3znOkZTsyJg3+pecQh3QCDFvB4AaqR1NlgZI3IwfG+OGwqdda0xg6qRPjnJGdqveIAKb7OBx6 fG8frR4qH2xaXZzl12diuDJ/KjbiYNevqriytGboMsLooSOq4mBDT1wbWLwFgz5sx3xZyh1B2GaU fDqolJR9FHNn8kHJT2+77rRlH6ew8EUnqHRjYGD65Ex1Ka0Lyk2INJaLg43DzqRJk8BG4WQAgd/L y9ASKFfQsoWl4UH7z4lL7cPkg5k5sdKAAFPLWahYnNuU6ZMnWDFkYEBpOcIt9fbDVHGwyRcUVyNg 6+ntxeVmT0pVx6jBb2cjjd6FtOtJKyk7MFQ+KF35Qz6xBwViHWV++m9wzRD03nXrVIs09tZxUhxk cG68VhxsqIrEkpOdDWPwxi43TUzVt1TcC+g/uyHRxnncqW39rtK3hsgHxbfOn04g1WFJARNcRkE0 9LKh4AOL5hjSerq7EWOMecMSIC0/Px9UwOMzceE0/+QMtyUBcqg7Of5EOK1Jwo/Ht/m9So6/0Zol oVXVNmueBJidNFmKNdVF2LKFsxVvmjTUihhj7G8GG1KyC2dLEN4xw69ub7QEgyAlDIgT6qCijr9R pfTNf7f1Ch4YE1O0kabW5Nqr/+E7b8HfLN50Khh7bMjGVSQ2mX/DDRBHsEKFS+dOSHMNqAO+OgSL 74VVrkxUZUYss/ybuoh8UNXYvnnfaXUNQRkExly9iFpKX10G+p56sMgAQ6EYJGJEKSpORxx/YzZW zlf9DwoL+aUQeHyDp7oGfnW7/nYWNataY6OWBtN0UFm95QP7/qu37FUpnnAKfqWFsEbURI0KfQFs +aJpE/3GIFEoAiTqbEoE+95DtbGHvLy8adOmCTwunublehfc4NWWGWZPtG6FUO1Lbm91c9emdypk WT7DYVJhpoijGkiWjrilDMzLz/j9zxYpLwt7mvwEOZRsw/SPCBs649ejosWLyePA69W/jD6+aNL0 TKe+NhV42j5F/cKeTnelbx6WfKDcT04h8lZpQXOlv+5knUxP8K+/vl9QCTyiCVuPgjQwu0pLS4eB Lq+IKOQWNiDF1dXVYVB89fi8njtmZp6u62rvjfpk5IwiQcXh6O3rr2u6WtXQ/mZFtcKmStjBFHth eMFApjuwY+19N+XlMEIdwrjCCAYzMzPBlmhmU5uwAIqRVtyaKNLS0rJv//5Lly6xGT/iZPj9AYfr xU8bLnaElNzqRkDukuUTUx8TddxT0UUNIHnoqIizKfYEWBBVwdi2J+6bN30SK8tPKMjD3dbEiRPx iLiyxRyQADa0QH6rra19b88efkayw3v3m7aPLnQp0YmB6kssjA1IFKU+/cVptXUUUf7JlZ6y5x/N yN782J1ZGT4FTBcuDjP9fo57OFuiac3gTAAbc/ABAsmV2toP9u418Pgxghh9rrlv29Hmpi5NINjI 4NQUqa0NNWkqPMIbpAVmZPseL5774KJZYVBwlkLQz87Kys3NhTf6ramJ/5MYNtYHHj/ocM1sh+f2 eOTHpM8vdh3+ruPrhm7NXvhT2vqGYbZgA1VozpSMh4tmLl84w6CiweJYfu4UVYj7yQBjs4SxCTzY u3r16ifl5TU1NUigfkB1uVAzJkTIaekOfl3f9d/G3sbOvsZr/U3X1HVLps81c2J6flba3Dz/XTfn FWSnMYW5jBcM5DHaBfn5+FiSjLEdZTTYmCYK5grs9JkzlZWVJAaBh5QKIeda/R9nlNxadgEgtYUG VBqZOqeyXCgEpKkFBfJLt6DVEo6+GiU2NiS04PHYZ0Nj4+lTp85duECXoYIjEgg9/LcfQBqcNpaY TgEXMPhpG1Rgww6ZOOrgEaGG0WOThYRAEDa3tJw/f/7Ct98SCTQfihXT4AGcBApmCXtkTMATCfNy c/kNEVTEesZHyJfMY7LYZG/Uj7eQIQBZ39DAz6tkQvXY3W2HRxuLJeqo+D55MkdwIOGi/IgB4GRg xJw7NthkaTgUkPK5QI3R0kM/AwQkJgcSKKKmCIcxJUu+cyyxGWnEl4BEkTav8CIKCCnSNuPHqTEu 2MZJ1kSXHUvfTXTv8R7/f2zjreHxWT/hS4hkxLhy5QqHNVaYOnUqoX/4pS5wGNCFnE4CHH5wzLfu jS++eOXyZd5t2LBB9tu9e3d5eTk9a9as2bp1a/S0tWvXzp49+9VXXyVZ298iRFFR0dKlS+k0b196 6SUeQcVSJD0znpErV65kRzBs2bKF/mXLlsncYQYzbN26ddQFU6euf/ppGma6SLVz586TJ0/Sj/DO 24uKaFGki8Y5LTFJdt68efrNSCtE37t376lTp6InRABjQEVFxfPPP09+jxgMMKCKFpCBIoNf0fjN YPg4dOiQeTQNVIZRiHW4CwsLd+3axTtIWLx4Mad7oZF+M2HOnDlPPvmkeYxoGGY2btzIK4SOUAqq FVmLi4tXrFgBHlTAMFQbbZm8EskeeeQR5GFBoYKLtoh9GQmSiE4MyojqxpThFzzwtmrVKmNmdmxI tm/fPrOKWI55lAYGKQ2RLOKtPLIFPKBXZALkUGPoRyQBRhupMNdol2MjWImGZ5ZVsQSzZBBDsQex TCSw616MzcyJwIZr8UqYoQHJZqQ00KWoz74OW+BvBkDEFGEJecSm5C3jCwoKpM10BIZ8NBUx1zwq bMYsASa82UljgCjbzIloGKrpR4sYXsQAHn+3di0mhCeLwdODZDt27IjYyEzkrYyxLy6dMoaNkNau LDPXNBQ2Y5Zsb2aaETTQjTFie7+0MZivTp4UoQEW7UIyTJyNNmywkRjIZR2i7WsKIbzFaNmX6McY O3syWGgnRNkB29ehbZ1LltiUjedgRfZxfKoQD0xBOPtbTPShlSulJ1oI+omchEQizZEjR4hV9PCx J+ONl8ojtTAJIWVlZYL8iwrrZtqMkQZeE23/9jGKN4rdNuxteQsnkoLkMTpsogtmiUmDxO6rTEG1 ol2MUFaQGrvCZIyjSidWwDqMp6bYx0e3iaVoLbpfeixsGBI2I3qyR56YihH3jXBiHF0AIBDY7G8J GPDDecDIyiO7SEzCumQX4RC069evh38ZzFsEE6+jjdARg9GF/a0d5/8ActOtScHpPCkAAAAASUVO RK5CYII= --_004_1DC00B9E9F0BAB44A146755EE8B1642D62E2F4BAD9SMO92WEXVS01c_-- From JGould@verisign.com Mon May 6 06:00:37 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D166F21F8FDF for ; Mon, 6 May 2013 06:00:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e-x3i+8YvrSH for ; Mon, 6 May 2013 06:00:33 -0700 (PDT) Received: from exprod6og123.obsmtp.com (exprod6og123.obsmtp.com [64.18.1.241]) by ietfa.amsl.com (Postfix) with ESMTP id F178F21F8FDC for ; Mon, 6 May 2013 06:00:30 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob123.postini.com ([64.18.5.12]) with SMTP ID DSNKUYepbt6KDbMOEFNz0C6caHgy/9jCJD0s@postini.com; Mon, 06 May 2013 06:00:32 PDT Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id r46D0RgD011427 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 6 May 2013 09:00:27 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Mon, 6 May 2013 09:00:26 -0400 From: "Gould, James" To: Ben Levac , "EPP Provreg (provreg@ietf.org)" Thread-Topic: Launch Phase EPP Extension Version 10 Thread-Index: AQHORmgC76piG2RBeE2BJXZKE2THBpjzkspAgAA7bwCAAt7w4IABeVSA Date: Mon, 6 May 2013 13:00:25 +0000 Message-ID: In-Reply-To: <1DC00B9E9F0BAB44A146755EE8B1642D62E2F4BAD9@SMO92WEXVS01.corp.dm.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.173.152.4] Content-Type: multipart/mixed; boundary="_006_CDAD19404EF40jgouldverisigncom_" MIME-Version: 1.0 Subject: Re: [provreg] Launch Phase EPP Extension Version 10 X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2013 13:00:37 -0000 --_006_CDAD19404EF40jgouldverisigncom_ Content-Type: multipart/related; boundary="_005_CDAD19404EF40jgouldverisigncom_"; type="multipart/alternative" --_005_CDAD19404EF40jgouldverisigncom_ Content-Type: multipart/alternative; boundary="_000_CDAD19404EF40jgouldverisigncom_" --_000_CDAD19404EF40jgouldverisigncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Ben, My feedback is below. -- JG [cid:DDC715B1-58BA-450C-BF20-BDDFB0A67208] James Gould Principal Software Engineer jgould@verisign.com 703-948-3271 (Office) 12061 Bluemont Way Reston, VA 20190 VerisignInc.com From: Ben Levac > Date: Sunday, May 5, 2013 7:13 PM To: James Gould >, EPP Prov= reg > Subject: RE: Launch Phase EPP Extension Version 10 James, Thank you for your answers. It certainly does clarifies what the vision be= hind some of the suggestions in the document. It seems that you are suggesting that if the claims and landrush phases ove= rlap, then the claims period is the principal phase? Since ICANN is curren= tly proposing the claims period for 90 days after sunrise, it is likely tha= t landrush and claims will overlap for a lot of registries. And what seems= awkward to me is that we would be asking registrars to send the following = phase information for every single application even though (I assume) few o= f them will ever actually need to pass actual claims notice information=85 claims Yes, this is the recommended phase for landrush during the claims period. = There are many ways to handle this, but it was felt that leveraging the exi= sting support for phases and optional sub-phases for the overlapping claims= and landrush phases to be the cleanest and least impactful. Passing the s= ame values for the phase independent of the need for a notice should be eas= ier for the client as well. Wouldn=92t it make more sense to ask them to provide the following, because= to my previous comments on this topic in revision 08, I am most interested= in validating their actual intention of submitting a landrush application = (as opposed to a general registration). landrush As discussed earlier on the list a landrush could be setup with a first-com= e-first-serve model in the case of a dutch auction, so there is no implied = expectation that the landrush phase will result in an application. The dra= ft supports the client passing the expected object to create with the optio= nal "type" attribute with the values of "application" or "registration". T= he extension could include the following value for an overlapping landrush = during claims of applications. My recommendation is not to require the "ty= pe" attribute to be passed, but to simply validate it if passed by the clie= nt against the type of object that will be created with the active server l= aunch phase. claims >From a validation perspective, I=92m not sure I care to validate the fact t= hat they passed in =93claims=94 as a phase or sub-phase. I do however, wan= t to validate that they passed in valid claims notice information if the do= main is part of the DNL list. And we would return an error message if they= did not. What I would also want to avoid is that if the landrush period does last lo= nger than the claims period, to have different phase values for landrush ap= plications. For example: 1 - Applications submitted before claim ends would have to return the follo= wing phase in the info response: claims= 2 =96 While applications submitted after the claims period ends would have = to return the following in the response: landrush Because they are all landrush applications, I would only ever want to have = to return landrush in the info response, espec= ially since we never even return the claims information. Yes, this is a corner case that would require you to split the landrush int= o separate phases: "claims" with "landrush" sub-phase and "landrush". You = could consider extending the "claims" phase to fully cover the "landrush" t= o forgo the split. I'm not sure if this is a likely use case considering t= he requirement for a 90 day claims, but you have the option of having the l= andrush as a sub-phase of claims, split the phases, or start landrush after= claims. I have a couple of questions about the following statement: JG>The draft does not specify that the application ID's are unique, but I b= elieve they should be. The phase defines the context of the query and the = application ID defines the specific application without the phase; although= I don't see why an application ID cannot be unique across phases. Outside = sunrise, the extension to the info command / response is focused on the app= lication status. 1 =96 What would the INFO response return if a registrar passed in a phase = and no application ID? Would we return a validation error? If the domain = was registered in that phase, I would expect the INFO to return a regular I= NFO response. If the domain created an application, I would expect the app= lication ID to return information about it? If an info command was sent without the application ID then that would mean= that the phase passed was for a none pending launch phase, so if the launc= h phase was a non pending launch phase the server could return a successful= info response. In the case of sunrise, this could include the information. A registration can have launch statuses as well, so the could be returned. An info command referencing a launch phas= e that was a pending launch phase without the application ID should result = in an error. 2 =96 If the INFO request did include the application ID, should we validat= e the phase to make sure that it matched the phase of the application? Aga= in, that could get complicated if the phase of the application in landrush = used different values depending on overlapping periods. Yes, the correct phase value should be passed to get the information for th= e application that was created in that phase. This is one reason that we i= ncluded the recommendation to use claims as the phase for the likely combination of landrush and claims= . Cheers, Ben From: Gould, James [mailto:JGould@verisign.com] Sent: Friday, May 03, 2013 11:39 AM To: Ben Levac; EPP Provreg (provreg@ietf.org) Subject: Re: Launch Phase EPP Extension Version 10 Ben, My feedback is below. To note, these are suggestions on how I might go abo= ut it, but I'm sure there are other ways to skin the cat. -- JG [cid:image001.png@01CE4962.BE9520B0] James Gould Principal Software Engineer jgould@verisign.com 703-948-3271 (Office) 12061 Bluemont Way Reston, VA 20190 VerisignInc.com From: Ben Levac > Date: Friday, May 3, 2013 11:46 AM To: James Gould >, EPP Prov= reg > Subject: RE: Launch Phase EPP Extension Version 10 James, I do have some questions, specifically around how the proposed model handle= s simultaneous phases. 1 =96 The first question is around the handling of overlapping claims and l= andrush (which will most likely be the case for us). If I understood secti= on 2.2 of the requirement, a landrush application that was NOT subject to a= claim would pass the launch:create extension with just the phase like this= : landrush The phase that is being passed should match the phase that the server is ac= tivitly running, which is "claims" with the sub-phase "landrush". It would= look like the following in General Create Form according to the overlap ha= ndling defined in section 2.2 "Launch Phase": claims While a landrush application that WAS subject to a claims would pass the fo= llowing extension: claims =85 COMMENT: This means that we can=92t judge the phase based only the value of= the phase element, but we also have to base it off the name which seems a = bit awkward. The phases would be exactly the same for this use case, except the notice w= ould be included: claims =85 2 =96 In the case where we are running a special custom =93sunrise 2=94 to = restrict registration to a specific group, it=92s not clear to me whether w= e should follow the proposed landrush from 2.2: Without claim: custom With claim: claims =85 Does the "sunrise 2" overlap with the "claims" phase and does it proceed th= e "landrush" phase? If so, I would recommend always specifying "claims" as= the phase and "sunrise 2" or "landrush" as a sub-phase for both the Genera= l Create Form and the Claims Create Form as in: claims claims =85 Or whether we should use a custom phase sort of as is proposed in section 3= .3.4: Without claim: custom With claim: custom =85 I do not believe there is the need for a custom phase. 3 =96 Finally there might be a scenario where we might want to run 2 concur= rent custom phases. Say that there are some domains which will require mar= k data to be registered, even in a custom sunrise or landrush. We would ex= pect a =93custom=94 phase with mark information to be passed. But if this = happens during a custom sunrise, then I can=92t think of a good way to han= dle this, other than creating a hybrid custom phase, so you would use eithe= r: custom custom I always view the server being in a single active phase, where in this use = case the active phase will require mark data for a subset of the domains. = The phase value passed can be identical, where it could be a single custom = phase (e.g. custom), and the = passing of the required mark data would be up to the client to pass based o= n I'm guessing a known set of domains that would require it. The server wo= uld match the custom phase and would apply the server logic for the differe= nt groups of domains (requiring the mark data or not). If this phase overl= aps with the "claims" phase, then the same use of a sub-phase would apply t= hat was discussed in the prior use cases. 4 =96 COMMENT: Given 1, 2 and 3, wouldn=92t it be better if we allowed some= one to send multiple independent phases? Different scenarios include compl= etely different launch:create extensions, one for each phase with the data = required for that phase. Or just allowing multiple phase elements inside = the single extension? There are other options that could be cleaner such a= s turning the launch:create into a collection, but that would be a big sche= ma change at this point in the game=85 I believe that you can accomplish this using a combination of the phase and= sub-phases with the option of passing the notice and the mark information.= The key is not to make it so custom that it will make it too challenging = for the client to now what to do. 5 =96 My next question is regarding the INFO command specified in 3.2: If the application/registration was created as part of a claim request, wou= ld the info response ever show the claims information? So for example, if = I created a landrush domain that had a claim against it with what I assume = is the proposed method: claims =85 Then what INFO command extension phase information would the registrar have= to send to get information back on this domain? And what phase informatio= n would the server return to him in the response? The phase of the info is based on the context of when the application or re= gistration was created. The only applicable information returned in the ex= tension to the info response during the claims phase is the application inf= ormation (e.g. status). The info response does not support the returning o= f the claims information. 6 =96 Is phase information really required for INFO requests? I assume tha= t application IDs are unique to the registry? So if you pass it in, then w= e would return information regarding the application including the phase. = Otherwise, we are infoing a registration. In this case, I=92m not sure why= we would want to send in the extension? The draft does not specify that the application ID's are unique, but I beli= eve they should be. The phase defines the context of the query and the app= lication ID defines the specific application without the phase; although I = don't see why an application ID can not be unique across phases. Outside su= nrise, the extension to the info command / response is focused on the appli= cation status. Sorry for the long list of questions this late in the process, but I just w= ant to make sure that we (and everyone on the list) have a clear understand= ing of the mechanisms, especially around concurrent phases which does tend = to get a bit more complicated. Hopefully my suggestions help. Cheers, Ben From:provreg-bounces@ietf.org [mailto:prov= reg-bounces@ietf.org] On Behalf Of Gould, James Sent: Wednesday, May 01, 2013 5:33 AM To: EPP Provreg (provreg@ietf.org) Subject: [provreg] Launch Phase EPP Extension Version 10 Wil Tan, Gavin Brown and I have updated the Launch Phase EPP Extension Mapping to Version 10. You can find the draft at the URL http://tools.ietf= .org/html/draft-tan-epp-launchphase-10. This version includes the following changes: 1. Changed noticeIDType from base64Binary to token to be compatible wit= h draft-lozano-tmch-func-spec-05. 2. Changed codeType from base64Binary to token to be more generic. 3. Updated based on feedback from Alexander Mayrhofer, which include: 1. Changed "extension to the domain name extension" to "extension to the domain name mapping". 2. Changed use of 2004 return code to 2306 return code when phase passed mismatches active phase and sub-phase. 3. Changed description of "allocated" and "rejected" statuses. 4. Moved sentence on a synchronous command without the use of an intermediate application, then an Application Identifier MAY not be needed to the Application Identifier section. 5. Restructured the Mark Validation Models section to include the " element" sub-section, the " element" sub-section, and the Digital Signature sub- section. 6. Changed "Registries may" to "Registries MAY". 7. Changed "extensed" to "extended" in "Availability Check Form" section. 8. Broke the mix of create forms in the "EPP Command" section to a fourth "Mixed Create Form" with its own sub- section. 9. Removed "displayed or" from "displayed or accepted" in the description. 10. Replaced "given domain name is supported" with "given domain name are supported" in the "Create Response" section. 11. Changed the reference of 2303 (object does not exist) in the "Security Considerations" section to 2201 (authorization error). 12. Added arrow from "invalid" status to "pendingValidation" status and "pendingAllocation" status to "rejected" status in the State Transition Diagram. 4. Added the "C:" and "S:" example prefixes and related text in the "Conventions Used in This Document" section. We are hoping that the draft stabilizes with this version. Please reply with any feedback. Thanks, JG James F. Gould Verisign =93This message (including any attachments) is intended only for the use of= the individual or entity to which it is addressed, and may contain informa= tion that is non-public, proprietary, privileged, confidential and exempt f= rom disclosure under applicable law or may be constituted as attorney work = product. If you are not the intended recipient, you are hereby notified tha= t any use, dissemination, distribution, or copying of this communication is= strictly prohibited. If you have received this message in error, notify se= nder immediately and delete this message immediately.=94 ________________________________ Please NOTE: This electronic message, including any attachments, may includ= e privileged, confidential and/or inside information owned by Demand Media,= Inc. Any distribution or use of this communication by anyone other than th= e intended recipient(s) is strictly prohibited and may be unlawful. If you = are not the intended recipient, please notify the sender by replying to thi= s message and then delete it from your system. Thank you. ________________________________ Please NOTE: This electronic message, including any attachments, may includ= e privileged, confidential and/or inside information owned by Demand Media,= Inc. Any distribution or use of this communication by anyone other than th= e intended recipient(s) is strictly prohibited and may be unlawful. If you = are not the intended recipient, please notify the sender by replying to thi= s message and then delete it from your system. Thank you. --_000_CDAD19404EF40jgouldverisigncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <3B671D3B72F21540B1AA9B5A849637C7@verisign.com> Content-Transfer-Encoding: quoted-printable
Ben,

My feedback is below.

<= font face=3D"Calibri" size=3D"3">-- 

<= font face=3D"Calibri" size=3D"3"> 

<= font face=3D"Calibri" size=3D"3">JG

<= font face=3D"Calibri" size=3D"3"> 

<= font face=3D"Calibri" size=3D"3">

<= font face=3D"Calibri" size=3D"3"> 

<= font face=3D"Calibri" size=3D"3">= James Gould

<= font face=3D"Calibri" size=3D"3">P= rincipal Software Engineer

<= font face=3D"Calibri" size=3D"3">jg= ould@verisign.com

<= font face=3D"Calibri" size=3D"3">&= nbsp;

<= font face=3D"Calibri" size=3D"3">7= 03-948-3271 (Office)

<= font face=3D"Calibri" size=3D"3">1= 2061 Bluemont Way

<= font face=3D"Calibri" size=3D"3">R= eston, VA 20190

<= span style=3D"color: rgb(13, 44, 118); ">= VerisignInc.com


From: Ben Levac <Benoit.Levac@demandmedia.com>
Date: Sunday, May 5, 2013 7:13 PM To: James Gould <jgould@verisign.com>, EPP Provreg <provreg@ietf.org>
Subject: RE: Launch Phase EPP Exten= sion Version 10

James,

 

Thank you for your answers.  = It certainly does clarifies what the vision behind some of the suggestions = in the document.

 

It seems that you are suggesting t= hat if the claims and landrush phases overlap, then the claims period is th= e principal phase?  Since ICANN is currently proposing the claims period for 90 days after sunrise, it is likely that l= andrush and claims will overlap for a lot of registries.  And what see= ms awkward to me is that we would be asking registrars to send the followin= g phase information for every single application even though (I assume) few of them will ever actually need to = pass actual claims notice information=85

 

<launch:phase name=3D=94landrus= h=94>claims</launch:phase>

Yes, this is the recommended phase for landrush during the claims peri= od.  There are many ways to handle this, but it was felt that leveragi= ng the existing support for phases and optional sub-phases for the overlapp= ing claims and landrush phases to be the cleanest and least impactful.  Passing the same values for the ph= ase independent of the need for a notice should be easier for the client as= well.  

 

Wouldn=92t it make more sense to a= sk them to provide the following, because to my previous comments on this t= opic in revision 08, I am most interested in validating their actual intention of submitting a landrush application = (as opposed to a general registration).

 

<launch:phase>landrush</l= aunch:phase>

As discussed earlier on the list a landrush could be setup with a firs= t-come-first-serve model in the case of a dutch auction, so there is no imp= lied expectation that the landrush phase will result in an application. &nb= sp;The draft supports the client passing the expected object to create with the optional "type" attribute= with the values of "application" or "registration". &n= bsp;The extension could include the following value for an overlapping land= rush during claims of applications.  My recommendation is not to requi= re the "type" attribute to be passed, but to simply validate it if = passed by the client against the type of object that will be created with t= he active server launch phase.

<launch:create xmlns:launch=3D"urn:ietf:params:xml:ns:launch-1= .0" 
    type=3D"application">
   <launch:phase name=3D"landrush">claims<= ;/launch:phase>
</launch:create>



 

From a validation perspective, I= =92m not sure I care to validate the fact that they passed in =93claims=94 = as a phase or sub-phase.  I do however, want to validate that they passed in valid claims notice information if the dom= ain is part of the DNL list.  And we would return an error message if = they did not.

 

What I would also want to avoid is= that if the landrush period does last longer than the claims period, to ha= ve different phase values for landrush applications.  For example:

 

1 - Applications submitted before = claim ends would have to return the following phase in the info response: &= lt;launch:phase name=3D=94landrush=94>claims</launch:phase>

2 =96 While applications submitted= after the claims period ends would have to return the following in the res= ponse: <launch:phase>landrush</launch:phase><= /p>

 

Because they are all landrush appl= ications, I would only ever want to have to return <launch:phase>land= rush</launch:phase> in the info response, especially since we never even return the claims information.

Yes, this is a corner case that would require you to split the landrus= h into separate phases: "claims" with "landrush" sub-ph= ase and "landrush".  You could consider extending the "= claims" phase to fully cover the "landrush" to forgo the spl= it.  I'm not sure if this is a likely use case considering the requirement for a 90 day= claims, but you have the option of having the landrush as a sub-phase of c= laims, split the phases, or start landrush after claims.   

 

I have a couple of questions about= the following statement:

 

JG>The draft does not specify that the applicatio= n ID's are unique, but I believe they should be.  The phase defines th= e context of the query and the application ID defines the specific applicat= ion without the phase; although I don't see why an application ID cannot be unique across phases. Outside sunrise, the= extension to the info command / response is focused on the application sta= tus.  

 

1 =96 What would the INFO response= return if a registrar passed in a phase and no application ID?  Would= we return a validation error?  If the domain was registered in that phase, I would expect the INFO to return a regular = INFO response.  If the domain created an application, I would expect t= he application ID to return information about it?

If an info command was sent without the application ID then that would= mean that the phase passed was for a none pending launch phase, so if the = launch phase was a non pending launch phase the server could return a succe= ssful info response.  In the case of sunrise, this could include the <launch:mark> information.  = A registration can have launch statuses as well, so the <launch:status&g= t; could be returned.  An info command referencing a launch phase that= was a pending launch phase without the application ID should result in an error.  

2 =96 If the INFO request did incl= ude the application ID, should we validate the phase to make sure that it m= atched the phase of the application?  Again, that could get complicated if the phase of the application in landr= ush used different values depending on overlapping periods.

Yes, the correct phase value should be passed to get the information f= or the application that was created in that phase.  This is one reason= that we included the recommendation to use <launch:phase name=3D"l= andrush">claims</launch:phase> as the phase for the likely combination of landrush and claims.  

 

Cheers,

 

Ben

 

From: Gould, James [mailto:JGould@verisign.com]
Sent: Friday, May 03, 2013 11:39 AM
To: Ben Levac; EPP Provreg (prov= reg@ietf.org)
Subject: Re: Launch Phase EPP Extension Version 10=

 

Ben,

 

My feedback is below.  To note, these = are suggestions on how I might go about it, but I'm sure there are other wa= ys to skin the cat.  

 

-= - <= o:p>

&= nbsp;

J= G

&= nbsp;

<= img width=3D"75" height=3D"66" id=3D"_x0000_i1025" src=3D"cid:image001.png@= 01CE4962.BE9520B0">

&= nbsp;

James Gould

Principal Software Engineer

jgould@verisign.com

 

703-948-3271 (Office)

12061 Bluemont Way

Reston, VA 20190

VerisignInc.com

 

From: Ben Levac <Benoit.Levac@demandmedia.com>
Date: Friday, May 3, 2013 11:46 AM
To: James Gould <jgould@ve= risign.com>, EPP Provreg <pro= vreg@ietf.org>
Subject: RE: Launch Phase EPP Extension Version 10=

 

James,

 

I do have some questions, specific= ally around how the proposed model handles simultaneous phases.

 

1 =96 The first question is around= the handling of overlapping claims and landrush (which will most likely be= the case for us).  If I understood section 2.2 of the requirement, a landrush application that was NOT subject to a c= laim would pass the launch:create extension with just the phase like this:<= /span>

 

<launch:create xmlns:launch=3D&= quot;urn:ietf:params:xml:ns:launch-1.0" type=3D"application"= >

     &nbs= p;          <launch:phase&g= t;landrush</launch:phase>

</launch:create>

 

 

The phase that is being passed should match= the phase that the server is activitly running, which is "claims"= ; with the sub-phase "landrush".  It would look like the following in General Create Form according to the overlap handlin= g defined in section 2.2 "Launch Phase":

 

<launch:create xmlns:launch=3D"urn:ietf:params:xml:= ns:launch-1.0" type=3D"application">

          = ;      <launch:phase name=3D"landrush"= ;>claims</launch:phase>

</launch:create>

 

 

While a landrush application that = WAS subject to a claims would pass the following extension:

 

<launch:create xmlns:launch=3D&= quot;urn:ietf:params:xml:ns:launch-1.0">

  <launch:phase name=3D=94= landrush=94>claims</launch:phase>

  <launch:notice>

  =85

  </launch:notice>

</launch:create>

 

COMMENT: This means that we can=92t judge the phase based only the value of the phase element, but we also have to b= ase it off the name which seems a bit awkward.

 

 

The phases would be exactly the same for th= is use case, except the notice would be included:

 

<launch:create xmlns:launch=3D"urn:ietf:params:xml:= ns:launch-1.0" type=3D"application"><= /p>

          = ;      <launch:phase name=3D"landrush"= ;>claims</launch:phase>

  

<launch:notice>

=85

</launch:notice>

</launch:create>

 

 

2 =96 In the case where we are run= ning a special custom =93sunrise 2=94 to restrict registration to a specifi= c group, it=92s not clear to me whether we should follow the proposed landrush from 2.2:<= o:p>

 

Without claim:

 

<launch:create xmlns:launch=3D&= quot;urn:ietf:params:xml:ns:launch-1.0" type=3D"application"= >

     &nbs= p;          <launch:phase n= ame=3D=94sunrise 2=94>custom</launch:phase>

</launch:create>

 

With claim:

 

<launch:create xmlns:launch=3D&= quot;urn:ietf:params:xml:ns:launch-1.0">

  <launch:phase name=3D=94= sunrise 2=94>claims</launch:phase>

  <launch:notice>

  =85

  </launch:notice>

</launch:create>

 

 

Does the "sunrise 2" overlap with the &quo= t;claims" phase and does it proceed the "landrush" phase? &n= bsp;If so, I would recommend always specifying "claims" as the ph= ase and "sunrise 2" or "landrush" as a sub-phase for bo= th the General Create Form and the Claims Create Form as in:

 

<launch:create xmlns:launch=3D"urn:ietf:params:xml:= ns:launch-1.0" type=3D"application">

          = ;      <launch:phase name=3D"sunrise 2&quo= t;>claims</launch:phase>

</launch:create>

 

<launch:create xmlns:launch=3D"urn:ietf:params:xml:= ns:launch-1.0" type=3D"application"><= /p>

          = ;      <launch:phase name=3D"landrush"= ;>claims</launch:phase>

  

<launch:notice>

=85

</launch:notice>

</launch:create>

 

 

Or= whether we should use a custom phase sort of as is proposed in section 3.3.4:

 

Without claim:

 

<launch:create xmlns:launch=3D&= quot;urn:ietf:params:xml:ns:launch-1.0" type=3D"application"= >

     &nbs= p;          <launch:phase n= ame=3D=94sunrise 2=94>custom</launch:phase>

</launch:create>

 

With claim:

 

<launch:create xmlns:launch=3D&= quot;urn:ietf:params:xml:ns:launch-1.0">

  <launch:phase name=3D=94= sunrise 2 - claims=94>custom</launch:phase>

  <launch:notice>

  =85

  </launch:notice>

</launch:create>

 

 

I do not believe there is the need for a custom phas= e.

 

3 =96 Finally there might be a sce= nario where we might want to run 2 concurrent custom phases.  Say that= there are some domains which will require mark data to be registered, even in a custom sunrise or landrush.  We= would expect a =93custom=94 phase with mark information to be passed. = ; But if this happens during a custom sunrise,  then I can=92t think o= f a good way to handle this, other than creating a hybrid custom phase, so you would use either:<= o:p>

 

<launch:phase name=3D=94special= =94>custom</launch:phase><= /o:p>

<launch:phase name=3D=94sunrise= 2 - special=94>custom</launch:phase>

 

I always view the server being in a single active ph= ase, where in this use case the active phase will require mark data for a s= ubset of the domains.  The phase value passed can be identical, where = it could be a single custom phase (e.g. <launch:phase name=3D"special">custom</launch:phase>= ), and the passing of the required mark data would be up to the client to p= ass based on I'm guessing a known set of domains that would require it. &nb= sp;The server would match the custom phase and would apply the server logic for the different groups of domains (requiring the mark data = or not).  If this phase overlaps with the "claims" phase, th= en the same use of a sub-phase would apply that was discussed in the prior = use cases.

 

 

4 =96 COMMENT: Given 1, 2 and 3, wouldn=92t it be better if we allowed som= eone to send multiple independent phases?  Different scenarios include= completely different launch:create extensions, one for each phase with the= data required for that phase.   Or just allowing multiple phase elements inside the single extension?  There = are other options that could be cleaner such as turning the launch:create i= nto a collection, but that would be a big schema change at this point in th= e game=85

 

 

I believe that you can accomplish this using a combi= nation of the phase and sub-phases with the option of passing the notice an= d the mark information.  The key is not to make it so custom that it w= ill make it too challenging for the client to now what to do.

 

5 =96 My next question is regardin= g the INFO command specified in 3.2:

 

If the application/registration wa= s created as part of a claim request, would the info response ever show the= claims information?  So for example, if I created a landrush domain that had a claim against it with what I ass= ume is the proposed method:

 

<launch:create xmlns:launch=3D&= quot;urn:ietf:params:xml:ns:launch-1.0">

  <launch:phase name=3D=94= landrush=94>claims</launch:phase>

  <launch:notice>

  =85

  </launch:notice>

</launch:create>

 

Then what INFO command extension p= hase information would the registrar have to send to get information back o= n this domain?  And what phase information would the server return to him in the response?

 

 

The phase of the info is based on the context of whe= n the application or registration was created.  The only applicable in= formation returned in the extension to the info response during the claims = phase is the application information (e.g. status).  The info response does not support the returning of the cla= ims information.   

 

6 =96 Is phase information really = required for INFO requests?  I assume that application IDs are unique = to the registry?  So if you pass it in, then we would return information regarding the application including the phase.=   Otherwise, we are infoing a registration.  In this case, I=92m = not sure why we would want to send in the extension?

 

 

The draft does not specify that the application ID's= are unique, but I believe they should be.  The phase defines the cont= ext of the query and the application ID defines the specific application wi= thout the phase; although I don't see why an application ID can not be unique across phases. Outside sunrise, the ex= tension to the info command / response is focused on the application status= .  

 

Sorry for the long list of questio= ns this late in the process, but I just want to make sure that we (and ever= yone on the list) have a clear understanding of the mechanisms, especially around concurrent phases which does tend to = get a bit more complicated.

 

Hopefully my suggestions help.  

 

 

Cheers,

 

Ben

 

From:provreg-bounces@ietf.org [mailto:provreg-bounces@ietf.o= rg] On Behalf Of Gould, James
Sent: Wednesday, May 01, 2013 5:33 AM
To: EPP Provreg (provreg@ietf.or= g)
Subject: [provreg] Launch Phase EPP Extension Version 10

 =

Wil Tan= , Gavin Brown and I have updated the Launch Phase EPP Extension

Mapping= to Version 10.  You can find the draft at the URL http://tools.i= etf.org/html/draft-tan-epp-launchphase-10.  This version

include= s the following changes:

 <= /span>

   1.  Chan=
ged noticeIDType from base64Binary to token to be compatible with
    &n=
bsp;  draft-lozano-tmch-func-spec-05.
   2.  Chan=
ged codeType from base64Binary to token to be more generic.
   3.  Upda=
ted based on feedback from Alexander Mayrhofer, which
    &n=
bsp;  include:

    &n=
bsp;  1.   Changed "extension to the domain name extens=
ion" to


    &n=
bsp;       "extension to the domain name=
 mapping".


    &n=
bsp;  2.   Changed use of 2004 return code to 2306 return co=
de when


    &n=
bsp;       phase passed mismatches active pha=
se and sub-phase.

    &n=
bsp;  3.   Changed description of "allocated" and =
"rejected" statuses.


    &n=
bsp;  4.   Moved sentence on a synchronous <domain:create=
> command


    &n=
bsp;       without the use of an intermediate=
 application, then an<=
/pre>

    &n=
bsp;       Application Identifier MAY not be =
needed to the Application


    &n=
bsp;       Identifier section.


    &n=
bsp;  5.   Restructured the Mark Validation Models section t=
o include


    &n=
bsp;       the "<launch:codeMark> =
element" sub-section, the "<mark:


    &n=
bsp;       mark> element" sub-section=
, and the Digital Signature sub-


    &n=
bsp;       section.


    &n=
bsp;  6.   Changed "Registries may" to "Regis=
tries MAY".


    &n=
bsp;  7.   Changed "extensed" to "extended&qu=
ot; in "Availability Check


    &n=
bsp;       Form" section.


    &n=
bsp;  8.   Broke the mix of create forms in the "EPP &l=
t;create> Command"


    &n=
bsp;       section to a fourth "Mixed Cr=
eate Form" with its own sub-


    &n=
bsp;       section.


    &n=
bsp;  9.   Removed "displayed or" from "displ=
ayed or accepted" in the=



    &n=
bsp;       <launch:acceptedDate> descri=
ption.


    &n=
bsp;  10.  Replaced "given domain name is supported" wi=
th "given domain<=
/pre>

    &n=
bsp;       name are supported" in the &q=
uot;Create Response" section.<=
/o:p>


    &n=
bsp;  11.  Changed the reference of 2303 (object does not exist) =
in the


    &n=
bsp;       "Security Considerations"=
; section to 2201 (authorization


    &n=
bsp;       error).


    &n=
bsp;  12.  Added arrow from "invalid" status to "p=
endingValidation"=



    &n=
bsp;       status and "pendingAllocation=
" status to "rejected" status


    &n=
bsp;       in the State Transition Diagram.


   4.  Adde=
d the "C:" and "S:" example prefixes and related text i=
n the


    &n=
bsp;  "Conventions Used in This Document" section.

 <= /span>

 

We are hoping that the draft stabilizes wit= h this version.  Please reply<= o:p>

with any feedback.

 

Thanks,<= o:p>

 

JG<= /o:p>

 

James F. Gould

Verisign=

 

 

 

 

=93This message (including any attachments) = is intended only for the use of the individual or entity to which it is add= ressed, and may contain information that is non-public, proprietary, privil= eged, confidential and exempt from disclosure under applicable law or may be constituted as attorney work product. If yo= u are not the intended recipient, you are hereby notified that any use, dis= semination, distribution, or copying of this communication is strictly proh= ibited. If you have received this message in error, notify sender immediately and delete this message immedi= ately.=94

 

Please NOTE: This electronic message, including= any attachments, may include privileged, confidential and/or inside inform= ation owned by Demand Media, Inc. Any distribution or use of this communication by anyone other than the intende= d recipient(s) is strictly prohibited and may be unlawful. If you are not t= he intended recipient, please notify the sender by replying to this message= and then delete it from your system. Thank you.


Please NOTE: This electronic= message, including any attachments, may include privileged, confidential a= nd/or inside information owned by Demand Media, Inc. Any distribution or us= e of this communication by anyone other than the intended recipient(s) is strictly prohibited and may be unlawful.= If you are not the intended recipient, please notify the sender by replyin= g to this message and then delete it from your system. Thank you.
 --_000_CDAD19404EF40jgouldverisigncom_-- --_005_CDAD19404EF40jgouldverisigncom_ Content-Type: image/png; name="8A7A655D-9ED0-4D38-898D-E9E8B754666E[129].png" Content-Description: 8A7A655D-9ED0-4D38-898D-E9E8B754666E[129].png Content-Disposition: inline; filename="8A7A655D-9ED0-4D38-898D-E9E8B754666E[129].png"; size=4109; creation-date="Mon, 06 May 2013 13:00:25 GMT"; modification-date="Mon, 06 May 2013 13:00:25 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAEkAAABACAIAAADZHs1DAAAP1ElEQVRoBe2aa3CU1RnHN3vLJtmQ hEtiwlUBtZUUCiU6tU7wVhinjOB0xmJnFIdpO1Y6DY586Iwdo36gLc4Iip3pVAL9IKjTDnhDEEWC 1GoICHLRctEkXHIPuZHr7qa/c553T152N9lsNvnWM5nDec97Ls//+T+X854lZWBgwDFuRRaXOiUl hX2kHrcNr1vYfd1T0g/ACIVCQV0CgQD/8miwOZ1Ol8vldrupKTyOK9QU2ThpUA4w9Pf39/X19fT0 UCsYYHA6QcLiYKCwF2MEMNh8Pp/X6/V4PAxOXoDoFcYAG7ICplsXNvClpSFvipAimGy1wQmrMgV4 aUzxekEbLV8yPUlhE66u6YJkqT6fMjKDyjRs2GgaeNKA587OTqZnZGSMLYejx4biEautrQ3eUlNT LUiCx6AyjWHhAbKrqwuEwMNQxYyTYUzmjhIbboMo7e3tyIwoMYA5nZ+duXiyur6ju88u5ZL5s+ff mJ+TmUan4JUGNVbQ2tqKNvx+PwTaZ42uPRpseBeoYMygUvRoijp7AnuPXdhz9PyeyvPI7khxqtoU yTcDofk35j1674LH7luY7U8zVsoo2qgMc5gwYQIeaOaNrpEwNoCBqraujgBALDeoOnr6X9t/4rX9 x9t7gg6Xx+F0K1QEQOBRFKoBVYdCjoGgI6T+MtO9j9+74Nlf3gNChhiQHR0dwMvKykoSXmLYMEUY u3T5MoyxMZEDbJTK81fWlR242NrrcHsdToBpSBZpsKeps0gDocYWDDhC6i8zzbO9ZOWKH38/Ah5K hL1kjDMBbMQMDKa6pgaE6enpggp4r+z5cvOeLx0en6bLpRkTbIKKWjGnijoCgQ3qdB3sdwR6FcJg 8NF7Crc99XNeG/ZQIvkQ3xt1bhgpNrYhlMFYY0NDVna2Bczp/MPrh3dVVjncAHOrvxSwuSw3U3SF SVPIxDKpBVuYQOABMtg3f+aUA39aY/fApqYmLB89CmBZY+T1SA8EcIWb1dfXk8QIaFIUsKM1Dk+a w+1xuLQ1Ag9s1p9uC9rBTk2sUoRLq8Ojp6cy/UR100MvvK41oPkdGMjJySF3svXI8dhHjggbSDhD ED8wSxgTYLsqLihgbsRCULBp3gghBobyN5AY33NalKoeuA2rgInYs1rHU37m4rq/vW/gsReZk63Z 0S70CNsjwiakNTU2etxuAXax5dpf3juuuBJgFiQtPdgUKv3n1DZpPdrawFPDwvBoW/C8L79bceD4 eQOPcELMHB118bHhab29vYq0UIhjvGB77p+VHeRk7MpCIn5lgobRrHY5noCnQgrD5JX5sJJOPZ0Y q/h3rdn0NpsaePgbAkiPWXckjfjfOJytMHrcmngltnGsqqmyqllZUYozK82z4MY8tZNYmtnT6T5+ saWtV1DpXuARRYLB4ltyVWw0hZRA4VDS1Xfiu3pe1TR3vLDz4B9XLSGEAIlw0tzcTJ1oPoiPDXto uXoVzfkzM/kyQ4y/f3JW0QVpig3H7vXLJfkqEW3l4OlLd/95n7JbU0KB4rkTDz6z3HTYGyVlH5+o alTjQ6FtHx575hfFvAUeXodaESNRbHFsErWRQxsaGpRBpqRQX2ru/LKmRScxZZBtnd0lr31oF9G0 l9w2rfjmXJWppdDo79n+xL1mgL1RVd+6+f1jWmUq9dc0tb/z+TfsTmEYB2jEkLZ91vDtONgwQhgj ZavPaf1N/enZegUM3uTP7f3Hga8OnqyKuc323xQ7OH9ICQaefWjRrCkTYo5c/fK7yshlTXVkc739 +RlGanQDREvEEI+IOT1mZxxsBH0WlfO+uioIhQ6dbdSuhffrUI5Aqf7SNz6NuTpInl2xQHlXKJDl CZU8sCDmsN1fnC0/16wCiVqTU6jS3cGvqoUoakk87B9z+lCdcbChKoAJY7SBV9PUobMTE3VwQ9Me X/nXtds/Ph5zj5JlhVk+J2erTY/+JDvDF3tM2ceaNI41kjzw5BTMsrWzx8DD8caBt76+YEDZlaYt 1N4bUqo1fyBE39700rf+09rZHS16dkbqplWL5xf4Vy9Rp+HoUvrG4eo2/emgzmgUWVzBO/Fdrdgk vZjlGPPG0nClCVP1uXpIE6qtPKVBOtF6dUv3pt2faeEiK1Bt/+39kb36ufVaz6YPz6jEDf+WvvQL Mor+WhVsSozwfVnMdWJ2DpcDZF0MElj9+kKuvZuERdEJ16p1B/nAk/bcv46svn/RrLxs3XVdBaUp KzYoR7UX1IS7qg+I62+BLALVUGSQGQbkyM/N129m31jnFukQ3kBoey9bWhuTudWXmze9ZOsQ+aBw 1oN3znOkZTsyJg3+pecQh3QCDFvB4AaqR1NlgZI3IwfG+OGwqdda0xg6qRPjnJGdqveIAKb7OBx6 fG8frR4qH2xaXZzl12diuDJ/KjbiYNevqriytGboMsLooSOq4mBDT1wbWLwFgz5sx3xZyh1B2GaU fDqolJR9FHNn8kHJT2+77rRlH6ew8EUnqHRjYGD65Ex1Ka0Lyk2INJaLg43DzqRJk8BG4WQAgd/L y9ASKFfQsoWl4UH7z4lL7cPkg5k5sdKAAFPLWahYnNuU6ZMnWDFkYEBpOcIt9fbDVHGwyRcUVyNg 6+ntxeVmT0pVx6jBb2cjjd6FtOtJKyk7MFQ+KF35Qz6xBwViHWV++m9wzRD03nXrVIs09tZxUhxk cG68VhxsqIrEkpOdDWPwxi43TUzVt1TcC+g/uyHRxnncqW39rtK3hsgHxbfOn04g1WFJARNcRkE0 9LKh4AOL5hjSerq7EWOMecMSIC0/Px9UwOMzceE0/+QMtyUBcqg7Of5EOK1Jwo/Ht/m9So6/0Zol oVXVNmueBJidNFmKNdVF2LKFsxVvmjTUihhj7G8GG1KyC2dLEN4xw69ub7QEgyAlDIgT6qCijr9R pfTNf7f1Ch4YE1O0kabW5Nqr/+E7b8HfLN50Khh7bMjGVSQ2mX/DDRBHsEKFS+dOSHMNqAO+OgSL 74VVrkxUZUYss/ybuoh8UNXYvnnfaXUNQRkExly9iFpKX10G+p56sMgAQ6EYJGJEKSpORxx/YzZW zlf9DwoL+aUQeHyDp7oGfnW7/nYWNataY6OWBtN0UFm95QP7/qu37FUpnnAKfqWFsEbURI0KfQFs +aJpE/3GIFEoAiTqbEoE+95DtbGHvLy8adOmCTwunublehfc4NWWGWZPtG6FUO1Lbm91c9emdypk WT7DYVJhpoijGkiWjrilDMzLz/j9zxYpLwt7mvwEOZRsw/SPCBs649ejosWLyePA69W/jD6+aNL0 TKe+NhV42j5F/cKeTnelbx6WfKDcT04h8lZpQXOlv+5knUxP8K+/vl9QCTyiCVuPgjQwu0pLS4eB Lq+IKOQWNiDF1dXVYVB89fi8njtmZp6u62rvjfpk5IwiQcXh6O3rr2u6WtXQ/mZFtcKmStjBFHth eMFApjuwY+19N+XlMEIdwrjCCAYzMzPBlmhmU5uwAIqRVtyaKNLS0rJv//5Lly6xGT/iZPj9AYfr xU8bLnaElNzqRkDukuUTUx8TddxT0UUNIHnoqIizKfYEWBBVwdi2J+6bN30SK8tPKMjD3dbEiRPx iLiyxRyQADa0QH6rra19b88efkayw3v3m7aPLnQp0YmB6kssjA1IFKU+/cVptXUUUf7JlZ6y5x/N yN782J1ZGT4FTBcuDjP9fo57OFuiac3gTAAbc/ABAsmV2toP9u418Pgxghh9rrlv29Hmpi5NINjI 4NQUqa0NNWkqPMIbpAVmZPseL5774KJZYVBwlkLQz87Kys3NhTf6ramJ/5MYNtYHHj/ocM1sh+f2 eOTHpM8vdh3+ruPrhm7NXvhT2vqGYbZgA1VozpSMh4tmLl84w6CiweJYfu4UVYj7yQBjs4SxCTzY u3r16ifl5TU1NUigfkB1uVAzJkTIaekOfl3f9d/G3sbOvsZr/U3X1HVLps81c2J6flba3Dz/XTfn FWSnMYW5jBcM5DHaBfn5+FiSjLEdZTTYmCYK5grs9JkzlZWVJAaBh5QKIeda/R9nlNxadgEgtYUG VBqZOqeyXCgEpKkFBfJLt6DVEo6+GiU2NiS04PHYZ0Nj4+lTp85duECXoYIjEgg9/LcfQBqcNpaY TgEXMPhpG1Rgww6ZOOrgEaGG0WOThYRAEDa3tJw/f/7Ct98SCTQfihXT4AGcBApmCXtkTMATCfNy c/kNEVTEesZHyJfMY7LYZG/Uj7eQIQBZ39DAz6tkQvXY3W2HRxuLJeqo+D55MkdwIOGi/IgB4GRg xJw7NthkaTgUkPK5QI3R0kM/AwQkJgcSKKKmCIcxJUu+cyyxGWnEl4BEkTav8CIKCCnSNuPHqTEu 2MZJ1kSXHUvfTXTv8R7/f2zjreHxWT/hS4hkxLhy5QqHNVaYOnUqoX/4pS5wGNCFnE4CHH5wzLfu jS++eOXyZd5t2LBB9tu9e3d5eTk9a9as2bp1a/S0tWvXzp49+9VXXyVZ298iRFFR0dKlS+k0b196 6SUeQcVSJD0znpErV65kRzBs2bKF/mXLlsncYQYzbN26ddQFU6euf/ppGma6SLVz586TJ0/Sj/DO 24uKaFGki8Y5LTFJdt68efrNSCtE37t376lTp6InRABjQEVFxfPPP09+jxgMMKCKFpCBIoNf0fjN YPg4dOiQeTQNVIZRiHW4CwsLd+3axTtIWLx4Mad7oZF+M2HOnDlPPvmkeYxoGGY2btzIK4SOUAqq FVmLi4tXrFgBHlTAMFQbbZm8EskeeeQR5GFBoYKLtoh9GQmSiE4MyojqxpThFzzwtmrVKmNmdmxI tm/fPrOKWI55lAYGKQ2RLOKtPLIFPKBXZALkUGPoRyQBRhupMNdol2MjWImGZ5ZVsQSzZBBDsQex TCSw616MzcyJwIZr8UqYoQHJZqQ00KWoz74OW+BvBkDEFGEJecSm5C3jCwoKpM10BIZ8NBUx1zwq bMYsASa82UljgCjbzIloGKrpR4sYXsQAHn+3di0mhCeLwdODZDt27IjYyEzkrYyxLy6dMoaNkNau LDPXNBQ2Y5Zsb2aaETTQjTFie7+0MZivTp4UoQEW7UIyTJyNNmywkRjIZR2i7WsKIbzFaNmX6McY O3syWGgnRNkB29ehbZ1LltiUjedgRfZxfKoQD0xBOPtbTPShlSulJ1oI+omchEQizZEjR4hV9PCx J+ONl8ojtTAJIWVlZYL8iwrrZtqMkQZeE23/9jGKN4rdNuxteQsnkoLkMTpsogtmiUmDxO6rTEG1 ol2MUFaQGrvCZIyjSidWwDqMp6bYx0e3iaVoLbpfeixsGBI2I3qyR56YihH3jXBiHF0AIBDY7G8J GPDDecDIyiO7SEzCumQX4RC069evh38ZzFsEE6+jjdARg9GF/a0d5/8ActOtScHpPCkAAAAASUVO RK5CYII= --_005_CDAD19404EF40jgouldverisigncom_-- --_006_CDAD19404EF40jgouldverisigncom_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: attachment; filename="image001.png"; size=4109; creation-date="Mon, 06 May 2013 13:00:25 GMT"; modification-date="Mon, 06 May 2013 13:00:25 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAEkAAABACAIAAADZHs1DAAAP1ElEQVRoBe2aa3CU1RnHN3vLJtmQ hEtiwlUBtZUUCiU6tU7wVhinjOB0xmJnFIdpO1Y6DY586Iwdo36gLc4Iip3pVAL9IKjTDnhDEEWC 1GoICHLRctEkXHIPuZHr7qa/c553T152N9lsNvnWM5nDec97Ls//+T+X854lZWBgwDFuRRaXOiUl hX2kHrcNr1vYfd1T0g/ACIVCQV0CgQD/8miwOZ1Ol8vldrupKTyOK9QU2ThpUA4w9Pf39/X19fT0 UCsYYHA6QcLiYKCwF2MEMNh8Pp/X6/V4PAxOXoDoFcYAG7ICplsXNvClpSFvipAimGy1wQmrMgV4 aUzxekEbLV8yPUlhE66u6YJkqT6fMjKDyjRs2GgaeNKA587OTqZnZGSMLYejx4biEautrQ3eUlNT LUiCx6AyjWHhAbKrqwuEwMNQxYyTYUzmjhIbboMo7e3tyIwoMYA5nZ+duXiyur6ju88u5ZL5s+ff mJ+TmUan4JUGNVbQ2tqKNvx+PwTaZ42uPRpseBeoYMygUvRoijp7AnuPXdhz9PyeyvPI7khxqtoU yTcDofk35j1674LH7luY7U8zVsoo2qgMc5gwYQIeaOaNrpEwNoCBqraujgBALDeoOnr6X9t/4rX9 x9t7gg6Xx+F0K1QEQOBRFKoBVYdCjoGgI6T+MtO9j9+74Nlf3gNChhiQHR0dwMvKykoSXmLYMEUY u3T5MoyxMZEDbJTK81fWlR242NrrcHsdToBpSBZpsKeps0gDocYWDDhC6i8zzbO9ZOWKH38/Ah5K hL1kjDMBbMQMDKa6pgaE6enpggp4r+z5cvOeLx0en6bLpRkTbIKKWjGnijoCgQ3qdB3sdwR6FcJg 8NF7Crc99XNeG/ZQIvkQ3xt1bhgpNrYhlMFYY0NDVna2Bczp/MPrh3dVVjncAHOrvxSwuSw3U3SF SVPIxDKpBVuYQOABMtg3f+aUA39aY/fApqYmLB89CmBZY+T1SA8EcIWb1dfXk8QIaFIUsKM1Dk+a w+1xuLQ1Ag9s1p9uC9rBTk2sUoRLq8Ojp6cy/UR100MvvK41oPkdGMjJySF3svXI8dhHjggbSDhD ED8wSxgTYLsqLihgbsRCULBp3gghBobyN5AY33NalKoeuA2rgInYs1rHU37m4rq/vW/gsReZk63Z 0S70CNsjwiakNTU2etxuAXax5dpf3juuuBJgFiQtPdgUKv3n1DZpPdrawFPDwvBoW/C8L79bceD4 eQOPcELMHB118bHhab29vYq0UIhjvGB77p+VHeRk7MpCIn5lgobRrHY5noCnQgrD5JX5sJJOPZ0Y q/h3rdn0NpsaePgbAkiPWXckjfjfOJytMHrcmngltnGsqqmyqllZUYozK82z4MY8tZNYmtnT6T5+ saWtV1DpXuARRYLB4ltyVWw0hZRA4VDS1Xfiu3pe1TR3vLDz4B9XLSGEAIlw0tzcTJ1oPoiPDXto uXoVzfkzM/kyQ4y/f3JW0QVpig3H7vXLJfkqEW3l4OlLd/95n7JbU0KB4rkTDz6z3HTYGyVlH5+o alTjQ6FtHx575hfFvAUeXodaESNRbHFsErWRQxsaGpRBpqRQX2ru/LKmRScxZZBtnd0lr31oF9G0 l9w2rfjmXJWppdDo79n+xL1mgL1RVd+6+f1jWmUq9dc0tb/z+TfsTmEYB2jEkLZ91vDtONgwQhgj ZavPaf1N/enZegUM3uTP7f3Hga8OnqyKuc323xQ7OH9ICQaefWjRrCkTYo5c/fK7yshlTXVkc739 +RlGanQDREvEEI+IOT1mZxxsBH0WlfO+uioIhQ6dbdSuhffrUI5Aqf7SNz6NuTpInl2xQHlXKJDl CZU8sCDmsN1fnC0/16wCiVqTU6jS3cGvqoUoakk87B9z+lCdcbChKoAJY7SBV9PUobMTE3VwQ9Me X/nXtds/Ph5zj5JlhVk+J2erTY/+JDvDF3tM2ceaNI41kjzw5BTMsrWzx8DD8caBt76+YEDZlaYt 1N4bUqo1fyBE39700rf+09rZHS16dkbqplWL5xf4Vy9Rp+HoUvrG4eo2/emgzmgUWVzBO/Fdrdgk vZjlGPPG0nClCVP1uXpIE6qtPKVBOtF6dUv3pt2faeEiK1Bt/+39kb36ufVaz6YPz6jEDf+WvvQL Mor+WhVsSozwfVnMdWJ2DpcDZF0MElj9+kKuvZuERdEJ16p1B/nAk/bcv46svn/RrLxs3XVdBaUp KzYoR7UX1IS7qg+I62+BLALVUGSQGQbkyM/N129m31jnFukQ3kBoey9bWhuTudWXmze9ZOsQ+aBw 1oN3znOkZTsyJg3+pecQh3QCDFvB4AaqR1NlgZI3IwfG+OGwqdda0xg6qRPjnJGdqveIAKb7OBx6 fG8frR4qH2xaXZzl12diuDJ/KjbiYNevqriytGboMsLooSOq4mBDT1wbWLwFgz5sx3xZyh1B2GaU fDqolJR9FHNn8kHJT2+77rRlH6ew8EUnqHRjYGD65Ex1Ka0Lyk2INJaLg43DzqRJk8BG4WQAgd/L y9ASKFfQsoWl4UH7z4lL7cPkg5k5sdKAAFPLWahYnNuU6ZMnWDFkYEBpOcIt9fbDVHGwyRcUVyNg 6+ntxeVmT0pVx6jBb2cjjd6FtOtJKyk7MFQ+KF35Qz6xBwViHWV++m9wzRD03nXrVIs09tZxUhxk cG68VhxsqIrEkpOdDWPwxi43TUzVt1TcC+g/uyHRxnncqW39rtK3hsgHxbfOn04g1WFJARNcRkE0 9LKh4AOL5hjSerq7EWOMecMSIC0/Px9UwOMzceE0/+QMtyUBcqg7Of5EOK1Jwo/Ht/m9So6/0Zol oVXVNmueBJidNFmKNdVF2LKFsxVvmjTUihhj7G8GG1KyC2dLEN4xw69ub7QEgyAlDIgT6qCijr9R pfTNf7f1Ch4YE1O0kabW5Nqr/+E7b8HfLN50Khh7bMjGVSQ2mX/DDRBHsEKFS+dOSHMNqAO+OgSL 74VVrkxUZUYss/ybuoh8UNXYvnnfaXUNQRkExly9iFpKX10G+p56sMgAQ6EYJGJEKSpORxx/YzZW zlf9DwoL+aUQeHyDp7oGfnW7/nYWNataY6OWBtN0UFm95QP7/qu37FUpnnAKfqWFsEbURI0KfQFs +aJpE/3GIFEoAiTqbEoE+95DtbGHvLy8adOmCTwunublehfc4NWWGWZPtG6FUO1Lbm91c9emdypk WT7DYVJhpoijGkiWjrilDMzLz/j9zxYpLwt7mvwEOZRsw/SPCBs649ejosWLyePA69W/jD6+aNL0 TKe+NhV42j5F/cKeTnelbx6WfKDcT04h8lZpQXOlv+5knUxP8K+/vl9QCTyiCVuPgjQwu0pLS4eB Lq+IKOQWNiDF1dXVYVB89fi8njtmZp6u62rvjfpk5IwiQcXh6O3rr2u6WtXQ/mZFtcKmStjBFHth eMFApjuwY+19N+XlMEIdwrjCCAYzMzPBlmhmU5uwAIqRVtyaKNLS0rJv//5Lly6xGT/iZPj9AYfr xU8bLnaElNzqRkDukuUTUx8TddxT0UUNIHnoqIizKfYEWBBVwdi2J+6bN30SK8tPKMjD3dbEiRPx iLiyxRyQADa0QH6rra19b88efkayw3v3m7aPLnQp0YmB6kssjA1IFKU+/cVptXUUUf7JlZ6y5x/N yN782J1ZGT4FTBcuDjP9fo57OFuiac3gTAAbc/ABAsmV2toP9u418Pgxghh9rrlv29Hmpi5NINjI 4NQUqa0NNWkqPMIbpAVmZPseL5774KJZYVBwlkLQz87Kys3NhTf6ramJ/5MYNtYHHj/ocM1sh+f2 eOTHpM8vdh3+ruPrhm7NXvhT2vqGYbZgA1VozpSMh4tmLl84w6CiweJYfu4UVYj7yQBjs4SxCTzY u3r16ifl5TU1NUigfkB1uVAzJkTIaekOfl3f9d/G3sbOvsZr/U3X1HVLps81c2J6flba3Dz/XTfn FWSnMYW5jBcM5DHaBfn5+FiSjLEdZTTYmCYK5grs9JkzlZWVJAaBh5QKIeda/R9nlNxadgEgtYUG VBqZOqeyXCgEpKkFBfJLt6DVEo6+GiU2NiS04PHYZ0Nj4+lTp85duECXoYIjEgg9/LcfQBqcNpaY TgEXMPhpG1Rgww6ZOOrgEaGG0WOThYRAEDa3tJw/f/7Ct98SCTQfihXT4AGcBApmCXtkTMATCfNy c/kNEVTEesZHyJfMY7LYZG/Uj7eQIQBZ39DAz6tkQvXY3W2HRxuLJeqo+D55MkdwIOGi/IgB4GRg xJw7NthkaTgUkPK5QI3R0kM/AwQkJgcSKKKmCIcxJUu+cyyxGWnEl4BEkTav8CIKCCnSNuPHqTEu 2MZJ1kSXHUvfTXTv8R7/f2zjreHxWT/hS4hkxLhy5QqHNVaYOnUqoX/4pS5wGNCFnE4CHH5wzLfu jS++eOXyZd5t2LBB9tu9e3d5eTk9a9as2bp1a/S0tWvXzp49+9VXXyVZ298iRFFR0dKlS+k0b196 6SUeQcVSJD0znpErV65kRzBs2bKF/mXLlsncYQYzbN26ddQFU6euf/ppGma6SLVz586TJ0/Sj/DO 24uKaFGki8Y5LTFJdt68efrNSCtE37t376lTp6InRABjQEVFxfPPP09+jxgMMKCKFpCBIoNf0fjN YPg4dOiQeTQNVIZRiHW4CwsLd+3axTtIWLx4Mad7oZF+M2HOnDlPPvmkeYxoGGY2btzIK4SOUAqq FVmLi4tXrFgBHlTAMFQbbZm8EskeeeQR5GFBoYKLtoh9GQmSiE4MyojqxpThFzzwtmrVKmNmdmxI tm/fPrOKWI55lAYGKQ2RLOKtPLIFPKBXZALkUGPoRyQBRhupMNdol2MjWImGZ5ZVsQSzZBBDsQex TCSw616MzcyJwIZr8UqYoQHJZqQ00KWoz74OW+BvBkDEFGEJecSm5C3jCwoKpM10BIZ8NBUx1zwq bMYsASa82UljgCjbzIloGKrpR4sYXsQAHn+3di0mhCeLwdODZDt27IjYyEzkrYyxLy6dMoaNkNau LDPXNBQ2Y5Zsb2aaETTQjTFie7+0MZivTp4UoQEW7UIyTJyNNmywkRjIZR2i7WsKIbzFaNmX6McY O3syWGgnRNkB29ehbZ1LltiUjedgRfZxfKoQD0xBOPtbTPShlSulJ1oI+omchEQizZEjR4hV9PCx J+ONl8ojtTAJIWVlZYL8iwrrZtqMkQZeE23/9jGKN4rdNuxteQsnkoLkMTpsogtmiUmDxO6rTEG1 ol2MUFaQGrvCZIyjSidWwDqMp6bYx0e3iaVoLbpfeixsGBI2I3qyR56YihH3jXBiHF0AIBDY7G8J GPDDecDIyiO7SEzCumQX4RC069evh38ZzFsEE6+jjdARg9GF/a0d5/8ActOtScHpPCkAAAAASUVO RK5CYII= --_006_CDAD19404EF40jgouldverisigncom_-- From fobispo@isc.org Mon May 6 12:19:20 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA86721F87CD for ; Mon, 6 May 2013 12:19:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id czed5dR0U841 for ; Mon, 6 May 2013 12:19:20 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 2C97921F894E for ; Mon, 6 May 2013 12:19:17 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 99D7E5F98C5 for ; Mon, 6 May 2013 19:19:07 +0000 (UTC) (envelope-from fobispo@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1367867956; bh=FYEwWjnHmp41xkP5OvWXJkqx4gRLhg1DlE1exjCVR3I=; h=From:Subject:Date:References:To; b=dRSKnic+7OHXtt6OqRpofvP5ZpFMzormPQva0yaL2ESF65GpnYdhVHUfE8YDcyB86 6/omGfBE5uGi6ULxlIJIS7V4r5f7bvEFaEjflaCRt6N1z2EeViHF7RaW+UHSud6mwN NUQVVtTCabPH8lGvonTckL8AauA305798G3OS7kw= Received: from [IPv6:2001:4f8:3:64:1d0f:e11d:b719:4f80] (unknown [IPv6:2001:4f8:3:64:1d0f:e11d:b719:4f80]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 30C67216C43 for ; Mon, 6 May 2013 19:19:06 +0000 (UTC) (envelope-from fobispo@isc.org) From: Francisco Obispo Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 6 May 2013 12:19:05 -0700 References: <20130506191809.8585.25818.idtracker@ietfa.amsl.com> To: "provreg@ietf.org" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) Subject: [provreg] New Version Notification for draft-obispo-epp-idn-03.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2013 19:19:21 -0000 Just updated the draft to the latest comments/suggestions. Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for draft-obispo-epp-idn-03.txt > Date: May 6, 2013 12:18:09 PM PDT > To: Luis Enri Munoz , Francisco Obispo , = Luis Enrique Munoz >=20 >=20 > A new version of I-D, draft-obispo-epp-idn-03.txt > has been successfully submitted by Francisco Obispo and posted to the > IETF repository. >=20 > Filename: draft-obispo-epp-idn > Revision: 03 > Title: Internationalized Domain Name Mapping Extension = for the Extensible Provisioning Protocol (EPP) > Creation date: 2013-05-06 > Group: Individual Submission > Number of pages: 5 > URL: = http://www.ietf.org/internet-drafts/draft-obispo-epp-idn-03.txt > Status: http://datatracker.ietf.org/doc/draft-obispo-epp-idn > Htmlized: http://tools.ietf.org/html/draft-obispo-epp-idn-03 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-obispo-epp-idn-03 >=20 > Abstract: > This document describes an Extensible Provisioning Protocol (EPP) > extension mapping for the provisioning of Internationalized Domain > Names (IDN) stored in a shared central repository. This mapping > extends the EPP domain name mapping to provide additional features > required to implement registrations of domain names in characters > sets other than ASCII. >=20 >=20 >=20 >=20 > The IETF Secretariat Francisco Obispo=20 Director of Applications and Services - ISC email: fobispo@isc.org Phone: +1 650 423 1374 || INOC-DBA *3557* NOC PGP KeyID =3D B38DB1BE From sasha@dnservices.co.za Mon May 6 23:23:46 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 628CF21F8F17 for ; Mon, 6 May 2013 23:23:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u9qm-DrKhKp0 for ; Mon, 6 May 2013 23:23:46 -0700 (PDT) Received: from relay.dnservices.co.za (relay.dnservices.co.za [160.124.24.10]) by ietfa.amsl.com (Postfix) with ESMTP id E2F7221F8630 for ; Mon, 6 May 2013 23:23:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=simple/simple; d=dnservices.co.za; s=mail; h=Mime-Version:To:Date:Message-Id:Subject:Content-Transfer-Encoding:Content-Type:From; bh=ipJOVUlM0LkOhVaCibfzN3sTphD+Xuha/E/WZE8tMUU=; b=iWv/eJCT8cBp1rFMjARN/nbxKVWcxWROMG1UWQKYTehzoo85jVkjeIcGDZOZRA44AeT8Ib1lbpyLTEG5NPlpFwbb24VFxsWpks4dhFG+UyUpt+2lXOOwD+nKv8WLTMBkRDhqQsIDJO2YaJDFaiPVBKtbWijW0loysLJkiVmOInA=; Received: from cache.coza.net.za ([206.223.136.211] helo=[192.168.0.141]) by relay.dnservices.co.za with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1UZbJF-0002Zg-4Z for provreg@ietf.org; Tue, 07 May 2013 08:23:33 +0200 From: Vlad Dinculescu Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Tue, 7 May 2013 08:23:37 +0200 To: "provreg@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [provreg] Implementation of EPP AuthInfo X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 06:24:30 -0000 All, Please share your thoughts regarding the implementation of the Contact = AuthInfo for the approval of initiated contact updates. Our current process looks to have the registrant provide the code as an = indication of approval regarding the update of their information, = completing the update instantly. Updates that are not provided with the = code will not execute. Further to this, we are looking to implement the Domain AuthInfo code as = a definite measure for approving registrant changes to a linked domain. = In this instance the current registrant must provide the Domain AuthInfo = code as approval of the registrant change. Regards, Vlad Dinculescu -------------------------------- Domain Name Services= From fobispo@isc.org Mon May 6 23:33:29 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A11621F8C1A for ; Mon, 6 May 2013 23:33:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[AWL=1.299, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5LSUvJedEPk3 for ; Mon, 6 May 2013 23:33:27 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id C003B21F8E49 for ; Mon, 6 May 2013 23:33:26 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id A9716C941E; Tue, 7 May 2013 06:33:18 +0000 (UTC) (envelope-from fobispo@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1367908406; bh=pjI/svA5fxB6IZk1ToYxGceROW2KiMmWwe96KqZKwp4=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=f27BBiTAW0KKdmSqhHNYahEjfyVFUCy2GT4zjCbWUEk6/N1s3bERLDg0NTVOIzqQd E+NynTftaRC0UEUgU7VtpVpO4MoH111vUTI35vSgjWZTPehPo5MiUpFbtsq4zPJMZe 9qiY3XXMWKfS9UgJ6/7EPmZGGCC8bY9Y69uCRA9Y= Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS; Tue, 7 May 2013 06:33:18 +0000 (UTC) (envelope-from fobispo@isc.org) Received: from [192.168.255.120] (c-24-7-39-79.hsd1.ca.comcast.net [24.7.39.79]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 91BD7216C40; Tue, 7 May 2013 06:33:18 +0000 (UTC) (envelope-from fobispo@isc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Francisco Obispo In-Reply-To: Date: Mon, 6 May 2013 23:33:18 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Vlad Dinculescu X-Mailer: Apple Mail (2.1503) X-DCC--Metrics: post.isc.org; whitelist Cc: "provreg@ietf.org" Subject: Re: [provreg] Implementation of EPP AuthInfo X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 06:33:29 -0000 Hi Vlad, What are the problems you're trying to address with these measures? Some thoughts below: On May 6, 2013, at 11:23 PM, Vlad Dinculescu = wrote: > All, >=20 > Please share your thoughts regarding the implementation of the Contact = AuthInfo for the approval of initiated contact updates. >=20 > Our current process looks to have the registrant provide the code as = an indication of approval regarding the update of their information, = completing the update instantly. Updates that are not provided with the = code will not execute. >=20 Do you want to accept an update from a non-sponsoring registrar? If that's not the case, the AuthInfo will be available to the sponsoring = registrar anyway. > Further to this, we are looking to implement the Domain AuthInfo code = as a definite measure for approving registrant changes to a linked = domain. In this instance the current registrant must provide the Domain = AuthInfo code as approval of the registrant change. >=20 Same as above, but in addition, a contact object can be independently = updated regardless if its used in a domain name or not, so the = restriction will only have effect if you 'replace' the registrant with = other ID, but not if you change the contact underlying data. > Regards, > Vlad Dinculescu > -------------------------------- > Domain Name Services > _______________________________________________ > provreg mailing list > provreg@ietf.org > https://www.ietf.org/mailman/listinfo/provreg Francisco Obispo=20 Director of Applications and Services - ISC email: fobispo@isc.org Phone: +1 650 423 1374 || INOC-DBA *3557* NOC PGP KeyID =3D B38DB1BE From sasha@dnservices.co.za Mon May 6 23:52:17 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA02221F8521 for ; Mon, 6 May 2013 23:52:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jqa-zGLftI8j for ; Mon, 6 May 2013 23:52:11 -0700 (PDT) Received: from relay.dnservices.co.za (relay.dnservices.co.za [160.124.24.10]) by ietfa.amsl.com (Postfix) with ESMTP id 15D5C21F8F25 for ; Mon, 6 May 2013 23:52:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=simple/simple; d=dnservices.co.za; s=mail; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=7VtkQfv7UuCtjMSaShUITifAdQVxCQ3jeTfyRMT5bwc=; b=FZyIwGyOL1IrdC444hOXZflYWgpdZJzP1LkyEwiu3knh/TY6Ie1yUe/AMC/EPTfqA0eKqp+pps2Gm214zHcTapSy943Bzoiq+pXKZFEJhLM6//AXNTQnsMr0GZtnWyd+hfI16kgJjOeO87sz7TCYYTqEDy7M7dHyWunQtiKDNyM=; Received: from cache.coza.net.za ([206.223.136.211] helo=[192.168.0.141]) by relay.dnservices.co.za with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1UZbkb-0002aw-Gc; Tue, 07 May 2013 08:51:49 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Vlad Dinculescu In-Reply-To: Date: Tue, 7 May 2013 08:51:55 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Francisco Obispo X-Mailer: Apple Mail (2.1499) Cc: "provreg@ietf.org" Subject: Re: [provreg] Implementation of EPP AuthInfo X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 06:52:17 -0000 Hi Francisco, Thanks for the reply, please see responses inline below. On 07 May 2013, at 8:33 AM, Francisco Obispo wrote: > Hi Vlad, >=20 > What are the problems you're trying to address with these measures? Simply put, we are attempting to avoid registrars performing updates on = Contact information that are not authorised or requested by the Contact. We have found that "bringing out the big stick" doesn't work = effectively, so now we are attempting to put the decision making where = it belongs, in the hands of the registrant. >=20 > Some thoughts below: >=20 >=20 > On May 6, 2013, at 11:23 PM, Vlad Dinculescu = wrote: >=20 >> All, >>=20 >> Please share your thoughts regarding the implementation of the = Contact AuthInfo for the approval of initiated contact updates. >>=20 >> Our current process looks to have the registrant provide the code as = an indication of approval regarding the update of their information, = completing the update instantly. Updates that are not provided with the = code will not execute. >>=20 >=20 > Do you want to accept an update from a non-sponsoring registrar? >=20 > If that's not the case, the AuthInfo will be available to the = sponsoring registrar anyway. We did identify this issue as well, knowing that the sponsoring = registrar would have access to the code.=20 Does an implementation exist where the AuthInfo is used as an = out-of-band means of authorisation from the registrant. >=20 >> Further to this, we are looking to implement the Domain AuthInfo code = as a definite measure for approving registrant changes to a linked = domain. In this instance the current registrant must provide the Domain = AuthInfo code as approval of the registrant change. >>=20 >=20 >=20 > Same as above, but in addition, a contact object can be independently = updated regardless if its used in a domain name or not, so the = restriction will only have effect if you 'replace' the registrant with = other ID, but not if you change the contact underlying data. >=20 In this instance we are looking at the replacement of the associated = domain registrant ID with a different one. This is a domain update where = the current registrant can use the associated domain AuthInfo to approve = the change of the registrant ID to a different one. >=20 >> Regards, >> Vlad Dinculescu >> -------------------------------- >> Domain Name Services >> _______________________________________________ >> provreg mailing list >> provreg@ietf.org >> https://www.ietf.org/mailman/listinfo/provreg >=20 > Francisco Obispo=20 > Director of Applications and Services - ISC > email: fobispo@isc.org > Phone: +1 650 423 1374 || INOC-DBA *3557* NOC > PGP KeyID =3D B38DB1BE >=20 From michele@blacknight.com Tue May 7 01:44:44 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AD2121F8FDC for ; Tue, 7 May 2013 01:44:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E19NJj47hBbG for ; Tue, 7 May 2013 01:44:40 -0700 (PDT) Received: from exchange.blacknight.ie (exchange.blacknight.ie [81.17.243.252]) by ietfa.amsl.com (Postfix) with ESMTP id 0CAA421F9299 for ; Tue, 7 May 2013 01:44:38 -0700 (PDT) Received: from BKEXCHMBX01.blacknight.local ([fe80::76:af74:8c72:96ac]) by bkexchhubcas01.blacknight.local ([fe80::3ca9:6bf1:bd5d:24b%15]) with mapi id 14.02.0328.009; Tue, 7 May 2013 09:44:36 +0100 From: "Michele Neylon :: Blacknight" To: Vlad Dinculescu Thread-Topic: [provreg] Implementation of EPP AuthInfo Thread-Index: AQHOSu9ckUVnHFFpSkKEeAcusGvcf5j5V5GA Date: Tue, 7 May 2013 08:44:35 +0000 Message-ID: References: <20130507065105.3356D5A4010@merlin.blacknight.ie> In-Reply-To: <20130507065105.3356D5A4010@merlin.blacknight.ie> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [81.17.243.251] Content-Type: text/plain; charset="utf-8" Content-ID: <3C4EF10389D9A9469E0AFFBA8F27441B@blacknight.local> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "provreg@ietf.org" Subject: Re: [provreg] Implementation of EPP AuthInfo X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 08:44:44 -0000 DQpPbiA3IE1heSAyMDEzLCBhdCAwNzo1MSwgVmxhZCBEaW5jdWxlc2N1IDxzYXNoYUBkbnNlcnZp Y2VzLmNvLnphPiB3cm90ZToNCg0KPiBIaSBGcmFuY2lzY28sDQo+IA0KPiBUaGFua3MgZm9yIHRo ZSByZXBseSwgcGxlYXNlIHNlZSByZXNwb25zZXMgaW5saW5lIGJlbG93Lg0KPiANCj4gT24gMDcg TWF5IDIwMTMsIGF0IDg6MzMgQU0sIEZyYW5jaXNjbyBPYmlzcG8gPGZvYmlzcG9AaXNjLm9yZz4g d3JvdGU6DQo+IA0KPj4gSGkgVmxhZCwNCj4+IA0KPj4gV2hhdCBhcmUgdGhlIHByb2JsZW1zIHlv dSdyZSB0cnlpbmcgdG8gYWRkcmVzcyB3aXRoIHRoZXNlIG1lYXN1cmVzPw0KPiANCj4gU2ltcGx5 IHB1dCwgd2UgYXJlIGF0dGVtcHRpbmcgdG8gYXZvaWQgcmVnaXN0cmFycyBwZXJmb3JtaW5nIHVw ZGF0ZXMgb24gQ29udGFjdCBpbmZvcm1hdGlvbiB0aGF0IGFyZSBub3QgYXV0aG9yaXNlZCBvciBy ZXF1ZXN0ZWQgYnkgdGhlIENvbnRhY3QuDQo+IFdlIGhhdmUgZm91bmQgdGhhdCAiYnJpbmdpbmcg b3V0IHRoZSBiaWcgc3RpY2siIGRvZXNuJ3Qgd29yayBlZmZlY3RpdmVseSwgc28gbm93IHdlIGFy ZSBhdHRlbXB0aW5nIHRvIHB1dCB0aGUgZGVjaXNpb24gbWFraW5nIHdoZXJlIGl0IGJlbG9uZ3Ms IGluIHRoZSBoYW5kcyBvZiB0aGUgcmVnaXN0cmFudC4NCg0KSWYgeW91J3JlIGhhdmluZyBpc3N1 ZXMgd2l0aCBzb21lIG9mIHlvdXIgcmVnaXN0cmFycyB0aGVuIHlvdSBuZWVkIHRvIGFkZHJlc3Mg dGhhdCB2aWEgdGhlIGNvbnRyYWN0IHlvdSBoYXZlIHdpdGggdGhlbQ0KUGVuYWxpc2luZyBhbGwg cmVnaXN0cmFycyBieSBjcmVhdGluZyBtb3JlIHdvcmsgZm9yIHRoZW0gYW5kIHRoZWlyIGRldmVs b3BlcnMgZG9lc24ndCBzZWVtIHJhdGlvbmFsIHRvIG1lDQoNCj4gDQo+PiANCj4+IFNvbWUgdGhv dWdodHMgYmVsb3c6DQo+PiANCj4+IA0KPj4gT24gTWF5IDYsIDIwMTMsIGF0IDExOjIzIFBNLCBW bGFkIERpbmN1bGVzY3UgPHNhc2hhQGRuc2VydmljZXMuY28uemE+IHdyb3RlOg0KPj4gDQo+Pj4g QWxsLA0KPj4+IA0KPj4+IFBsZWFzZSBzaGFyZSB5b3VyIHRob3VnaHRzIHJlZ2FyZGluZyB0aGUg aW1wbGVtZW50YXRpb24gb2YgdGhlIENvbnRhY3QgQXV0aEluZm8gZm9yIHRoZSBhcHByb3ZhbCBv ZiBpbml0aWF0ZWQgY29udGFjdCB1cGRhdGVzLg0KPj4+IA0KPj4+IE91ciBjdXJyZW50IHByb2Nl c3MgbG9va3MgdG8gaGF2ZSB0aGUgcmVnaXN0cmFudCBwcm92aWRlIHRoZSBjb2RlIGFzIGFuIGlu ZGljYXRpb24gb2YgYXBwcm92YWwgcmVnYXJkaW5nIHRoZSB1cGRhdGUgb2YgdGhlaXIgaW5mb3Jt YXRpb24sIGNvbXBsZXRpbmcgdGhlIHVwZGF0ZSBpbnN0YW50bHkuIFVwZGF0ZXMgdGhhdCBhcmUg bm90IHByb3ZpZGVkIHdpdGggdGhlIGNvZGUgd2lsbCBub3QgZXhlY3V0ZS4NCj4+PiANCj4+IA0K Pj4gRG8geW91IHdhbnQgdG8gYWNjZXB0IGFuIHVwZGF0ZSBmcm9tIGEgbm9uLXNwb25zb3Jpbmcg cmVnaXN0cmFyPw0KPj4gDQo+PiBJZiB0aGF0J3Mgbm90IHRoZSBjYXNlLCB0aGUgQXV0aEluZm8g d2lsbCBiZSBhdmFpbGFibGUgdG8gdGhlIHNwb25zb3JpbmcgcmVnaXN0cmFyIGFueXdheS4NCj4g DQo+IFdlIGRpZCBpZGVudGlmeSB0aGlzIGlzc3VlIGFzIHdlbGwsIGtub3dpbmcgdGhhdCB0aGUg c3BvbnNvcmluZyByZWdpc3RyYXIgd291bGQgaGF2ZSBhY2Nlc3MgdG8gdGhlIGNvZGUuIA0KPiBE b2VzIGFuIGltcGxlbWVudGF0aW9uIGV4aXN0IHdoZXJlIHRoZSBBdXRoSW5mbyBpcyB1c2VkIGFz IGFuIG91dC1vZi1iYW5kIG1lYW5zIG9mIGF1dGhvcmlzYXRpb24gZnJvbSB0aGUgcmVnaXN0cmFu dC4NCj4gDQo+PiANCj4+PiBGdXJ0aGVyIHRvIHRoaXMsIHdlIGFyZSBsb29raW5nIHRvIGltcGxl bWVudCB0aGUgRG9tYWluIEF1dGhJbmZvIGNvZGUgYXMgYSBkZWZpbml0ZSBtZWFzdXJlIGZvciBh cHByb3ZpbmcgcmVnaXN0cmFudCBjaGFuZ2VzIHRvIGEgbGlua2VkIGRvbWFpbi4gSW4gdGhpcyBp bnN0YW5jZSB0aGUgY3VycmVudCByZWdpc3RyYW50IG11c3QgcHJvdmlkZSB0aGUgRG9tYWluIEF1 dGhJbmZvIGNvZGUgYXMgYXBwcm92YWwgb2YgdGhlIHJlZ2lzdHJhbnQgY2hhbmdlLg0KPj4+IA0K Pj4gDQo+PiANCj4+IFNhbWUgYXMgYWJvdmUsIGJ1dCBpbiBhZGRpdGlvbiwgYSBjb250YWN0IG9i amVjdCBjYW4gYmUgaW5kZXBlbmRlbnRseSB1cGRhdGVkIHJlZ2FyZGxlc3MgaWYgaXRzIHVzZWQg aW4gYSBkb21haW4gbmFtZSBvciBub3QsIHNvIHRoZSByZXN0cmljdGlvbiB3aWxsIG9ubHkgaGF2 ZSBlZmZlY3QgaWYgeW91ICdyZXBsYWNlJyB0aGUgcmVnaXN0cmFudCB3aXRoIG90aGVyIElELCBi dXQgbm90IGlmIHlvdSBjaGFuZ2UgdGhlIGNvbnRhY3QgdW5kZXJseWluZyBkYXRhLg0KPj4gDQo+ IA0KPiBJbiB0aGlzIGluc3RhbmNlIHdlIGFyZSBsb29raW5nIGF0IHRoZSByZXBsYWNlbWVudCBv ZiB0aGUgYXNzb2NpYXRlZCBkb21haW4gcmVnaXN0cmFudCBJRCB3aXRoIGEgZGlmZmVyZW50IG9u ZS4gVGhpcyBpcyBhIGRvbWFpbiB1cGRhdGUgd2hlcmUgdGhlIGN1cnJlbnQgcmVnaXN0cmFudCBj YW4gdXNlIHRoZSBhc3NvY2lhdGVkIGRvbWFpbiBBdXRoSW5mbyB0byBhcHByb3ZlIHRoZSBjaGFu Z2Ugb2YgdGhlIHJlZ2lzdHJhbnQgSUQgdG8gYSBkaWZmZXJlbnQgb25lLg0KPiANCj4+IA0KPj4+ IFJlZ2FyZHMsDQo+Pj4gVmxhZCBEaW5jdWxlc2N1DQo+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCj4+PiBEb21haW4gTmFtZSBTZXJ2aWNlcw0KPj4+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4gcHJvdnJlZyBtYWlsaW5nIGxp c3QNCj4+PiBwcm92cmVnQGlldGYub3JnDQo+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9wcm92cmVnDQo+PiANCj4+IEZyYW5jaXNjbyBPYmlzcG8gDQo+PiBEaXJlY3Rv ciBvZiBBcHBsaWNhdGlvbnMgYW5kIFNlcnZpY2VzIC0gSVNDDQo+PiBlbWFpbDogZm9iaXNwb0Bp c2Mub3JnDQo+PiBQaG9uZTogKzEgNjUwIDQyMyAxMzc0IHx8IElOT0MtREJBICozNTU3KiBOT0MN Cj4+IFBHUCBLZXlJRCA9IEIzOERCMUJFDQo+PiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHByb3ZyZWcgbWFpbGluZyBsaXN0DQo+IHBy b3ZyZWdAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9w cm92cmVnDQoNCk1yIE1pY2hlbGUgTmV5bG9uDQpCbGFja25pZ2h0IFNvbHV0aW9ucyDimZ4NCkhv c3RpbmcgJiBEb21haW5zDQpJQ0FOTiBBY2NyZWRpdGVkIFJlZ2lzdHJhcg0KaHR0cDovL3d3dy5i bGFja25pZ2h0LmNvDQpodHRwOi8vYmxvZy5ibGFja25pZ2h0LmNvbS8NCkludGwuICszNTMgKDAp IDU5ICA5MTgzMDcyDQpVUzogMjEzLTIzMy0xNjEyIA0KTG9jYWxsOiAxODUwIDkyOSA5MjkNCkRp cmVjdCBEaWFsOiArMzUzICgwKTU5IDkxODMwOTANCkZhY2Vib29rOiBodHRwOi8vZmIubWUvYmxh Y2tuaWdodA0KVHdpdHRlcjogaHR0cDovL3R3aXR0ZXIuY29tL21uZXlsb24NCi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCkJsYWNrbmlnaHQgSW50ZXJuZXQgU29sdXRpb25zIEx0ZCwg VW5pdCAxMkEsQmFycm93c2lkZSBCdXNpbmVzcyBQYXJrLFNsZWF0eQ0KUm9hZCxHcmFpZ3VlY3Vs bGVuLENhcmxvdyxJcmVsYW5kICBDb21wYW55IE5vLjogMzcwODQ1DQoNCg== From sasha@dnservices.co.za Tue May 7 02:04:52 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B48F21F8E51 for ; Tue, 7 May 2013 02:04:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.242 X-Spam-Level: X-Spam-Status: No, score=-2.242 tagged_above=-999 required=5 tests=[AWL=-0.243, BAYES_00=-2.599, J_CHICKENPOX_46=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VYWJ-37FOjQ8 for ; Tue, 7 May 2013 02:04:48 -0700 (PDT) Received: from relay.dnservices.co.za (relay.dnservices.co.za [160.124.24.10]) by ietfa.amsl.com (Postfix) with ESMTP id 3F9AC21F8B5F for ; Tue, 7 May 2013 02:04:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=simple/simple; d=dnservices.co.za; s=mail; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=Myr/jOFhU2ZjS/hmSfUIDQ6YHD1ZMOfeHdPWXe2rtZI=; b=yR4fucA0vW7jWYhFejvAvbK/5B+DULbYhSrb8KMeoqgz/MdCFGANusKuH8NBn+X3e7+FQwSCR89t52UinNrOV9UwZ3vX6yLdYHlmuw3sOkXI/QZA5PqnrkpYrckmEo5MCcixOzB7zRkg7hxlSHjVmvvCeeW3PPNlwvAchHCA75U=; Received: from cache.coza.net.za ([206.223.136.211] helo=[192.168.0.141]) by relay.dnservices.co.za with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1UZdp9-0000I8-P4; Tue, 07 May 2013 11:04:39 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Vlad Dinculescu In-Reply-To: Date: Tue, 7 May 2013 11:04:38 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5FFC13DE-5EEE-4142-8D6D-86E6F062277A@dnservices.co.za> References: <20130507065105.3356D5A4010@merlin.blacknight.ie> To: "Michele Neylon :: Blacknight" X-Mailer: Apple Mail (2.1499) Cc: provreg@ietf.org Subject: Re: [provreg] Implementation of EPP AuthInfo X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 09:04:52 -0000 Hi Michele, Thanks for the response. I completely agree with your statement. We were = just looking to see if there was perhaps some way of implementing it. It = seems that there isn't without inconveniencing so many others and = increasing the workload for everyone; something which we do not want to = do. Thank you All for the feedback. On 07 May 2013, at 10:44 AM, "Michele Neylon :: Blacknight" = wrote: >=20 > On 7 May 2013, at 07:51, Vlad Dinculescu = wrote: >=20 >> Hi Francisco, >>=20 >> Thanks for the reply, please see responses inline below. >>=20 >> On 07 May 2013, at 8:33 AM, Francisco Obispo wrote: >>=20 >>> Hi Vlad, >>>=20 >>> What are the problems you're trying to address with these measures? >>=20 >> Simply put, we are attempting to avoid registrars performing updates = on Contact information that are not authorised or requested by the = Contact. >> We have found that "bringing out the big stick" doesn't work = effectively, so now we are attempting to put the decision making where = it belongs, in the hands of the registrant. >=20 > If you're having issues with some of your registrars then you need to = address that via the contract you have with them > Penalising all registrars by creating more work for them and their = developers doesn't seem rational to me >=20 >>=20 >>>=20 >>> Some thoughts below: >>>=20 >>>=20 >>> On May 6, 2013, at 11:23 PM, Vlad Dinculescu = wrote: >>>=20 >>>> All, >>>>=20 >>>> Please share your thoughts regarding the implementation of the = Contact AuthInfo for the approval of initiated contact updates. >>>>=20 >>>> Our current process looks to have the registrant provide the code = as an indication of approval regarding the update of their information, = completing the update instantly. Updates that are not provided with the = code will not execute. >>>>=20 >>>=20 >>> Do you want to accept an update from a non-sponsoring registrar? >>>=20 >>> If that's not the case, the AuthInfo will be available to the = sponsoring registrar anyway. >>=20 >> We did identify this issue as well, knowing that the sponsoring = registrar would have access to the code.=20 >> Does an implementation exist where the AuthInfo is used as an = out-of-band means of authorisation from the registrant. >>=20 >>>=20 >>>> Further to this, we are looking to implement the Domain AuthInfo = code as a definite measure for approving registrant changes to a linked = domain. In this instance the current registrant must provide the Domain = AuthInfo code as approval of the registrant change. >>>>=20 >>>=20 >>>=20 >>> Same as above, but in addition, a contact object can be = independently updated regardless if its used in a domain name or not, so = the restriction will only have effect if you 'replace' the registrant = with other ID, but not if you change the contact underlying data. >>>=20 >>=20 >> In this instance we are looking at the replacement of the associated = domain registrant ID with a different one. This is a domain update where = the current registrant can use the associated domain AuthInfo to approve = the change of the registrant ID to a different one. >>=20 >>>=20 >>>> Regards, >>>> Vlad Dinculescu >>>> -------------------------------- >>>> Domain Name Services >>>> _______________________________________________ >>>> provreg mailing list >>>> provreg@ietf.org >>>> https://www.ietf.org/mailman/listinfo/provreg >>>=20 >>> Francisco Obispo=20 >>> Director of Applications and Services - ISC >>> email: fobispo@isc.org >>> Phone: +1 650 423 1374 || INOC-DBA *3557* NOC >>> PGP KeyID =3D B38DB1BE >>>=20 >>=20 >> _______________________________________________ >> provreg mailing list >> provreg@ietf.org >> https://www.ietf.org/mailman/listinfo/provreg >=20 > Mr Michele Neylon > Blacknight Solutions =E2=99=9E > Hosting & Domains > ICANN Accredited Registrar > http://www.blacknight.co > http://blog.blacknight.com/ > Intl. +353 (0) 59 9183072 > US: 213-233-1612=20 > Locall: 1850 929 929 > Direct Dial: +353 (0)59 9183090 > Facebook: http://fb.me/blacknight > Twitter: http://twitter.com/mneylon > ------------------------------- > Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business = Park,Sleaty > Road,Graiguecullen,Carlow,Ireland Company No.: 370845 >=20 Kind Regards, Vlad Dinculescu ------------------------- Domain Name Services= From volker.janzen@internetx.de Tue May 7 02:10:31 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A18E721F850F for ; Tue, 7 May 2013 02:10:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k0b4Ho7-EOtC for ; Tue, 7 May 2013 02:10:26 -0700 (PDT) Received: from mx1.internetx.com (mx1.internetx.com [62.116.129.39]) by ietfa.amsl.com (Postfix) with ESMTP id 4D0AC21F8732 for ; Tue, 7 May 2013 02:10:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.internetx.com (Postfix) with ESMTP id 7DD034C4D7C1 for ; Tue, 7 May 2013 11:10:25 +0200 (CEST) X-Virus-Scanned: InterNetX GmbH amavisd-new at ix-mailer.internetx.de Received: from mx1.internetx.com ([62.116.129.39]) by localhost (ix-mailer.internetx.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HQInbPrDJ+Iw for ; Tue, 7 May 2013 11:10:22 +0200 (CEST) Received: from [192.168.100.46] (pizza.internetx.de [62.116.129.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.internetx.com (Postfix) with ESMTPSA id D8A3E4C4D6D4 for ; Tue, 7 May 2013 11:10:22 +0200 (CEST) Message-ID: <5188C4FE.102@internetx.de> Date: Tue, 07 May 2013 11:10:22 +0200 From: InterNetX - Volker Janzen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: provreg@ietf.org References: <20130507065105.3356D5A4010@merlin.blacknight.ie> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [provreg] Implementation of EPP AuthInfo X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 09:10:31 -0000 Hi, On 05/07/2013 10:44 AM, Michele Neylon :: Blacknight wrote: > Penalising all registrars by creating more work for them and their developers doesn't seem rational to me I agree with this. I don't know any example where a contact:update has to be performed with a password and the registrar is not allowed to store it in its own database and has to fetch it from the domain owner every time. I know some registries that are sending out email notifications if contact data has changed. This enables the registrant to complain, if there are changes he or she did not want. Volker Janzen Team Entwicklung -- InterNetX GmbH Maximilianstr. 6 93047 Regensburg Germany Tel: +49 941 59559-0 Fax: +49 941 59579-050 www.internetx.com www.facebook.com/InterNetX www.twitter.com/InterNetX Geschäftsführer/CEO: Thomas Mörz Amtsgericht Regensburg, HRB 7142 GPG-Key: 0x186C5F77 GPG-Fingerprint: 392E 8730 FE23 DCE8 8878 8524 5361 BCCC 186C 5F77 From michele@blacknight.com Tue May 7 02:35:22 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5535221F84F5 for ; Tue, 7 May 2013 02:35:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LTflQ+F+R2HR for ; Tue, 7 May 2013 02:35:18 -0700 (PDT) Received: from exchange.blacknight.ie (exchange.blacknight.ie [81.17.243.252]) by ietfa.amsl.com (Postfix) with ESMTP id AC27021F89D5 for ; Tue, 7 May 2013 02:35:17 -0700 (PDT) Received: from BKEXCHMBX01.blacknight.local ([fe80::76:af74:8c72:96ac]) by bkexchhubcas01.blacknight.local ([fe80::3ca9:6bf1:bd5d:24b%15]) with mapi id 14.02.0328.009; Tue, 7 May 2013 10:35:16 +0100 From: "Michele Neylon :: Blacknight" To: InterNetX - Volker Janzen Thread-Topic: [provreg] Implementation of EPP AuthInfo Thread-Index: AQHOSu9ckUVnHFFpSkKEeAcusGvcf5j5V5GAgAAHNACAAAb1AA== Date: Tue, 7 May 2013 09:35:15 +0000 Message-ID: References: <20130507065105.3356D5A4010@merlin.blacknight.ie> <20130507090920.1E0EC5A4010@merlin.blacknight.ie> In-Reply-To: <20130507090920.1E0EC5A4010@merlin.blacknight.ie> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [81.17.243.251] Content-Type: text/plain; charset="utf-8" Content-ID: <7D80011161555D41AEDE334A9BECDFDB@blacknight.local> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "" Subject: Re: [provreg] Implementation of EPP AuthInfo X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 09:35:22 -0000 Vm9sa2VyDQoNCkkgKnRoaW5rKiBJJ3ZlIHNlZW4gYSBjb3VwbGUgb2YgY2NUTERzIG9mZmVyIGEg c29ydCBvZiAic2VsZiBzZXJ2aWNlIiBwb3J0YWwgdGhhdCBhbGxvd3MgcmVnaXN0cmFudHMgdG8g ZG8gc29tZSBtYWludGVuYW5jZSB1c2luZyB0aGlzIGtpbmQgb2YgbWV0aG9kLCB0aG91Z2ggdGhl IHByb2JsZW0gaXMgdGhhdCBkb2luZyB0aGlzIG1lYW5zIHRoZSBkYXRhIHdlICh0aGUgcmVnaXN0 cmFyKSBob2xkIGlzIG91dCBvZiBkYXRlLg0KDQpXZSd2ZSBhbHNvIHNlZW4gY2NUTEQgcmVnaXN0 cmllcyBhbGxvdyBkb21haW4gaG9sZGVyIChyZWdpc3RyYW50KSB0cmFuc2ZlcnMgd2l0aG91dCBp bmZvcm1pbmcgdGhlIHJlZ2lzdHJhciBvZiByZWNvcmQuDQpWZXJ5IHZlcnkgYW5ub3lpbmcNCg0K UmVnYXJkcw0KDQpNaWNoZWxlDQoNCg0KTXIgTWljaGVsZSBOZXlsb24NCkJsYWNrbmlnaHQgU29s dXRpb25zIOKZng0KSG9zdGluZyAmIERvbWFpbnMNCklDQU5OIEFjY3JlZGl0ZWQgUmVnaXN0cmFy DQpodHRwOi8vd3d3LmJsYWNrbmlnaHQuY28NCmh0dHA6Ly9ibG9nLmJsYWNrbmlnaHQuY29tLw0K SW50bC4gKzM1MyAoMCkgNTkgIDkxODMwNzINClVTOiAyMTMtMjMzLTE2MTIgDQpMb2NhbGw6IDE4 NTAgOTI5IDkyOQ0KRGlyZWN0IERpYWw6ICszNTMgKDApNTkgOTE4MzA5MA0KRmFjZWJvb2s6IGh0 dHA6Ly9mYi5tZS9ibGFja25pZ2h0DQpUd2l0dGVyOiBodHRwOi8vdHdpdHRlci5jb20vbW5leWxv bg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KQmxhY2tuaWdodCBJbnRlcm5ldCBT b2x1dGlvbnMgTHRkLCBVbml0IDEyQSxCYXJyb3dzaWRlIEJ1c2luZXNzIFBhcmssU2xlYXR5DQpS b2FkLEdyYWlndWVjdWxsZW4sQ2FybG93LElyZWxhbmQgIENvbXBhbnkgTm8uOiAzNzA4NDUNCg0K From JGould@verisign.com Tue May 7 05:42:56 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A52121F8EC1 for ; Tue, 7 May 2013 05:42:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w-QUxF1-2z5L for ; Tue, 7 May 2013 05:42:52 -0700 (PDT) Received: from exprod6og105.obsmtp.com (exprod6og105.obsmtp.com [64.18.1.189]) by ietfa.amsl.com (Postfix) with ESMTP id 9ED2F21F8F07 for ; Tue, 7 May 2013 05:42:43 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob105.postini.com ([64.18.5.12]) with SMTP ID DSNKUYj2w0hr7agla/KiEVQ4Gz0C3gfR6glm@postini.com; Tue, 07 May 2013 05:42:51 PDT Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id r47CgdeU019703 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 7 May 2013 08:42:40 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Tue, 7 May 2013 08:42:39 -0400 From: "Gould, James" To: Vlad Dinculescu , "provreg@ietf.org" Thread-Topic: [provreg] Implementation of EPP AuthInfo Thread-Index: AQHOSuuM1axMiD5+ekqtrlcsa+loTpj5qtAA Date: Tue, 7 May 2013 12:42:39 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-ID: <769CDB067473A74C96237A5B042D4512@verisign.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [provreg] Implementation of EPP AuthInfo X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 12:42:56 -0000 Vlad, The main question is what you're attempting to mitigate with requiring the authinfo on an update for a contact or domain. The first item is that the sponsoring registrars can and do have the authinfo values, so there is no guarantee and is unlikely that the registrant will be presented anything by the sponsoring registrar. Are you attempting to mitigate a compromised registrant account or a compromised registrar? In both cases, the sponsoring registrar can pass the authinfo automatically without any additional steps from the registrant, so requiring the authinfo on update will not mitigate these vulnerabilities. The authinfo works for actions taken by non-sponsoring registrars like for an info or transfer, since the registrant must pass the authinfo that was received by the sponsoring registrar to authorize the action. Use of the authinfo for actions by the sponsoring registrar will add no additional security since the information is available to the sponsoring registrar without any direct action from the registrant. =20 --=20 =20 JG =20 =20 James Gould Principal Software Engineer jgould@verisign.com =20 703-948-3271 (Office) 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On 5/7/13 2:23 AM, "Vlad Dinculescu" wrote: >All, > >Please share your thoughts regarding the implementation of the Contact >AuthInfo for the approval of initiated contact updates. > >Our current process looks to have the registrant provide the code as an >indication of approval regarding the update of their information, >completing the update instantly. Updates that are not provided with the >code will not execute. > >Further to this, we are looking to implement the Domain AuthInfo code as >a definite measure for approving registrant changes to a linked domain. >In this instance the current registrant must provide the Domain AuthInfo >code as approval of the registrant change. > >Regards, >Vlad Dinculescu >-------------------------------- >Domain Name Services >_______________________________________________ >provreg mailing list >provreg@ietf.org >https://www.ietf.org/mailman/listinfo/provreg From sasha@dnservices.co.za Tue May 7 06:00:56 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7BA021F86D8 for ; Tue, 7 May 2013 06:00:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.461 X-Spam-Level: X-Spam-Status: No, score=-2.461 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K1OqhwE389Ld for ; Tue, 7 May 2013 06:00:52 -0700 (PDT) Received: from relay.dnservices.co.za (relay.dnservices.co.za [160.124.24.10]) by ietfa.amsl.com (Postfix) with ESMTP id F3AC221F86B9 for ; Tue, 7 May 2013 06:00:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=simple/simple; d=dnservices.co.za; s=mail; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=SFHTLFftXks80DDHeMsvyt43nu8QwN74TWNkLBtk6Vc=; b=zjdnp2faL5+TeE2O1gS87nrNc2E5vXcWNMBf+j155LjPHlQ0udEF+K6AchvXDhfkLH7vt3HcqMUkhTEOqnTaRy1FqOmj2uT5T5l2PYm3NmkW4AhAvOjjHYReKBAwJA9dOSakB2MN9FdrLdEpBMsOnkFNcFOlfPWG85t8JDBonYQ=; Received: from cache.coza.net.za ([206.223.136.211] helo=[192.168.0.141]) by relay.dnservices.co.za with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1UZhVU-0000QY-2k; Tue, 07 May 2013 15:00:36 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Vlad Dinculescu In-Reply-To: Date: Tue, 7 May 2013 15:00:35 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Gould, James" X-Mailer: Apple Mail (2.1499) Cc: "provreg@ietf.org" Subject: Re: [provreg] Implementation of EPP AuthInfo X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 13:00:57 -0000 James, I'm attempting to mitigate unwarranted or accidental updates from = occurring. I though this would be possible by implementation of an out-of-band = process whereby, for example, a domain update is performed to change the = associated registrant ID. This would create a queued timer on the = registry side whereby its execution will depend on the current = registrant providing the AuthInfo code through some online interface. By = doing this, the registrant provides authorisation. If the code is not = provided, the timer expires and the domain update is cancelled. As Michele mentioned earlier this would be an extreme incorporation = which will require a lot of work, hence we will be abandoning the idea = and looking more towards a policy level to punish unwarranted actions. On 07 May 2013, at 2:42 PM, "Gould, James" wrote: > Vlad, >=20 > The main question is what you're attempting to mitigate with requiring = the > authinfo on an update for a contact or domain. The first item is that = the > sponsoring registrars can and do have the authinfo values, so there is = no > guarantee and is unlikely that the registrant will be presented = anything > by the sponsoring registrar. Are you attempting to mitigate a = compromised > registrant account or a compromised registrar? In both cases, the > sponsoring registrar can pass the authinfo automatically without any > additional steps from the registrant, so requiring the authinfo on = update > will not mitigate these vulnerabilities. The authinfo works for = actions > taken by non-sponsoring registrars like for an info or transfer, since = the > registrant must pass the authinfo that was received by the sponsoring > registrar to authorize the action. Use of the authinfo for actions by = the > sponsoring registrar will add no additional security since the = information > is available to the sponsoring registrar without any direct action = from > the registrant. =20 >=20 > --=20 >=20 > JG >=20 >=20 >=20 > James Gould > Principal Software Engineer > jgould@verisign.com >=20 > 703-948-3271 (Office) > 12061 Bluemont Way > Reston, VA 20190 > VerisignInc.com >=20 >=20 >=20 >=20 >=20 > On 5/7/13 2:23 AM, "Vlad Dinculescu" wrote: >=20 >> All, >>=20 >> Please share your thoughts regarding the implementation of the = Contact >> AuthInfo for the approval of initiated contact updates. >>=20 >> Our current process looks to have the registrant provide the code as = an >> indication of approval regarding the update of their information, >> completing the update instantly. Updates that are not provided with = the >> code will not execute. >>=20 >> Further to this, we are looking to implement the Domain AuthInfo code = as >> a definite measure for approving registrant changes to a linked = domain. >> In this instance the current registrant must provide the Domain = AuthInfo >> code as approval of the registrant change. >>=20 >> Regards, >> Vlad Dinculescu >> -------------------------------- >> Domain Name Services >> _______________________________________________ >> provreg mailing list >> provreg@ietf.org >> https://www.ietf.org/mailman/listinfo/provreg >=20 From rubensk@nic.br Tue May 7 06:37:43 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A3F321F902A for ; Tue, 7 May 2013 06:37:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V+yKPj8Sr7vJ for ; Tue, 7 May 2013 06:37:42 -0700 (PDT) Received: from mail.nic.br (mail.cgi.br [IPv6:2001:12ff:0:4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 3CF2321F901D for ; Tue, 7 May 2013 06:37:42 -0700 (PDT) Received: from rubens.in.registro.br (3.195.net.registro.br [200.160.3.195]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.nic.br (Postfix) with ESMTPSA id 8B9402080270; Tue, 7 May 2013 10:37:41 -0300 (BRT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Rubens Kuhl In-Reply-To: Date: Tue, 7 May 2013 10:37:41 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Vlad Dinculescu X-Mailer: Apple Mail (2.1283) Cc: "provreg@ietf.org" Subject: Re: [provreg] Implementation of EPP AuthInfo X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 13:37:43 -0000 Vlad, What you are trying to accomplish is a registry-registrant = communications authorization channel. It can only be implemented outside = EPP, because registrants do not "speak" EPP. We have one such mechanism = in .br where registrants can ask for a password to manage their .br = handles instead of their registrars, and it's implemented by web = interface and e-mail. When that happens registrars are informed thru EPP = Poll messages.=20 Rubens Em 07/05/2013, =E0s 10:00:000, Vlad Dinculescu escreveu: > James, >=20 > I'm attempting to mitigate unwarranted or accidental updates from = occurring. >=20 > I though this would be possible by implementation of an out-of-band = process whereby, for example, a domain update is performed to change the = associated registrant ID. This would create a queued timer on the = registry side whereby its execution will depend on the current = registrant providing the AuthInfo code through some online interface. By = doing this, the registrant provides authorisation. If the code is not = provided, the timer expires and the domain update is cancelled. >=20 > As Michele mentioned earlier this would be an extreme incorporation = which will require a lot of work, hence we will be abandoning the idea = and looking more towards a policy level to punish unwarranted actions. >=20 >=20 > On 07 May 2013, at 2:42 PM, "Gould, James" = wrote: >=20 >> Vlad, >>=20 >> The main question is what you're attempting to mitigate with = requiring the >> authinfo on an update for a contact or domain. The first item is = that the >> sponsoring registrars can and do have the authinfo values, so there = is no >> guarantee and is unlikely that the registrant will be presented = anything >> by the sponsoring registrar. Are you attempting to mitigate a = compromised >> registrant account or a compromised registrar? In both cases, the >> sponsoring registrar can pass the authinfo automatically without any >> additional steps from the registrant, so requiring the authinfo on = update >> will not mitigate these vulnerabilities. The authinfo works for = actions >> taken by non-sponsoring registrars like for an info or transfer, = since the >> registrant must pass the authinfo that was received by the sponsoring >> registrar to authorize the action. Use of the authinfo for actions = by the >> sponsoring registrar will add no additional security since the = information >> is available to the sponsoring registrar without any direct action = from >> the registrant. =20 >>=20 >> --=20 >>=20 >> JG >>=20 >>=20 >>=20 >> James Gould >> Principal Software Engineer >> jgould@verisign.com >>=20 >> 703-948-3271 (Office) >> 12061 Bluemont Way >> Reston, VA 20190 >> VerisignInc.com >>=20 >>=20 >>=20 >>=20 >>=20 >> On 5/7/13 2:23 AM, "Vlad Dinculescu" wrote: >>=20 >>> All, >>>=20 >>> Please share your thoughts regarding the implementation of the = Contact >>> AuthInfo for the approval of initiated contact updates. >>>=20 >>> Our current process looks to have the registrant provide the code as = an >>> indication of approval regarding the update of their information, >>> completing the update instantly. Updates that are not provided with = the >>> code will not execute. >>>=20 >>> Further to this, we are looking to implement the Domain AuthInfo = code as >>> a definite measure for approving registrant changes to a linked = domain. >>> In this instance the current registrant must provide the Domain = AuthInfo >>> code as approval of the registrant change. >>>=20 >>> Regards, >>> Vlad Dinculescu >>> -------------------------------- >>> Domain Name Services >>> _______________________________________________ >>> provreg mailing list >>> provreg@ietf.org >>> https://www.ietf.org/mailman/listinfo/provreg >>=20 >=20 > _______________________________________________ > provreg mailing list > provreg@ietf.org > https://www.ietf.org/mailman/listinfo/provreg From JGould@verisign.com Wed May 8 07:44:01 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC9B221F92A5 for ; Wed, 8 May 2013 07:44:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[AWL=-1.501, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qUiGd+-f5VA0 for ; Wed, 8 May 2013 07:43:57 -0700 (PDT) Received: from exprod6og122.obsmtp.com (exprod6og122.obsmtp.com [64.18.1.238]) by ietfa.amsl.com (Postfix) with ESMTP id B27F921F873D for ; Wed, 8 May 2013 07:43:55 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob122.postini.com ([64.18.5.12]) with SMTP ID DSNKUYpkq41SFoMw/9lvcrpK9AXQPBsVRyX+@postini.com; Wed, 08 May 2013 07:43:56 PDT Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id r48EhqlC018280 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 8 May 2013 10:43:54 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Wed, 8 May 2013 10:43:51 -0400 From: "Gould, James" To: EPP Provreg Thread-Topic: Launch EPP SDK 2.1.0.0 Preview Thread-Index: AQHOS/p1SqOTwlnHMkOCrRpdjSrgQg== Date: Wed, 8 May 2013 14:43:51 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.173.152.4] Content-Type: multipart/mixed; boundary="_004_CDAFD7964F32Ajgouldverisigncom_" MIME-Version: 1.0 Subject: [provreg] Launch EPP SDK 2.1.0.0 Preview X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2013 14:44:01 -0000 --_004_CDAFD7964F32Ajgouldverisigncom_ Content-Type: multipart/alternative; boundary="_000_CDAFD7964F32Ajgouldverisigncom_" --_000_CDAFD7964F32Ajgouldverisigncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Verisign has released the third release of a preview version of the Launch = EPP SDK, named Launch EPP SDK 2.1.0.0. This SDK fully implements draft-tan= -epp-launchphase-10 ( http://tools.ietf.org/html/draft-tan-epp-launchphase-= 10 ) and draft-lozano-tmch-smd-02 ( http://tools.ietf.org/html/draft-lozano= -tmch-smd-02 ), referred to simply as 10/02, and includes the following fea= tures that can be of use to multiple stakeholders: 1. Packet encoder / decoder (CODEC) that will encode the XML from object= s and decode the objects from XML. 2. Creation and validation code for signed marks (SMD) using an XML sign= ed mark or a base64 encoded signed mark that complies with draft-lozano-tmc= h-smd-02. 3. Use of a test CA issued certificate that is included in the signed ma= rk or base64 encoded signed mark that is chained to the test CA certificate= by the EPP Stub Server. A test certificate in a test Certificate Revocati= on List (CRL) is also validated by the EPP Stub Server. 4. Sample of poll messaging compliant with draft-tan-epp-launchphase-10 = in the EPP Stub Server. 5. A client API that utilizes the packet encoder / decoder (CODEC) along= with other code (e.g. transport, configuration, XML parsing pooling) to in= terface with an EPP server. 6. An EPP Stub Server that includes pre-defined responses to support the= client tests. The EPP Stub Server behavior can be easily customized to su= ite your testing needs. The Launch EPP SDK includes support for RFC 5730, 5731, 5732, 5733, 5734, 3= 915, and 5910. Verisign will be integrating the preview of the Launch Phase EPP Extension = into its Verisign Bundle EPP SDK. The Launch EPP SDK is open source, requires Java 6 or higher, and below are= the distributions and documents: * Unix Binary Distribution (.tar.gz) - http://www.verisigninc.com/asset= s/2-1-0-0/epp-launch-bundle-2.1.0.0-bin.tar.gz * Unix Source Distribution (.tag.gz) - http://www.verisigninc.com/asset= s/2-1-0-0/epp-launch-bundle-2.1.0.0-src.tar.gz * Windows Binary Distribution (.zip) - http://www.verisigninc.com/asset= s/2-1-0-0/epp-launch-bundle-2.1.0.0-bin.zip * Windows Source Distribution (.zip) - http://www.verisigninc.com/asset= s/2-1-0-0/epp-launch-bundle-2.1.0.0-src.zip * Readme File - http://www.verisigninc.com/assets/2-1-0-0/epp-launch.RE= ADME * Install Instructions - http://www.verisigninc.com/assets/2-1-0-0/epp-= launch.INSTALL * Change Log - http://www.verisigninc.com/assets/2-1-0-0/changelog.txt -- JG [cid:922F2D86-FC79-472E-A0CF-F88984FFA29E] James Gould Principal Software Engineer jgould@verisign.com 703-948-3271 (Office) 12061 Bluemont Way Reston, VA 20190 VerisignInc.com "This message (including any attachments) is intended only for the use of t= he individual or entity to which it is addressed, and may contain informati= on that is non-public, proprietary, privileged, confidential and exempt fro= m disclosure under applicable law or may be constituted as attorney work pr= oduct. If you are not the intended recipient, you are hereby notified that = any use, dissemination, distribution, or copying of this communication is s= trictly prohibited. If you have received this message in error, notify send= er immediately and delete this message immediately." --_000_CDAFD7964F32Ajgouldverisigncom_ Content-Type: text/html; charset="us-ascii" Content-ID: <4B4337BF24B5A941939D71031AB128A0@verisign.com> Content-Transfer-Encoding: quoted-printable
Verisign has released the third release of a preview version of the La= unch EPP SDK, named Launch EPP SDK 2.1.0.0.  This SDK fully implements= draft-tan-epp-launchphase-10 ( http://tools.ietf.org/html/draft-tan-epp-laun= chphase-10 ) and draft-lozano-tmch-smd-02 ( http://tools.ietf.org/html/draft-lozano-tmch-smd-02 ), referred to simply as 10/02, and includes the following fea= tures that can be of use to multiple stakeholders:

  1. Packet encoder / decoder (CODEC) that will encode the XML from objects = and decode the objects from XML.    
  2. Creation and validat= ion code for signed marks (SMD) using an XML signed mark or a base64 encode= d signed mark that complies with draft-lozano-tmch-smd-02.
  3. Use of a= test CA issued certificate that is included in the signed mark or base64 e= ncoded signed mark that is chained to the test CA certificate by the EPP St= ub Server.  A test certificate in a test Certificate Revocation List (= CRL) is also validated by the EPP Stub Server.
  4. Sample of poll messaging compliant with = draft-tan-epp-launchphase-10 in the EPP Stub Server.
  5. A client API t= hat utilizes the packet encoder / decoder (CODEC) along with other code (e.= g. transport, configuration, XML parsing pooling) to interface with an EPP = server.  
  6. An EPP Stub Server that includes pre-defined respons= es to support the client tests.  The EPP Stub Server behavior can be e= asily customized to suite your testing needs.  
The Launch EPP SDK includes support for RFC 5730, 5731, 5732, 5733, 57= 34, 3915, and 5910.  

Verisign will be integrating the preview of the Launch Phase EPP Exten= sion into its Verisign Bundle EPP SDK.  

The Launch EPP SDK is open source, requires Java 6 or higher, and belo= w are the distributions and documents:

-- 

 

JG

 

 

Jame= s Gould

Princ= ipal Software Engineer

jgould@verisign.com

 = ;

703-9= 48-3271 (Office)

12061= Bluemont Way

Resto= n, VA 20190

Veri= signInc.com

“This message (including any attachments) is= intended only for the use of the individual or entity to which it is addre= ssed, and may contain information that is non-public, proprietary, privileg= ed, confidential and exempt from disclosure under applicable law or may be constituted as attorney work product. If yo= u are not the intended recipient, you are hereby notified that any use, dis= semination, distribution, or copying of this communication is strictly proh= ibited. If you have received this message in error, notify sender immediately and delete this message immedi= ately.”
--_000_CDAFD7964F32Ajgouldverisigncom_-- --_004_CDAFD7964F32Ajgouldverisigncom_ Content-Type: image/png; name="8A7A655D-9ED0-4D38-898D-E9E8B754666E[21].png" Content-Description: 8A7A655D-9ED0-4D38-898D-E9E8B754666E[21].png Content-Disposition: attachment; filename="8A7A655D-9ED0-4D38-898D-E9E8B754666E[21].png"; size=4109; creation-date="Wed, 08 May 2013 14:43:51 GMT"; modification-date="Wed, 08 May 2013 14:43:51 GMT" Content-ID: <922F2D86-FC79-472E-A0CF-F88984FFA29E> Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAEkAAABACAIAAADZHs1DAAAP1ElEQVRoBe2aa3CU1RnHN3vLJtmQ hEtiwlUBtZUUCiU6tU7wVhinjOB0xmJnFIdpO1Y6DY586Iwdo36gLc4Iip3pVAL9IKjTDnhDEEWC 1GoICHLRctEkXHIPuZHr7qa/c553T152N9lsNvnWM5nDec97Ls//+T+X854lZWBgwDFuRRaXOiUl hX2kHrcNr1vYfd1T0g/ACIVCQV0CgQD/8miwOZ1Ol8vldrupKTyOK9QU2ThpUA4w9Pf39/X19fT0 UCsYYHA6QcLiYKCwF2MEMNh8Pp/X6/V4PAxOXoDoFcYAG7ICplsXNvClpSFvipAimGy1wQmrMgV4 aUzxekEbLV8yPUlhE66u6YJkqT6fMjKDyjRs2GgaeNKA587OTqZnZGSMLYejx4biEautrQ3eUlNT LUiCx6AyjWHhAbKrqwuEwMNQxYyTYUzmjhIbboMo7e3tyIwoMYA5nZ+duXiyur6ju88u5ZL5s+ff mJ+TmUan4JUGNVbQ2tqKNvx+PwTaZ42uPRpseBeoYMygUvRoijp7AnuPXdhz9PyeyvPI7khxqtoU yTcDofk35j1674LH7luY7U8zVsoo2qgMc5gwYQIeaOaNrpEwNoCBqraujgBALDeoOnr6X9t/4rX9 x9t7gg6Xx+F0K1QEQOBRFKoBVYdCjoGgI6T+MtO9j9+74Nlf3gNChhiQHR0dwMvKykoSXmLYMEUY u3T5MoyxMZEDbJTK81fWlR242NrrcHsdToBpSBZpsKeps0gDocYWDDhC6i8zzbO9ZOWKH38/Ah5K hL1kjDMBbMQMDKa6pgaE6enpggp4r+z5cvOeLx0en6bLpRkTbIKKWjGnijoCgQ3qdB3sdwR6FcJg 8NF7Crc99XNeG/ZQIvkQ3xt1bhgpNrYhlMFYY0NDVna2Bczp/MPrh3dVVjncAHOrvxSwuSw3U3SF SVPIxDKpBVuYQOABMtg3f+aUA39aY/fApqYmLB89CmBZY+T1SA8EcIWb1dfXk8QIaFIUsKM1Dk+a w+1xuLQ1Ag9s1p9uC9rBTk2sUoRLq8Ojp6cy/UR100MvvK41oPkdGMjJySF3svXI8dhHjggbSDhD ED8wSxgTYLsqLihgbsRCULBp3gghBobyN5AY33NalKoeuA2rgInYs1rHU37m4rq/vW/gsReZk63Z 0S70CNsjwiakNTU2etxuAXax5dpf3juuuBJgFiQtPdgUKv3n1DZpPdrawFPDwvBoW/C8L79bceD4 eQOPcELMHB118bHhab29vYq0UIhjvGB77p+VHeRk7MpCIn5lgobRrHY5noCnQgrD5JX5sJJOPZ0Y q/h3rdn0NpsaePgbAkiPWXckjfjfOJytMHrcmngltnGsqqmyqllZUYozK82z4MY8tZNYmtnT6T5+ saWtV1DpXuARRYLB4ltyVWw0hZRA4VDS1Xfiu3pe1TR3vLDz4B9XLSGEAIlw0tzcTJ1oPoiPDXto uXoVzfkzM/kyQ4y/f3JW0QVpig3H7vXLJfkqEW3l4OlLd/95n7JbU0KB4rkTDz6z3HTYGyVlH5+o alTjQ6FtHx575hfFvAUeXodaESNRbHFsErWRQxsaGpRBpqRQX2ru/LKmRScxZZBtnd0lr31oF9G0 l9w2rfjmXJWppdDo79n+xL1mgL1RVd+6+f1jWmUq9dc0tb/z+TfsTmEYB2jEkLZ91vDtONgwQhgj ZavPaf1N/enZegUM3uTP7f3Hga8OnqyKuc323xQ7OH9ICQaefWjRrCkTYo5c/fK7yshlTXVkc739 +RlGanQDREvEEI+IOT1mZxxsBH0WlfO+uioIhQ6dbdSuhffrUI5Aqf7SNz6NuTpInl2xQHlXKJDl CZU8sCDmsN1fnC0/16wCiVqTU6jS3cGvqoUoakk87B9z+lCdcbChKoAJY7SBV9PUobMTE3VwQ9Me X/nXtds/Ph5zj5JlhVk+J2erTY/+JDvDF3tM2ceaNI41kjzw5BTMsrWzx8DD8caBt76+YEDZlaYt 1N4bUqo1fyBE39700rf+09rZHS16dkbqplWL5xf4Vy9Rp+HoUvrG4eo2/emgzmgUWVzBO/Fdrdgk vZjlGPPG0nClCVP1uXpIE6qtPKVBOtF6dUv3pt2faeEiK1Bt/+39kb36ufVaz6YPz6jEDf+WvvQL Mor+WhVsSozwfVnMdWJ2DpcDZF0MElj9+kKuvZuERdEJ16p1B/nAk/bcv46svn/RrLxs3XVdBaUp KzYoR7UX1IS7qg+I62+BLALVUGSQGQbkyM/N129m31jnFukQ3kBoey9bWhuTudWXmze9ZOsQ+aBw 1oN3znOkZTsyJg3+pecQh3QCDFvB4AaqR1NlgZI3IwfG+OGwqdda0xg6qRPjnJGdqveIAKb7OBx6 fG8frR4qH2xaXZzl12diuDJ/KjbiYNevqriytGboMsLooSOq4mBDT1wbWLwFgz5sx3xZyh1B2GaU fDqolJR9FHNn8kHJT2+77rRlH6ew8EUnqHRjYGD65Ex1Ka0Lyk2INJaLg43DzqRJk8BG4WQAgd/L y9ASKFfQsoWl4UH7z4lL7cPkg5k5sdKAAFPLWahYnNuU6ZMnWDFkYEBpOcIt9fbDVHGwyRcUVyNg 6+ntxeVmT0pVx6jBb2cjjd6FtOtJKyk7MFQ+KF35Qz6xBwViHWV++m9wzRD03nXrVIs09tZxUhxk cG68VhxsqIrEkpOdDWPwxi43TUzVt1TcC+g/uyHRxnncqW39rtK3hsgHxbfOn04g1WFJARNcRkE0 9LKh4AOL5hjSerq7EWOMecMSIC0/Px9UwOMzceE0/+QMtyUBcqg7Of5EOK1Jwo/Ht/m9So6/0Zol oVXVNmueBJidNFmKNdVF2LKFsxVvmjTUihhj7G8GG1KyC2dLEN4xw69ub7QEgyAlDIgT6qCijr9R pfTNf7f1Ch4YE1O0kabW5Nqr/+E7b8HfLN50Khh7bMjGVSQ2mX/DDRBHsEKFS+dOSHMNqAO+OgSL 74VVrkxUZUYss/ybuoh8UNXYvnnfaXUNQRkExly9iFpKX10G+p56sMgAQ6EYJGJEKSpORxx/YzZW zlf9DwoL+aUQeHyDp7oGfnW7/nYWNataY6OWBtN0UFm95QP7/qu37FUpnnAKfqWFsEbURI0KfQFs +aJpE/3GIFEoAiTqbEoE+95DtbGHvLy8adOmCTwunublehfc4NWWGWZPtG6FUO1Lbm91c9emdypk WT7DYVJhpoijGkiWjrilDMzLz/j9zxYpLwt7mvwEOZRsw/SPCBs649ejosWLyePA69W/jD6+aNL0 TKe+NhV42j5F/cKeTnelbx6WfKDcT04h8lZpQXOlv+5knUxP8K+/vl9QCTyiCVuPgjQwu0pLS4eB Lq+IKOQWNiDF1dXVYVB89fi8njtmZp6u62rvjfpk5IwiQcXh6O3rr2u6WtXQ/mZFtcKmStjBFHth eMFApjuwY+19N+XlMEIdwrjCCAYzMzPBlmhmU5uwAIqRVtyaKNLS0rJv//5Lly6xGT/iZPj9AYfr xU8bLnaElNzqRkDukuUTUx8TddxT0UUNIHnoqIizKfYEWBBVwdi2J+6bN30SK8tPKMjD3dbEiRPx iLiyxRyQADa0QH6rra19b88efkayw3v3m7aPLnQp0YmB6kssjA1IFKU+/cVptXUUUf7JlZ6y5x/N yN782J1ZGT4FTBcuDjP9fo57OFuiac3gTAAbc/ABAsmV2toP9u418Pgxghh9rrlv29Hmpi5NINjI 4NQUqa0NNWkqPMIbpAVmZPseL5774KJZYVBwlkLQz87Kys3NhTf6ramJ/5MYNtYHHj/ocM1sh+f2 eOTHpM8vdh3+ruPrhm7NXvhT2vqGYbZgA1VozpSMh4tmLl84w6CiweJYfu4UVYj7yQBjs4SxCTzY u3r16ifl5TU1NUigfkB1uVAzJkTIaekOfl3f9d/G3sbOvsZr/U3X1HVLps81c2J6flba3Dz/XTfn FWSnMYW5jBcM5DHaBfn5+FiSjLEdZTTYmCYK5grs9JkzlZWVJAaBh5QKIeda/R9nlNxadgEgtYUG VBqZOqeyXCgEpKkFBfJLt6DVEo6+GiU2NiS04PHYZ0Nj4+lTp85duECXoYIjEgg9/LcfQBqcNpaY TgEXMPhpG1Rgww6ZOOrgEaGG0WOThYRAEDa3tJw/f/7Ct98SCTQfihXT4AGcBApmCXtkTMATCfNy c/kNEVTEesZHyJfMY7LYZG/Uj7eQIQBZ39DAz6tkQvXY3W2HRxuLJeqo+D55MkdwIOGi/IgB4GRg xJw7NthkaTgUkPK5QI3R0kM/AwQkJgcSKKKmCIcxJUu+cyyxGWnEl4BEkTav8CIKCCnSNuPHqTEu 2MZJ1kSXHUvfTXTv8R7/f2zjreHxWT/hS4hkxLhy5QqHNVaYOnUqoX/4pS5wGNCFnE4CHH5wzLfu jS++eOXyZd5t2LBB9tu9e3d5eTk9a9as2bp1a/S0tWvXzp49+9VXXyVZ298iRFFR0dKlS+k0b196 6SUeQcVSJD0znpErV65kRzBs2bKF/mXLlsncYQYzbN26ddQFU6euf/ppGma6SLVz586TJ0/Sj/DO 24uKaFGki8Y5LTFJdt68efrNSCtE37t376lTp6InRABjQEVFxfPPP09+jxgMMKCKFpCBIoNf0fjN YPg4dOiQeTQNVIZRiHW4CwsLd+3axTtIWLx4Mad7oZF+M2HOnDlPPvmkeYxoGGY2btzIK4SOUAqq FVmLi4tXrFgBHlTAMFQbbZm8EskeeeQR5GFBoYKLtoh9GQmSiE4MyojqxpThFzzwtmrVKmNmdmxI tm/fPrOKWI55lAYGKQ2RLOKtPLIFPKBXZALkUGPoRyQBRhupMNdol2MjWImGZ5ZVsQSzZBBDsQex TCSw616MzcyJwIZr8UqYoQHJZqQ00KWoz74OW+BvBkDEFGEJecSm5C3jCwoKpM10BIZ8NBUx1zwq bMYsASa82UljgCjbzIloGKrpR4sYXsQAHn+3di0mhCeLwdODZDt27IjYyEzkrYyxLy6dMoaNkNau LDPXNBQ2Y5Zsb2aaETTQjTFie7+0MZivTp4UoQEW7UIyTJyNNmywkRjIZR2i7WsKIbzFaNmX6McY O3syWGgnRNkB29ehbZ1LltiUjedgRfZxfKoQD0xBOPtbTPShlSulJ1oI+omchEQizZEjR4hV9PCx J+ONl8ojtTAJIWVlZYL8iwrrZtqMkQZeE23/9jGKN4rdNuxteQsnkoLkMTpsogtmiUmDxO6rTEG1 ol2MUFaQGrvCZIyjSidWwDqMp6bYx0e3iaVoLbpfeixsGBI2I3qyR56YihH3jXBiHF0AIBDY7G8J GPDDecDIyiO7SEzCumQX4RC069evh38ZzFsEE6+jjdARg9GF/a0d5/8ActOtScHpPCkAAAAASUVO RK5CYII= --_004_CDAFD7964F32Ajgouldverisigncom_-- From keith@blacknight.com Thu May 9 06:12:47 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DE4B21F9154 for ; Thu, 9 May 2013 06:12:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kgJbbyYWtqYj for ; Thu, 9 May 2013 06:12:42 -0700 (PDT) Received: from nineve.blacknight.ie (nineve.blacknight.ie [81.17.243.129]) by ietfa.amsl.com (Postfix) with ESMTP id A835921F84CD for ; Thu, 9 May 2013 06:12:42 -0700 (PDT) Received: by nineve.blacknight.ie (Postfix, from userid 1010) id 795AA580F1; Thu, 9 May 2013 14:12:40 +0100 (IST) Date: Thu, 9 May 2013 14:12:40 +0100 From: Keith Gaughan To: "provreg@ietf.org" Message-ID: <20130509131240.GR4002@nineve.blacknight.ie> References: <20130507065105.3356D5A4010@merlin.blacknight.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130507065105.3356D5A4010@merlin.blacknight.ie> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: [provreg] Implementation of EPP AuthInfo X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2013 13:12:47 -0000 On Tue, May 07, 2013 at 08:51:55AM +0200, Vlad Dinculescu wrote: > Thanks for the reply, please see responses inline below. > > On 07 May 2013, at 8:33 AM, Francisco Obispo wrote: > > > Hi Vlad, > > > > What are the problems you're trying to address with these measures? > > Simply put, we are attempting to avoid registrars performing updates > on Contact information that are not authorised or requested by the > Contact. We have found that "bringing out the big stick" doesn't work > effectively, so now we are attempting to put the decision making where > it belongs, in the hands of the registrant. As Michele wrote (albeit in different terms), that's a sociological problem, not a technical problem. By necessity, the registrar has to be a trusted intermediary between the registrant and the registry. If a registrar is being that abusive, then the solution is to remove their accreditation, not to place roadblocks in front of those registrars who behave themselves. An alternative might be this: allow registrars to submit whatever updates they want, but if the changes trigger some heuristic, hold the change for review and rather than responding with a 1000 response code, respond with 1001, thus indicating that the change has been held for review. Later, assuming you implement the message queue, you can put a message on the message queue either confirming or denying the update request (SS3.3 of RFC 5733). That leaves it up to you how you implement the review process, which could be done on your end or by contacting the existing contact to confirm the request, or whatever. Just a suggestion. K. -- Keith Gaughan, Development Lead PGP/GPG key ID: 82AC3634 Blacknight Internet Solutions Ltd. 12A Barrowside Business Park, Carlow, Ireland Registered in Ireland, Company No.: 370845 From fobispo@isc.org Thu May 9 22:07:34 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F235821F8E5F for ; Thu, 9 May 2013 22:07:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.649, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GZzshlF6b5TK for ; Thu, 9 May 2013 22:07:32 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 37F2221F8D92 for ; Thu, 9 May 2013 22:07:32 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 2E352C949D for ; Fri, 10 May 2013 05:07:26 +0000 (UTC) (envelope-from fobispo@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1368162451; bh=WjEWwJyow6rpXmRwRtsYDLcyIyzzyE2US7BfAVgUwb8=; h=From:Subject:Date:To; b=ZuHGN2yUhLGWo888PqUcgQucLzVtjVXIEFc8HVD5fddQ9GIj/slkzdhDP4csYFXeX U8RNaELBn1SZhanMhIxUoqjEYEEzZnKLprKfcA4A18SPJvhtvdwwVWZHFPzjLTXR3o m37S52yFechd4bMaP7Sv1G9GgLZhoXyahNPgYqiY= Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS for ; Fri, 10 May 2013 05:07:26 +0000 (UTC) (envelope-from fobispo@isc.org) Received: from [192.168.255.120] (c-24-7-39-79.hsd1.ca.comcast.net [24.7.39.79]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 0A126216C40 for ; Fri, 10 May 2013 05:07:26 +0000 (UTC) (envelope-from fobispo@isc.org) From: Francisco Obispo Content-Type: multipart/alternative; boundary="Apple-Mail=_6E066579-BF6D-459B-8F01-224B91FF0367" Message-Id: Date: Thu, 9 May 2013 22:07:25 -0700 To: "provreg@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) X-DCC--Metrics: post.isc.org; whitelist Subject: [provreg] Launchphase and X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 05:07:34 -0000 --Apple-Mail=_6E066579-BF6D-459B-8F01-224B91FF0367 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii We're currently implementing the launchphase extentension. In my opinion the Claims Check system should use the section = and not the The reason for my reasoning has to do with RFC5730 and: 2.9.2.1. EPP Command The EPP command is used to determine if an object can be provisioned within a repository. It provides a hint that allows a client to anticipate the success or failure of provisioning an object using the command as object-provisioning requirements are ultimately a matter of server policy. Referring to "Objects", however launch-1.0 is an extension, or at least = is handled in EPP like one, so my belief is that the response should go = into the section: S: S: S: S: S: Command completed successfully S: S: S: S: claims S: S: example1.tld S: S: S: example2.tld S: abc123 S: S: S: S: S: ABC-12345 S: 54321-XYZ S: S: S: SHOULD BE: S: S: S: S: S: Command completed successfully S: S: S: S: claims S: S: example1.tld S: S: S: example2.tld S: abc123 S: S: S: S: S: ABC-12345 S: 54321-XYZ S: S: S: The main reasoning behind this, is that some systems (including ours) = expect extensions to write on the section and NOT in the = rest of the document. Having extensions that behave like "objects" could lead to unnecessary = processing and confusion. Does anyone feel the same? Francisco Obispo=20 Director of Applications and Services - ISC email: fobispo@isc.org Phone: +1 650 423 1374 || INOC-DBA *3557* NOC PGP KeyID =3D B38DB1BE --Apple-Mail=_6E066579-BF6D-459B-8F01-224B91FF0367 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

2.9.2.1. =  EPP <check> = Command


   The EPP <check> command is used to determine if an = object can be
   provisioned within a = repository.  It provides a hint that allows = a
   client to anticipate the success or = failure of provisioning an object
  =  using the <create> command as object-provisioning = requirements are
   ultimately a matter = of server = policy.


R= eferring to "Objects", however launch-1.0 is an extension, or at least = is handled in EPP like one, so my belief is that the response should go = into the <extension> section:

  =  S:<?xml version=3D"1.0" encoding=3D"UTF-8" = standalone=3D"no"?>
   S:<epp = xmlns=3D"urn:ietf:params:xml:ns:epp-1.0">
   S: =  <response>
   S:    <result = code=3D"1000">
   S:     = <msg>Command completed successfully</msg>
  =  S:    </result>
   S:   =  <resData>
   S:     = <launch:chkData
   S:     =  xmlns:launch=3D"urn:ietf:params:xml:ns:launch-1.0">
&nb= sp;  S:     =  <launch:phase>claims</launch:phase>
  =  S:      <launch:cd>
   S: =        <launch:name = exists=3D"0">example1.tld</launch:name>
  =  S:      </launch:cd>
  =  S:      <launch:cd>
   S: =        <launch:name = exists=3D"1">example2.tld</launch:name>
  =  S:       =  <launch:claimKey>abc123</launch:claimKey>
&nbs= p;  S:      </launch:cd>
  =  S:     </launch:chkData>
   S: =    </resData>
   S:   =  <trID>
   S:     = <clTRID>ABC-12345</clTRID>
   S:   =   <svTRID>54321-XYZ</svTRID>
   S: =    </trID>
   S: =  </response>
  =  S:</epp>

SHOULD = BE:

   S:<?xml version=3D"1.0" = encoding=3D"UTF-8" standalone=3D"no"?>
  =  S:<epp = xmlns=3D"urn:ietf:params:xml:ns:epp-1.0">
   S: =  <response>
   S:    <result = code=3D"1000">
   S:     = <msg>Command completed successfully</msg>
  =  S:    </result>
   S:   =  <extension>
   S:     = <launch:chkData
   S:     =  xmlns:launch=3D"urn:ietf:params:xml:ns:launch-1.0">
&nb= sp;  S:     =  <launch:phase>claims</launch:phase>
  =  S:      <launch:cd>
   S: =        <launch:name = exists=3D"0">example1.tld</launch:name>
  =  S:      </launch:cd>
  =  S:      <launch:cd>
   S: =        <launch:name = exists=3D"1">example2.tld</launch:name>
  =  S:       =  <launch:claimKey>abc123</launch:claimKey>
&nbs= p;  S:      </launch:cd>
  =  S:     </launch:chkData>
   S: =    </extension>
   S:   =  <trID>
   S:     = <clTRID>ABC-12345</clTRID>
   S:   =   <svTRID>54321-XYZ</svTRID>
   S: =    </trID>
   S: =  </response>
  =  S:</epp>



The main reasoning behind this, is that some systems (including = ours) expect extensions to write on the <extension> section and = NOT in the rest of the document.

Having = extensions that behave like "objects" could lead to unnecessary = processing and confusion.

Does anyone feel the = same?


Francisco= Obispo 
Director of Applications and Services - ISC
email: = fobispo@isc.org
Phone: +1 650 = 423 1374 || INOC-DBA *3557* NOC
PGP KeyID =3D = B38DB1BE

= --Apple-Mail=_6E066579-BF6D-459B-8F01-224B91FF0367-- From provreg@contact.dotandco.com Fri May 10 04:06:03 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ADFF21F8629 for ; Fri, 10 May 2013 04:06:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iUyorQpSbz8x for ; Fri, 10 May 2013 04:05:58 -0700 (PDT) Received: from mail.dotandco.com (triglav.dotandco.com [194.242.114.22]) by ietfa.amsl.com (Postfix) with ESMTP id 221FF21F84DC for ; Fri, 10 May 2013 04:05:57 -0700 (PDT) Received: from triglav.dotandco.com (localhost.localdomain [127.0.0.1]) by mail.dotandco.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id r4AB3tF5015973; Fri, 10 May 2013 13:03:55 +0200 Received: (from patrick@localhost) by triglav.dotandco.com (8.14.3/8.14.3/Submit) id r4AB3tP5015971; Fri, 10 May 2013 13:03:55 +0200 X-Authentication-Warning: triglav.dotandco.com: patrick set sender to provreg@contact.dotandco.com using -f Date: Fri, 10 May 2013 13:03:54 +0200 From: Patrick Mevzek To: Francisco Obispo Message-ID: <20130510110354.GA19501@home.patoche.org> References: <20130506191809.8585.25818.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: Dot And Co User-Agent: Mutt/1.5.20 (2009-06-14) X-Greylist: Sender is SPF-compliant, not delayed by milter-greylist-3.0 (mail.dotandco.com [127.0.0.1]); Fri, 10 May 2013 13:03:55 +0200 (CEST) Cc: "provreg@ietf.org" Subject: Re: [provreg] New Version Notification for draft-obispo-epp-idn-03.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 11:06:03 -0000 Hello Francisco, Francisco Obispo 2013-05-06 21:19 > Just updated the draft to the latest comments/suggestions. Thanks for that. Net::DRI has already been released last week with support for -02. I've already updated my working tree with your new -03 version. -- Patrick Mevzek From fobispo@isc.org Sat May 11 08:44:48 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07AC321F8FF2 for ; Sat, 11 May 2013 08:44:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J2-5cop+04Qg for ; Sat, 11 May 2013 08:44:47 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 6B5D321F8F2C for ; Sat, 11 May 2013 08:44:47 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 9AC43C949D for ; Sat, 11 May 2013 15:44:33 +0000 (UTC) (envelope-from fobispo@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1368287084; bh=ZMOjfVEVoKXzc2EJiN28RFWCqxiXkiPD8vOgLihJLC8=; h=From:Subject:Date:To; b=uJLzQO6RGn/LCE36W5U7X1lPmt1/7hj1NQFHzHXeUa3H5K4V7jW6nJPGHM2naC1Ux siLJ/DPlGfqwI0D+iXGsbqmgvdjSc6qnMPiL2FIv3mVoP6/0kuUKrnfW4ic7rmN1Vp 7Ic4kfsYimuhhMkUfamnaPxT+EmsqrCKfYDm2sYw= Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS for ; Sat, 11 May 2013 15:44:33 +0000 (UTC) (envelope-from fobispo@isc.org) Received: from [192.168.255.120] (c-24-7-39-79.hsd1.ca.comcast.net [24.7.39.79]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 8043D216C40 for ; Sat, 11 May 2013 15:44:33 +0000 (UTC) (envelope-from fobispo@isc.org) From: Francisco Obispo Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Sat, 11 May 2013 08:44:34 -0700 To: "provreg@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) X-DCC--Metrics: post.isc.org; whitelist Subject: [provreg] Path to standard? X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 May 2013 15:44:48 -0000 How are we going to pursue standardization of the Launchphase and IDN = drafts? I'm in the process of registering the namespace for the IDN extension, = but I'm thinking about how to make sure it all stays "current" after the = draft expires. Can someone explain what is the process? Francisco Obispo=20 Director of Applications and Services - ISC email: fobispo@isc.org Phone: +1 650 423 1374 || INOC-DBA *3557* NOC PGP KeyID =3D B38DB1BE From ajs@anvilwalrusden.com Sun May 12 08:12:57 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CCA921F8E3C for ; Sun, 12 May 2013 08:12:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.84 X-Spam-Level: X-Spam-Status: No, score=-0.84 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zB4xfp47+Dm3 for ; Sun, 12 May 2013 08:12:51 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 7F7DB21F8D14 for ; Sun, 12 May 2013 08:12:51 -0700 (PDT) Received: from mx1.yitter.info (dhcp-26-25.ripemtg.ripe.net [193.0.26.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 5C3208A031 for ; Sun, 12 May 2013 15:12:49 +0000 (UTC) Date: Sun, 12 May 2013 11:12:41 -0400 From: Andrew Sullivan To: provreg@ietf.org Message-ID: <20130512151240.GA14651@mx1.yitter.info> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [provreg] Path to standard? X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 May 2013 15:12:57 -0000 On Sat, May 11, 2013 at 08:44:34AM -0700, Francisco Obispo wrote: > How are we going to pursue standardization of the Launchphase and IDN drafts? > > I'm in the process of registering the namespace for the IDN extension, but I'm thinking about how to make sure it all stays "current" after the draft expires. > Why not take the draft to RFC? The natural way to do this would be as an AD sponsored submission, or perhaps by one of the area WGs (APPSAWG, perhaps?). A -- Andrew Sullivan ajs@anvilwalrusden.com From shollenbeck@verisign.com Mon May 13 04:07:55 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3C7521F94CC for ; Mon, 13 May 2013 04:07:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I7QRvA6v3JYy for ; Mon, 13 May 2013 04:07:50 -0700 (PDT) Received: from exprod6og123.obsmtp.com (exprod6og123.obsmtp.com [64.18.1.241]) by ietfa.amsl.com (Postfix) with ESMTP id A05DA21F94A6 for ; Mon, 13 May 2013 04:07:44 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob123.postini.com ([64.18.5.12]) with SMTP ID DSNKUZDJgEquH84L0aAdQE7VXH7kH6KKJN7L@postini.com; Mon, 13 May 2013 04:07:49 PDT Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id r4DB7bpi019233 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 13 May 2013 07:07:41 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Mon, 13 May 2013 07:07:36 -0400 From: "Hollenbeck, Scott" To: Francisco Obispo , "provreg@ietf.org" Thread-Topic: [provreg] Path to standard? Thread-Index: AQHOTl562xwPVS3c5kuNbbroGuM3qpkC9flg Date: Mon, 13 May 2013 11:07:35 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F243852B1@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [provreg] Path to standard? X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 11:07:55 -0000 > -----Original Message----- > From: provreg-bounces@ietf.org [mailto:provreg-bounces@ietf.org] On > Behalf Of Francisco Obispo > Sent: Saturday, May 11, 2013 11:45 AM > To: provreg@ietf.org > Subject: [provreg] Path to standard? >=20 > How are we going to pursue standardization of the Launchphase and IDN > drafts? >=20 > I'm in the process of registering the namespace for the IDN extension, > but I'm thinking about how to make sure it all stays "current" after > the draft expires. >=20 > Can someone explain what is the process? The process is described in detail in RFCs 2026 and 5742. As Andrew noted, = the next step will be to find an interested applications area director. Scott From JGould@verisign.com Tue May 14 09:43:59 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D30A021F8B2B for ; Tue, 14 May 2013 09:43:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.598 X-Spam-Level: X-Spam-Status: No, score=-5.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RS4UzjzXeLuU for ; Tue, 14 May 2013 09:43:54 -0700 (PDT) Received: from exprod6og125.obsmtp.com (exprod6og125.obsmtp.com [64.18.1.218]) by ietfa.amsl.com (Postfix) with ESMTP id 1576321F9121 for ; Tue, 14 May 2013 09:43:50 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob125.postini.com ([64.18.5.12]) with SMTP ID DSNKUZJpxnckH/0i/IlfMuI+66t4GiEIvMCC@postini.com; Tue, 14 May 2013 09:43:53 PDT Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02.vcorp.ad.vrsn.com [10.173.152.206]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id r4EGhgL4028560 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 14 May 2013 12:43:47 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Tue, 14 May 2013 12:43:42 -0400 From: "Gould, James" To: Francisco Obispo , "provreg@ietf.org" Thread-Topic: [provreg] Launchphase and Thread-Index: AQHOTTxKlGCENab8wkWALaOIo5pI85kE6eIA Date: Tue, 14 May 2013 16:43:41 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.173.152.4] Content-Type: multipart/related; boundary="_004_CDB7DD824F97Bjgouldverisigncom_"; type="multipart/alternative" MIME-Version: 1.0 Subject: Re: [provreg] Launchphase and X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 May 2013 16:43:59 -0000 --_004_CDB7DD824F97Bjgouldverisigncom_ Content-Type: multipart/alternative; boundary="_000_CDB7DD824F97Bjgouldverisigncom_" --_000_CDB7DD824F97Bjgouldverisigncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Francisco, I believe what you propose makes sense. Changing to use the se= ction instead of the section does fall in line better with an ext= ension, but does represent an impactful, non-backward compatible change to = the draft text. I would like to hear from the community of the impacts of = making this proposed change at this point. I have a version of the draft c= reated that includes the requested change on GitHub at the URL https://gith= ub.com/james-f-gould/EPP-Launch-Phase-Extension-Specification.git for revie= w. Please let me know publicly or privately if you support or don't suppor= t this change. If this is supported, the hope is that draft 11 is the cand= idate draft to move forward with; otherwise draft 10 is the candidate draft= to move forward with. Splintering the versions that the servers implement= is very undesirable, so please provide your feedback. Thanks, -- JG [cid:C52435F1-F67B-4EC0-8F83-03FB0E79EBE3] James Gould Principal Software Engineer jgould@verisign.com 703-948-3271 (Office) 12061 Bluemont Way Reston, VA 20190 VerisignInc.com From: Francisco Obispo > Date: Friday, May 10, 2013 1:07 AM To: EPP Provreg > Subject: [provreg] Launchphase and We're currently implementing the launchphase extentension. In my opinion the Claims Check system should use the section an= d not the The reason for my reasoning has to do with RFC5730 and: 2.9.2.1. EPP Command The EPP command is used to determine if an object can be provisioned within a repository. It provides a hint that allows a client to anticipate the success or failure of provisioning an object using the command as object-provisioning requirements are ultimately a matter of server policy. Referring to "Objects", however launch-1.0 is an extension, or at least is = handled in EPP like one, so my belief is that the response should go into t= he section: S: S: S: S: S: Command completed successfully S: S: S: S: claims S: S: example1.tld S: S: S: example2.tld S: abc123 S: S: S: S: S: ABC-12345 S: 54321-XYZ S: S: S: SHOULD BE: S: S: S: S: S: Command completed successfully S: S: S: S: claims S: S: example1.tld S: S: S: example2.tld S: abc123 S: S: S: S: S: ABC-12345 S: 54321-XYZ S: S: S: The main reasoning behind this, is that some systems (including ours) expec= t extensions to write on the section and NOT in the rest of the= document. Having extensions that behave like "objects" could lead to unnecessary proc= essing and confusion. Does anyone feel the same? Francisco Obispo Director of Applications and Services - ISC email: fobispo@isc.org Phone: +1 650 423 1374 || INOC-DBA *3557* NOC PGP KeyID =3D B38DB1BE --_000_CDB7DD824F97Bjgouldverisigncom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Francisco, 

I believe what you propose makes sense.  Changing to use the <= extension> section instead of the <resData> section does fall in l= ine better with an extension, but does represent an impactful, non-backward= compatible change to the draft text.  I would like to hear from the community of the impacts of making this proposed change a= t this point.  I have a version of the draft created that includes the= requested change on GitHub at the URL https://github.com/james-f-gould/EPP-Launch-Phase-Extension-Specification.g= it for review.  Please let me know publicly or privately if y= ou support or don't support this change.  If this is supported, the ho= pe is that draft 11 is the candidate draft to move forward with; otherwise draft 10 is the candidate draft to move forward wi= th.  Splintering the versions that the servers implement is very undes= irable, so please provide your feedback.  

Thanks,

-- 

 

JG

 

 

James Gould

= Principal Software Engineer

j= gould@verisign.com

=  

= 703-948-3271 (Office)

= 12061 Bluemont Way

= Reston, VA 20190

VerisignInc.com


From: Francisco Obispo <fobispo@isc.org>
Date: Friday, May 10, 2013 1:07 AM<= br> To: EPP Provreg <provreg@ietf.org>
Subject: [provreg] Launchphase and = <check>

We're currently implementing the launchphase extentension.

In my opinion the Claims Check system should use the <extension>= section and not the <resData>

The reason for my reasoning has to do with RFC5730 and:

2.9.2.1.  EPP <check> Command


   The EPP <check> command is used to determine if an = object can be
   provisioned within a repository.  It provides a hint= that allows a
   client to anticipate the success or failure of provisioni= ng an object
   using the <create> command as object-provisioning r= equirements are
   ultimately a matter of server policy.


Referring to "Objects", however launch-1.0 is an extension, = or at least is handled in EPP like one, so my belief is that the response s= hould go into the <extension> section:

   S:<?xml version=3D"1.0" encoding=3D"UTF= -8" standalone=3D"no"?>
   S:<epp xmlns=3D"urn:ietf:params:xml:ns:epp-1.0&qu= ot;>
   S:  <response>
   S:    <result code=3D"1000">
   S:     <msg>Command completed successfull= y</msg>
   S:    </result>
   S:    <resData>
   S:     <launch:chkData
   S:      xmlns:launch=3D"urn:ietf:para= ms:xml:ns:launch-1.0">
   S:      <launch:phase>claims</lau= nch:phase>
   S:      <launch:cd>
   S:        <launch:name exists=3D&q= uot;0">example1.tld</launch:name>
   S:      </launch:cd>
   S:      <launch:cd>
   S:        <launch:name exists=3D&q= uot;1">example2.tld</launch:name>
   S:        <launch:claimKey>abc1= 23</launch:claimKey>
   S:      </launch:cd>
   S:     </launch:chkData>
   S:    </resData>
   S:    <trID>
   S:     <clTRID>ABC-12345</clTRID>
   S:     <svTRID>54321-XYZ</svTRID>
   S:    </trID>
   S:  </response>
   S:</epp>

SHOULD BE:

   S:<?xml version=3D"1.0" encoding=3D"UTF= -8" standalone=3D"no"?>
   S:<epp xmlns=3D"urn:ietf:params:xml:ns:epp-1.0&qu= ot;>
   S:  <response>
   S:    <result code=3D"1000">
   S:     <msg>Command completed successfull= y</msg>
   S:    </result>
   S:    <extension>
   S:     <launch:chkData
   S:      xmlns:launch=3D"urn:ietf:para= ms:xml:ns:launch-1.0">
   S:      <launch:phase>claims</lau= nch:phase>
   S:      <launch:cd>
   S:        <launch:name exists=3D&q= uot;0">example1.tld</launch:name>
   S:      </launch:cd>
   S:      <launch:cd>
   S:        <launch:name exists=3D&q= uot;1">example2.tld</launch:name>
   S:        <launch:claimKey>abc1= 23</launch:claimKey>
   S:      </launch:cd>
   S:     </launch:chkData>
   S:    </extension>
   S:    <trID>
   S:     <clTRID>ABC-12345</clTRID>
   S:     <svTRID>54321-XYZ</svTRID>
   S:    </trID>
   S:  </response>
   S:</epp>



The main reasoning behind this, is that some systems (including ours) = expect extensions to write on the <extension> section and NOT in the = rest of the document.

Having extensions that behave like "objects" could lead to u= nnecessary processing and confusion.

Does anyone feel the same?


Francisco Obispo 
Director of Applications and Services - ISC
email: fobispo@isc.org
Phone: +1 650 423 1374 || INOC-DBA *3557* NOC
PGP KeyID =3D B38DB1BE

 --_000_CDB7DD824F97Bjgouldverisigncom_-- --_004_CDB7DD824F97Bjgouldverisigncom_ Content-Type: image/png; name="8A7A655D-9ED0-4D38-898D-E9E8B754666E[3].png" Content-Description: 8A7A655D-9ED0-4D38-898D-E9E8B754666E[3].png Content-Disposition: inline; filename="8A7A655D-9ED0-4D38-898D-E9E8B754666E[3].png"; size=4109; creation-date="Tue, 14 May 2013 16:43:41 GMT"; modification-date="Tue, 14 May 2013 16:43:41 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAEkAAABACAIAAADZHs1DAAAP1ElEQVRoBe2aa3CU1RnHN3vLJtmQ hEtiwlUBtZUUCiU6tU7wVhinjOB0xmJnFIdpO1Y6DY586Iwdo36gLc4Iip3pVAL9IKjTDnhDEEWC 1GoICHLRctEkXHIPuZHr7qa/c553T152N9lsNvnWM5nDec97Ls//+T+X854lZWBgwDFuRRaXOiUl hX2kHrcNr1vYfd1T0g/ACIVCQV0CgQD/8miwOZ1Ol8vldrupKTyOK9QU2ThpUA4w9Pf39/X19fT0 UCsYYHA6QcLiYKCwF2MEMNh8Pp/X6/V4PAxOXoDoFcYAG7ICplsXNvClpSFvipAimGy1wQmrMgV4 aUzxekEbLV8yPUlhE66u6YJkqT6fMjKDyjRs2GgaeNKA587OTqZnZGSMLYejx4biEautrQ3eUlNT LUiCx6AyjWHhAbKrqwuEwMNQxYyTYUzmjhIbboMo7e3tyIwoMYA5nZ+duXiyur6ju88u5ZL5s+ff mJ+TmUan4JUGNVbQ2tqKNvx+PwTaZ42uPRpseBeoYMygUvRoijp7AnuPXdhz9PyeyvPI7khxqtoU yTcDofk35j1674LH7luY7U8zVsoo2qgMc5gwYQIeaOaNrpEwNoCBqraujgBALDeoOnr6X9t/4rX9 x9t7gg6Xx+F0K1QEQOBRFKoBVYdCjoGgI6T+MtO9j9+74Nlf3gNChhiQHR0dwMvKykoSXmLYMEUY u3T5MoyxMZEDbJTK81fWlR242NrrcHsdToBpSBZpsKeps0gDocYWDDhC6i8zzbO9ZOWKH38/Ah5K hL1kjDMBbMQMDKa6pgaE6enpggp4r+z5cvOeLx0en6bLpRkTbIKKWjGnijoCgQ3qdB3sdwR6FcJg 8NF7Crc99XNeG/ZQIvkQ3xt1bhgpNrYhlMFYY0NDVna2Bczp/MPrh3dVVjncAHOrvxSwuSw3U3SF SVPIxDKpBVuYQOABMtg3f+aUA39aY/fApqYmLB89CmBZY+T1SA8EcIWb1dfXk8QIaFIUsKM1Dk+a w+1xuLQ1Ag9s1p9uC9rBTk2sUoRLq8Ojp6cy/UR100MvvK41oPkdGMjJySF3svXI8dhHjggbSDhD ED8wSxgTYLsqLihgbsRCULBp3gghBobyN5AY33NalKoeuA2rgInYs1rHU37m4rq/vW/gsReZk63Z 0S70CNsjwiakNTU2etxuAXax5dpf3juuuBJgFiQtPdgUKv3n1DZpPdrawFPDwvBoW/C8L79bceD4 eQOPcELMHB118bHhab29vYq0UIhjvGB77p+VHeRk7MpCIn5lgobRrHY5noCnQgrD5JX5sJJOPZ0Y q/h3rdn0NpsaePgbAkiPWXckjfjfOJytMHrcmngltnGsqqmyqllZUYozK82z4MY8tZNYmtnT6T5+ saWtV1DpXuARRYLB4ltyVWw0hZRA4VDS1Xfiu3pe1TR3vLDz4B9XLSGEAIlw0tzcTJ1oPoiPDXto uXoVzfkzM/kyQ4y/f3JW0QVpig3H7vXLJfkqEW3l4OlLd/95n7JbU0KB4rkTDz6z3HTYGyVlH5+o alTjQ6FtHx575hfFvAUeXodaESNRbHFsErWRQxsaGpRBpqRQX2ru/LKmRScxZZBtnd0lr31oF9G0 l9w2rfjmXJWppdDo79n+xL1mgL1RVd+6+f1jWmUq9dc0tb/z+TfsTmEYB2jEkLZ91vDtONgwQhgj ZavPaf1N/enZegUM3uTP7f3Hga8OnqyKuc323xQ7OH9ICQaefWjRrCkTYo5c/fK7yshlTXVkc739 +RlGanQDREvEEI+IOT1mZxxsBH0WlfO+uioIhQ6dbdSuhffrUI5Aqf7SNz6NuTpInl2xQHlXKJDl CZU8sCDmsN1fnC0/16wCiVqTU6jS3cGvqoUoakk87B9z+lCdcbChKoAJY7SBV9PUobMTE3VwQ9Me X/nXtds/Ph5zj5JlhVk+J2erTY/+JDvDF3tM2ceaNI41kjzw5BTMsrWzx8DD8caBt76+YEDZlaYt 1N4bUqo1fyBE39700rf+09rZHS16dkbqplWL5xf4Vy9Rp+HoUvrG4eo2/emgzmgUWVzBO/Fdrdgk vZjlGPPG0nClCVP1uXpIE6qtPKVBOtF6dUv3pt2faeEiK1Bt/+39kb36ufVaz6YPz6jEDf+WvvQL Mor+WhVsSozwfVnMdWJ2DpcDZF0MElj9+kKuvZuERdEJ16p1B/nAk/bcv46svn/RrLxs3XVdBaUp KzYoR7UX1IS7qg+I62+BLALVUGSQGQbkyM/N129m31jnFukQ3kBoey9bWhuTudWXmze9ZOsQ+aBw 1oN3znOkZTsyJg3+pecQh3QCDFvB4AaqR1NlgZI3IwfG+OGwqdda0xg6qRPjnJGdqveIAKb7OBx6 fG8frR4qH2xaXZzl12diuDJ/KjbiYNevqriytGboMsLooSOq4mBDT1wbWLwFgz5sx3xZyh1B2GaU fDqolJR9FHNn8kHJT2+77rRlH6ew8EUnqHRjYGD65Ex1Ka0Lyk2INJaLg43DzqRJk8BG4WQAgd/L y9ASKFfQsoWl4UH7z4lL7cPkg5k5sdKAAFPLWahYnNuU6ZMnWDFkYEBpOcIt9fbDVHGwyRcUVyNg 6+ntxeVmT0pVx6jBb2cjjd6FtOtJKyk7MFQ+KF35Qz6xBwViHWV++m9wzRD03nXrVIs09tZxUhxk cG68VhxsqIrEkpOdDWPwxi43TUzVt1TcC+g/uyHRxnncqW39rtK3hsgHxbfOn04g1WFJARNcRkE0 9LKh4AOL5hjSerq7EWOMecMSIC0/Px9UwOMzceE0/+QMtyUBcqg7Of5EOK1Jwo/Ht/m9So6/0Zol oVXVNmueBJidNFmKNdVF2LKFsxVvmjTUihhj7G8GG1KyC2dLEN4xw69ub7QEgyAlDIgT6qCijr9R pfTNf7f1Ch4YE1O0kabW5Nqr/+E7b8HfLN50Khh7bMjGVSQ2mX/DDRBHsEKFS+dOSHMNqAO+OgSL 74VVrkxUZUYss/ybuoh8UNXYvnnfaXUNQRkExly9iFpKX10G+p56sMgAQ6EYJGJEKSpORxx/YzZW zlf9DwoL+aUQeHyDp7oGfnW7/nYWNataY6OWBtN0UFm95QP7/qu37FUpnnAKfqWFsEbURI0KfQFs +aJpE/3GIFEoAiTqbEoE+95DtbGHvLy8adOmCTwunublehfc4NWWGWZPtG6FUO1Lbm91c9emdypk WT7DYVJhpoijGkiWjrilDMzLz/j9zxYpLwt7mvwEOZRsw/SPCBs649ejosWLyePA69W/jD6+aNL0 TKe+NhV42j5F/cKeTnelbx6WfKDcT04h8lZpQXOlv+5knUxP8K+/vl9QCTyiCVuPgjQwu0pLS4eB Lq+IKOQWNiDF1dXVYVB89fi8njtmZp6u62rvjfpk5IwiQcXh6O3rr2u6WtXQ/mZFtcKmStjBFHth eMFApjuwY+19N+XlMEIdwrjCCAYzMzPBlmhmU5uwAIqRVtyaKNLS0rJv//5Lly6xGT/iZPj9AYfr xU8bLnaElNzqRkDukuUTUx8TddxT0UUNIHnoqIizKfYEWBBVwdi2J+6bN30SK8tPKMjD3dbEiRPx iLiyxRyQADa0QH6rra19b88efkayw3v3m7aPLnQp0YmB6kssjA1IFKU+/cVptXUUUf7JlZ6y5x/N yN782J1ZGT4FTBcuDjP9fo57OFuiac3gTAAbc/ABAsmV2toP9u418Pgxghh9rrlv29Hmpi5NINjI 4NQUqa0NNWkqPMIbpAVmZPseL5774KJZYVBwlkLQz87Kys3NhTf6ramJ/5MYNtYHHj/ocM1sh+f2 eOTHpM8vdh3+ruPrhm7NXvhT2vqGYbZgA1VozpSMh4tmLl84w6CiweJYfu4UVYj7yQBjs4SxCTzY u3r16ifl5TU1NUigfkB1uVAzJkTIaekOfl3f9d/G3sbOvsZr/U3X1HVLps81c2J6flba3Dz/XTfn FWSnMYW5jBcM5DHaBfn5+FiSjLEdZTTYmCYK5grs9JkzlZWVJAaBh5QKIeda/R9nlNxadgEgtYUG VBqZOqeyXCgEpKkFBfJLt6DVEo6+GiU2NiS04PHYZ0Nj4+lTp85duECXoYIjEgg9/LcfQBqcNpaY TgEXMPhpG1Rgww6ZOOrgEaGG0WOThYRAEDa3tJw/f/7Ct98SCTQfihXT4AGcBApmCXtkTMATCfNy c/kNEVTEesZHyJfMY7LYZG/Uj7eQIQBZ39DAz6tkQvXY3W2HRxuLJeqo+D55MkdwIOGi/IgB4GRg xJw7NthkaTgUkPK5QI3R0kM/AwQkJgcSKKKmCIcxJUu+cyyxGWnEl4BEkTav8CIKCCnSNuPHqTEu 2MZJ1kSXHUvfTXTv8R7/f2zjreHxWT/hS4hkxLhy5QqHNVaYOnUqoX/4pS5wGNCFnE4CHH5wzLfu jS++eOXyZd5t2LBB9tu9e3d5eTk9a9as2bp1a/S0tWvXzp49+9VXXyVZ298iRFFR0dKlS+k0b196 6SUeQcVSJD0znpErV65kRzBs2bKF/mXLlsncYQYzbN26ddQFU6euf/ppGma6SLVz586TJ0/Sj/DO 24uKaFGki8Y5LTFJdt68efrNSCtE37t376lTp6InRABjQEVFxfPPP09+jxgMMKCKFpCBIoNf0fjN YPg4dOiQeTQNVIZRiHW4CwsLd+3axTtIWLx4Mad7oZF+M2HOnDlPPvmkeYxoGGY2btzIK4SOUAqq FVmLi4tXrFgBHlTAMFQbbZm8EskeeeQR5GFBoYKLtoh9GQmSiE4MyojqxpThFzzwtmrVKmNmdmxI tm/fPrOKWI55lAYGKQ2RLOKtPLIFPKBXZALkUGPoRyQBRhupMNdol2MjWImGZ5ZVsQSzZBBDsQex TCSw616MzcyJwIZr8UqYoQHJZqQ00KWoz74OW+BvBkDEFGEJecSm5C3jCwoKpM10BIZ8NBUx1zwq bMYsASa82UljgCjbzIloGKrpR4sYXsQAHn+3di0mhCeLwdODZDt27IjYyEzkrYyxLy6dMoaNkNau LDPXNBQ2Y5Zsb2aaETTQjTFie7+0MZivTp4UoQEW7UIyTJyNNmywkRjIZR2i7WsKIbzFaNmX6McY O3syWGgnRNkB29ehbZ1LltiUjedgRfZxfKoQD0xBOPtbTPShlSulJ1oI+omchEQizZEjR4hV9PCx J+ONl8ojtTAJIWVlZYL8iwrrZtqMkQZeE23/9jGKN4rdNuxteQsnkoLkMTpsogtmiUmDxO6rTEG1 ol2MUFaQGrvCZIyjSidWwDqMp6bYx0e3iaVoLbpfeixsGBI2I3qyR56YihH3jXBiHF0AIBDY7G8J GPDDecDIyiO7SEzCumQX4RC069evh38ZzFsEE6+jjdARg9GF/a0d5/8ActOtScHpPCkAAAAASUVO RK5CYII= --_004_CDB7DD824F97Bjgouldverisigncom_-- From fobispo@isc.org Tue May 14 12:38:27 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE6A021F90F1 for ; Tue, 14 May 2013 12:38:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IHqCUs70JzZY for ; Tue, 14 May 2013 12:38:17 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id EAA3F21F90B9 for ; Tue, 14 May 2013 12:38:16 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id B345FC9423; Tue, 14 May 2013 19:38:06 +0000 (UTC) (envelope-from fobispo@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1368560295; bh=e7LoW8hRMuhRSatWZ3kerH1ElsIqI+hWhShzPGok3FM=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=O5QXz9wSzV9QoXbIc4GTdAZl0snPt133PU0ojdTjtYWzsp/+37pBcD2fHDboGjgxX gSwHzvE2EtRKwtrSsK4YScjFIpqI6gJ02Bz5b0Cl1SEvu0IEXYyEez8ggATxLv8I27 7OjSLJ5Uptvfj0xkAFcMBgMGKN/fK6NmoiBlHiFk= Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS; Tue, 14 May 2013 19:38:06 +0000 (UTC) (envelope-from fobispo@isc.org) Received: from [IPv6:2001:4f8:3:64:99da:2f63:f6cf:ce0] (unknown [IPv6:2001:4f8:3:64:99da:2f63:f6cf:ce0]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id A7502216C40; Tue, 14 May 2013 19:38:06 +0000 (UTC) (envelope-from fobispo@isc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Francisco Obispo In-Reply-To: Date: Tue, 14 May 2013 12:38:05 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Gould, James" X-Mailer: Apple Mail (2.1503) X-DCC--Metrics: post.isc.org; whitelist Cc: "provreg@ietf.org" Subject: Re: [provreg] Launchphase and X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 May 2013 19:38:27 -0000 Thanks for taking this into consideration. I believe this is the right thing to do, and now is the right time to = fix it. Francisco On May 14, 2013, at 9:43 AM, "Gould, James" wrote: > Francisco,=20 >=20 > I believe what you propose makes sense. Changing to use the = section instead of the section does fall in line = better with an extension, but does represent an impactful, non-backward = compatible change to the draft text. I would like to hear from the = community of the impacts of making this proposed change at this point. = I have a version of the draft created that includes the requested change = on GitHub at the URL = https://github.com/james-f-gould/EPP-Launch-Phase-Extension-Specification.= git for review. Please let me know publicly or privately if you support = or don't support this change. If this is supported, the hope is that = draft 11 is the candidate draft to move forward with; otherwise draft 10 = is the candidate draft to move forward with. Splintering the versions = that the servers implement is very undesirable, so please provide your = feedback. =20 >=20 > Thanks, >=20 > --=20 > =20 > JG > =20 > <8A7A655D-9ED0-4D38-898D-E9E8B754666E[3].png> > =20 > James Gould > Principal Software Engineer > jgould@verisign.com > =20 > 703-948-3271 (Office) > 12061 Bluemont Way > Reston, VA 20190 > VerisignInc.com >=20 > From: Francisco Obispo > Date: Friday, May 10, 2013 1:07 AM > To: EPP Provreg > Subject: [provreg] Launchphase and >=20 >> We're currently implementing the launchphase extentension. >>=20 >> In my opinion the Claims Check system should use the = section and not the >>=20 >> The reason for my reasoning has to do with RFC5730 and: >>>=20 >>> 2.9.2.1. EPP Command >>>=20 >>>=20 >>> The EPP command is used to determine if an object can be >>> provisioned within a repository. It provides a hint that allows = a >>> client to anticipate the success or failure of provisioning an = object >>> using the command as object-provisioning requirements = are >>> ultimately a matter of server policy. >>>=20 >>=20 >> Referring to "Objects", however launch-1.0 is an extension, or at = least is handled in EPP like one, so my belief is that the response = should go into the section: >>=20 >> S: >> S: >> S: >> S: >> S: Command completed successfully >> S: >> S: >> S: > S: xmlns:launch=3D"urn:ietf:params:xml:ns:launch-1.0"> >> S: claims >> S: >> S: example1.tld >> S: >> S: >> S: example2.tld >> S: abc123 >> S: >> S: >> S: >> S: >> S: ABC-12345 >> S: 54321-XYZ >> S: >> S: >> S: >>=20 >> SHOULD BE: >>=20 >> S: >> S: >> S: >> S: >> S: Command completed successfully >> S: >> S: >> S: > S: xmlns:launch=3D"urn:ietf:params:xml:ns:launch-1.0"> >> S: claims >> S: >> S: example1.tld >> S: >> S: >> S: example2.tld >> S: abc123 >> S: >> S: >> S: >> S: >> S: ABC-12345 >> S: 54321-XYZ >> S: >> S: >> S: >>=20 >>=20 >>=20 >> The main reasoning behind this, is that some systems (including ours) = expect extensions to write on the section and NOT in the = rest of the document. >>=20 >> Having extensions that behave like "objects" could lead to = unnecessary processing and confusion. >>=20 >> Does anyone feel the same? >>=20 >>=20 >> Francisco Obispo=20 >> Director of Applications and Services - ISC >> email: fobispo@isc.org >> Phone: +1 650 423 1374 || INOC-DBA *3557* NOC >> PGP KeyID =3D B38DB1BE >>=20 > _______________________________________________ > provreg mailing list > provreg@ietf.org > https://www.ietf.org/mailman/listinfo/provreg Francisco Obispo=20 Director of Applications and Services - ISC email: fobispo@isc.org Phone: +1 650 423 1374 || INOC-DBA *3557* NOC PGP KeyID =3D B38DB1BE From james.mitchell@ausregistry.com.au Wed May 15 22:23:22 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F6E721F85BF for ; Wed, 15 May 2013 22:23:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.894 X-Spam-Level: X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 43F0EmD9NoNg for ; Wed, 15 May 2013 22:23:17 -0700 (PDT) Received: from mx02.ausregistry.net.au (mx02.ausregistry.net.au [202.65.15.42]) by ietfa.amsl.com (Postfix) with ESMTP id D0A0821F8556 for ; Wed, 15 May 2013 22:23:11 -0700 (PDT) Received: from off-win2003-01.stkildard.vic.ausregistry.com.au (HELO off-win2003-01.ausregistrygroup.local) ([10.30.1.3]) by iron02.off08.stkildard.vic.ausregistry.com.au with ESMTP; 16 May 2013 15:23:09 +1000 Received: from off-win2003-01.ausregistrygroup.local ([10.30.1.3]) by off-win2003-01.ausregistrygroup.local ([10.30.1.3]) with mapi; Thu, 16 May 2013 15:23:07 +1000 From: James Mitchell To: EPP Provreg Date: Thu, 16 May 2013 15:23:05 +1000 Thread-Topic: Custom phases with claims Thread-Index: Ac5R9XJ72LqSj48WS02YkiYiAuPpoA== Message-ID: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 acceptlanguage: en-US, en-AU x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: multipart/alternative; boundary="_000_CDBAAA598BF3Djamesmitchellausregistrycomau_" MIME-Version: 1.0 Subject: [provreg] Custom phases with claims X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2013 05:23:22 -0000 --_000_CDBAAA598BF3Djamesmitchellausregistrycomau_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Jim, You have long been a proponent for having clients provide "claims" and "lan= drush" in the phase element (to my disagreement). Since you require clients= specify both, how would you represent a "custom" phase that requires claim= s processing given the "name" attribute cannot be used to specify the sub-p= hase? My preference is to remove "claims" as a phase as it provides _zero_ value = to the protocol, and retire the need to provide sub-phase information durin= g claims. Claims information may be provided with other phases (landrush, o= pen) without explicitly providing a "claims" phase value, and servers have = to code for missing claims information regardless (e.g. It is possible to p= rovide "sunrise" with claims information, and "claims" with mark informati= on). I also dislike the use of the term "custom" - registries will operate sunri= ses differently; those different sunrises are by definition custom. IMO the= schema-level restriction on phase values provides no value to the protocol= itself. I would like to see the phase enumeration removed, replaced instea= d with unrestricted "token" strings. The mapping document can reserve the e= xisting values (sunrise, landrush, open) as having special meaning if you f= eel it is necessary. Regards, James --_000_CDBAAA598BF3Djamesmitchellausregistrycomau_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Jim,

You have long been a proponent for having clients provide "claims" an= d "landrush" in the phase element (to my disagreement). Since you require c= lients specify both, how would you represent a "custom" phase that requires= claims processing given the "name" attribute cannot be used to specify the= sub-phase?

My preference is to remove "claims" as= a phase as it provides _zero_ value to the protocol, and retire the need t= o provide sub-phase information during claims. Claims information may be pr= ovided with other phases (landrush, open) without explicitly providing a "c= laims" phase value, and servers have to code for missing claims information= regardless (e.g. It is possible to provide "sunrise" with claims informati= on, and "claims"  with mark information).

I a= lso dislike the use of the term "custom" - registries will operate sunrises= differently; those different sunrises are by definition custom. IMO t= he schema-level restriction on phase values provides no value to the protoc= ol itself. I would like to see the phase enumeration removed, replaced inst= ead with unrestricted "token" strings. The mapping document can reserve the= existing values (sunrise, landrush, open) as having special meaning if you= feel it is necessary.

Regards,
James

--_000_CDBAAA598BF3Djamesmitchellausregistrycomau_-- From JGould@verisign.com Thu May 16 07:31:38 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D751D21F90FC for ; Thu, 16 May 2013 07:31:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.598 X-Spam-Level: X-Spam-Status: No, score=-5.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3dhqx-wCdXIM for ; Thu, 16 May 2013 07:31:33 -0700 (PDT) Received: from exprod6og109.obsmtp.com (exprod6og109.obsmtp.com [64.18.1.23]) by ietfa.amsl.com (Postfix) with ESMTP id 4FF1321F8F6D for ; Thu, 16 May 2013 07:31:31 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob109.postini.com ([64.18.5.12]) with SMTP ID DSNKUZTtwgj+vj6MEHJ9XSvx/c3nd2+my7F1@postini.com; Thu, 16 May 2013 07:31:33 PDT Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id r4GEVRlW016846 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 16 May 2013 10:31:27 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Thu, 16 May 2013 10:31:27 -0400 From: "Gould, James" To: "james.mitchell@ausregistry.com.au" , EPP Provreg Thread-Topic: [provreg] Custom phases with claims Thread-Index: Ac5R9XJ72LqSj48WS02YkiYiAuPpoAATJUqA Date: Thu, 16 May 2013 14:31:27 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.173.152.4] Content-Type: multipart/related; boundary="_004_CDBA63FB4FEACjgouldverisigncom_"; type="multipart/alternative" MIME-Version: 1.0 Subject: Re: [provreg] Custom phases with claims X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2013 14:31:39 -0000 --_004_CDBA63FB4FEACjgouldverisigncom_ Content-Type: multipart/alternative; boundary="_000_CDBA63FB4FEACjgouldverisigncom_" --_000_CDBA63FB4FEACjgouldverisigncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable James, My feedback is below. -- JG [cid:A9AFE7A3-373A-4E10-A8E0-34ACE123DC68] James Gould Principal Software Engineer jgould@verisign.com 703-948-3271 (Office) 12061 Bluemont Way Reston, VA 20190 VerisignInc.com From: James Mitchell > Date: Thursday, May 16, 2013 1:23 AM To: EPP Provreg > Subject: [provreg] Custom phases with claims Jim, You have long been a proponent for having clients provide "claims" and "lan= drush" in the phase element (to my disagreement). Since you require clients= specify both, how would you represent a "custom" phase that requires claim= s processing given the "name" attribute cannot be used to specify the sub-p= hase? The passing of the "claims" and the "landrush" in the phase element togethe= r in the draft is to cover a common use case of the overlapping "claims" ph= ase with a "landrush". Since SHOULD is used, this is recommended and is no= t a requirement. I'm assuming that a custom phase during the "claims" phas= e does not overlap with "landrush", so therefore since "name" is freeform y= ou can define your custom phase during claims to be a sub-phase of "claims"= . Based on the TMCH model the required phases include "sunrise" followed b= y "claims", so if you have additional granularity of phases, then you can u= tilize the sub-phase feature of the draft to reflect it. It might help if = you can provide a specific example of what you're attempting to accomplish. My preference is to remove "claims" as a phase as it provides _zero_ value = to the protocol, and retire the need to provide sub-phase information durin= g claims. Claims information may be provided with other phases (landrush, o= pen) without explicitly providing a "claims" phase value, and servers have = to code for missing claims information regardless (e.g. It is possible to p= rovide "sunrise" with claims information, and "claims" with mark informati= on). Your belief if that the "claims" phase provides no value from a protocol pe= rspective, but I disagree since I view a TLD as running through a state mac= hine of phases, where "claims" is one of those states or phases. The "clai= ms" phase defines specific server behavior and interface requirements that= is reflected with the use of the "claims" phase. This includes support fo= r the claims check and the requirement to pass the claims notice on the cre= ate. The draft fully supports passing claims information and mark informat= ion using the Mixed Create Form based on your prior feedback. Removing of = the "claims" phase value as well as the enumerated list of phases will make= it difficult for the clients considering the variety of definitions of pha= ses and the variety of server behavior based on a set of freeform phase nam= es. Having a standard set of phase names, with predefined meanings, with e= xpected server behavior, and with extensibility by the ability to define cu= stom phases and sub-phases provides for a good mix of consistency and flexi= bility. I also dislike the use of the term "custom" - registries will operate sunri= ses differently; those different sunrises are by definition custom. IMO the= schema-level restriction on phase values provides no value to the protocol= itself. I would like to see the phase enumeration removed, replaced instea= d with unrestricted "token" strings. The mapping document can reserve the e= xisting values (sunrise, landrush, open) as having special meaning if you f= eel it is necessary. Can you describe the interface / protocol differences that would be needed = to cover these different "custom" sunrises? If you're referring to differe= nt eligibility requirements, that is policy and not protocol that is best l= eft out of the protocol. Regards, James --_000_CDBA63FB4FEACjgouldverisigncom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
James,

My feedback is below.

-- 

 

JG

 

 

James Gould

= Principal Software Engineer

<= a href=3D"mailto:jgould@verisign.com">jgould@verisign.com

=  

= 703-948-3271 (Office)

= 12061 Bluemont Way

= Reston, VA 20190

VerisignInc.com


From: James Mitchell <james.mitchell@ausregist= ry.com.au>
Date: Thursday, May 16, 201= 3 1:23 AM
To: EPP Provreg <provreg@ietf.org>
Subject: [provreg] Custom p= hases with claims

Jim,

You have long been a proponent for having clients provide "claims= " and "landrush" in the phase element (to my disagreement). = Since you require clients specify both, how would you represent a "cus= tom" phase that requires claims processing given the "name" attribute cannot be used to specify the sub-phase?

The passing of the "claims" and the "landrush" in = the phase element together in the draft is to cover a common use case of th= e overlapping "claims" phase with a "landrush".  S= ince SHOULD is used, this is recommended and is not a requirement.  I'= m assuming that a custom phase during the "claims" phase does not overlap w= ith "landrush", so therefore since "name" is freeform y= ou can define your custom phase during claims to be a sub-phase of "cl= aims".  Based on the TMCH model the required phases include "= ;sunrise" followed by "claims", so if you have additional granularity of p= hases, then you can utilize the sub-phase feature of the draft to reflect i= t.  It might help if you can provide a specific example of what you're= attempting to accomplish.  


My preference is to remove "claims" as a phase as it provide= s _zero_ value to the protocol, and retire the need to provide sub-phase in= formation during claims. Claims information may be provided with other phas= es (landrush, open) without explicitly providing a "claims" phase value, and servers have to code for missing cla= ims information regardless (e.g. It is possible to provide "sunrise&qu= ot; with claims information, and "claims"  with mark informa= tion).

Your belief if that the "claims" phase provides no value fro= m a protocol perspective, but I disagree since I view a TLD as running thro= ugh a state machine of phases, where "claims" is one of those sta= tes or phases.  The "claims" phase defines specific  server behavior and interface requirements that is reflected with the use = of the "claims" phase.  This includes support for the claims= check and the requirement to pass the claims notice on the create.  T= he draft fully supports passing claims information and mark information using the Mixed Create Form based on your prior feedback.=  Removing of the "claims" phase value as well as the enumer= ated list of phases will make it difficult for the clients considering the = variety of definitions of phases and the variety of server behavior based on a set of freeform phase names.  Having a = standard set of phase names, with predefined meanings, with expected server= behavior, and with extensibility by the ability to define custom phases an= d sub-phases provides for a good mix of consistency and flexibility.  


I also dislike the use of the term "custom" - registries wil= l operate sunrises differently; those different sunrises are by definition = custom. IMO the schema-level restriction on phase values provides no v= alue to the protocol itself. I would like to see the phase enumeration removed, replaced instead with unrestricted "to= ken" strings. The mapping document can reserve the existing values (su= nrise, landrush, open) as having special meaning if you feel it is necessar= y.

Can you describe the interface / protocol differences that would be ne= eded to cover these different "custom" sunrises?  If you're = referring to different eligibility requirements, that is policy and not pro= tocol that is best left out of the protocol.



Regards,
James

 --_000_CDBA63FB4FEACjgouldverisigncom_-- --_004_CDBA63FB4FEACjgouldverisigncom_ Content-Type: image/png; name="A9AFE7A3-373A-4E10-A8E0-34ACE123DC68.png" Content-Description: A9AFE7A3-373A-4E10-A8E0-34ACE123DC68.png Content-Disposition: inline; filename="A9AFE7A3-373A-4E10-A8E0-34ACE123DC68.png"; size=4109; creation-date="Thu, 16 May 2013 14:31:27 GMT"; modification-date="Thu, 16 May 2013 14:31:27 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAEkAAABACAIAAADZHs1DAAAP1ElEQVRoBe2aa3CU1RnHN3vLJtmQ hEtiwlUBtZUUCiU6tU7wVhinjOB0xmJnFIdpO1Y6DY586Iwdo36gLc4Iip3pVAL9IKjTDnhDEEWC 1GoICHLRctEkXHIPuZHr7qa/c553T152N9lsNvnWM5nDec97Ls//+T+X854lZWBgwDFuRRaXOiUl hX2kHrcNr1vYfd1T0g/ACIVCQV0CgQD/8miwOZ1Ol8vldrupKTyOK9QU2ThpUA4w9Pf39/X19fT0 UCsYYHA6QcLiYKCwF2MEMNh8Pp/X6/V4PAxOXoDoFcYAG7ICplsXNvClpSFvipAimGy1wQmrMgV4 aUzxekEbLV8yPUlhE66u6YJkqT6fMjKDyjRs2GgaeNKA587OTqZnZGSMLYejx4biEautrQ3eUlNT LUiCx6AyjWHhAbKrqwuEwMNQxYyTYUzmjhIbboMo7e3tyIwoMYA5nZ+duXiyur6ju88u5ZL5s+ff mJ+TmUan4JUGNVbQ2tqKNvx+PwTaZ42uPRpseBeoYMygUvRoijp7AnuPXdhz9PyeyvPI7khxqtoU yTcDofk35j1674LH7luY7U8zVsoo2qgMc5gwYQIeaOaNrpEwNoCBqraujgBALDeoOnr6X9t/4rX9 x9t7gg6Xx+F0K1QEQOBRFKoBVYdCjoGgI6T+MtO9j9+74Nlf3gNChhiQHR0dwMvKykoSXmLYMEUY u3T5MoyxMZEDbJTK81fWlR242NrrcHsdToBpSBZpsKeps0gDocYWDDhC6i8zzbO9ZOWKH38/Ah5K hL1kjDMBbMQMDKa6pgaE6enpggp4r+z5cvOeLx0en6bLpRkTbIKKWjGnijoCgQ3qdB3sdwR6FcJg 8NF7Crc99XNeG/ZQIvkQ3xt1bhgpNrYhlMFYY0NDVna2Bczp/MPrh3dVVjncAHOrvxSwuSw3U3SF SVPIxDKpBVuYQOABMtg3f+aUA39aY/fApqYmLB89CmBZY+T1SA8EcIWb1dfXk8QIaFIUsKM1Dk+a w+1xuLQ1Ag9s1p9uC9rBTk2sUoRLq8Ojp6cy/UR100MvvK41oPkdGMjJySF3svXI8dhHjggbSDhD ED8wSxgTYLsqLihgbsRCULBp3gghBobyN5AY33NalKoeuA2rgInYs1rHU37m4rq/vW/gsReZk63Z 0S70CNsjwiakNTU2etxuAXax5dpf3juuuBJgFiQtPdgUKv3n1DZpPdrawFPDwvBoW/C8L79bceD4 eQOPcELMHB118bHhab29vYq0UIhjvGB77p+VHeRk7MpCIn5lgobRrHY5noCnQgrD5JX5sJJOPZ0Y q/h3rdn0NpsaePgbAkiPWXckjfjfOJytMHrcmngltnGsqqmyqllZUYozK82z4MY8tZNYmtnT6T5+ saWtV1DpXuARRYLB4ltyVWw0hZRA4VDS1Xfiu3pe1TR3vLDz4B9XLSGEAIlw0tzcTJ1oPoiPDXto uXoVzfkzM/kyQ4y/f3JW0QVpig3H7vXLJfkqEW3l4OlLd/95n7JbU0KB4rkTDz6z3HTYGyVlH5+o alTjQ6FtHx575hfFvAUeXodaESNRbHFsErWRQxsaGpRBpqRQX2ru/LKmRScxZZBtnd0lr31oF9G0 l9w2rfjmXJWppdDo79n+xL1mgL1RVd+6+f1jWmUq9dc0tb/z+TfsTmEYB2jEkLZ91vDtONgwQhgj ZavPaf1N/enZegUM3uTP7f3Hga8OnqyKuc323xQ7OH9ICQaefWjRrCkTYo5c/fK7yshlTXVkc739 +RlGanQDREvEEI+IOT1mZxxsBH0WlfO+uioIhQ6dbdSuhffrUI5Aqf7SNz6NuTpInl2xQHlXKJDl CZU8sCDmsN1fnC0/16wCiVqTU6jS3cGvqoUoakk87B9z+lCdcbChKoAJY7SBV9PUobMTE3VwQ9Me X/nXtds/Ph5zj5JlhVk+J2erTY/+JDvDF3tM2ceaNI41kjzw5BTMsrWzx8DD8caBt76+YEDZlaYt 1N4bUqo1fyBE39700rf+09rZHS16dkbqplWL5xf4Vy9Rp+HoUvrG4eo2/emgzmgUWVzBO/Fdrdgk vZjlGPPG0nClCVP1uXpIE6qtPKVBOtF6dUv3pt2faeEiK1Bt/+39kb36ufVaz6YPz6jEDf+WvvQL Mor+WhVsSozwfVnMdWJ2DpcDZF0MElj9+kKuvZuERdEJ16p1B/nAk/bcv46svn/RrLxs3XVdBaUp KzYoR7UX1IS7qg+I62+BLALVUGSQGQbkyM/N129m31jnFukQ3kBoey9bWhuTudWXmze9ZOsQ+aBw 1oN3znOkZTsyJg3+pecQh3QCDFvB4AaqR1NlgZI3IwfG+OGwqdda0xg6qRPjnJGdqveIAKb7OBx6 fG8frR4qH2xaXZzl12diuDJ/KjbiYNevqriytGboMsLooSOq4mBDT1wbWLwFgz5sx3xZyh1B2GaU fDqolJR9FHNn8kHJT2+77rRlH6ew8EUnqHRjYGD65Ex1Ka0Lyk2INJaLg43DzqRJk8BG4WQAgd/L y9ASKFfQsoWl4UH7z4lL7cPkg5k5sdKAAFPLWahYnNuU6ZMnWDFkYEBpOcIt9fbDVHGwyRcUVyNg 6+ntxeVmT0pVx6jBb2cjjd6FtOtJKyk7MFQ+KF35Qz6xBwViHWV++m9wzRD03nXrVIs09tZxUhxk cG68VhxsqIrEkpOdDWPwxi43TUzVt1TcC+g/uyHRxnncqW39rtK3hsgHxbfOn04g1WFJARNcRkE0 9LKh4AOL5hjSerq7EWOMecMSIC0/Px9UwOMzceE0/+QMtyUBcqg7Of5EOK1Jwo/Ht/m9So6/0Zol oVXVNmueBJidNFmKNdVF2LKFsxVvmjTUihhj7G8GG1KyC2dLEN4xw69ub7QEgyAlDIgT6qCijr9R pfTNf7f1Ch4YE1O0kabW5Nqr/+E7b8HfLN50Khh7bMjGVSQ2mX/DDRBHsEKFS+dOSHMNqAO+OgSL 74VVrkxUZUYss/ybuoh8UNXYvnnfaXUNQRkExly9iFpKX10G+p56sMgAQ6EYJGJEKSpORxx/YzZW zlf9DwoL+aUQeHyDp7oGfnW7/nYWNataY6OWBtN0UFm95QP7/qu37FUpnnAKfqWFsEbURI0KfQFs +aJpE/3GIFEoAiTqbEoE+95DtbGHvLy8adOmCTwunublehfc4NWWGWZPtG6FUO1Lbm91c9emdypk WT7DYVJhpoijGkiWjrilDMzLz/j9zxYpLwt7mvwEOZRsw/SPCBs649ejosWLyePA69W/jD6+aNL0 TKe+NhV42j5F/cKeTnelbx6WfKDcT04h8lZpQXOlv+5knUxP8K+/vl9QCTyiCVuPgjQwu0pLS4eB Lq+IKOQWNiDF1dXVYVB89fi8njtmZp6u62rvjfpk5IwiQcXh6O3rr2u6WtXQ/mZFtcKmStjBFHth eMFApjuwY+19N+XlMEIdwrjCCAYzMzPBlmhmU5uwAIqRVtyaKNLS0rJv//5Lly6xGT/iZPj9AYfr xU8bLnaElNzqRkDukuUTUx8TddxT0UUNIHnoqIizKfYEWBBVwdi2J+6bN30SK8tPKMjD3dbEiRPx iLiyxRyQADa0QH6rra19b88efkayw3v3m7aPLnQp0YmB6kssjA1IFKU+/cVptXUUUf7JlZ6y5x/N yN782J1ZGT4FTBcuDjP9fo57OFuiac3gTAAbc/ABAsmV2toP9u418Pgxghh9rrlv29Hmpi5NINjI 4NQUqa0NNWkqPMIbpAVmZPseL5774KJZYVBwlkLQz87Kys3NhTf6ramJ/5MYNtYHHj/ocM1sh+f2 eOTHpM8vdh3+ruPrhm7NXvhT2vqGYbZgA1VozpSMh4tmLl84w6CiweJYfu4UVYj7yQBjs4SxCTzY u3r16ifl5TU1NUigfkB1uVAzJkTIaekOfl3f9d/G3sbOvsZr/U3X1HVLps81c2J6flba3Dz/XTfn FWSnMYW5jBcM5DHaBfn5+FiSjLEdZTTYmCYK5grs9JkzlZWVJAaBh5QKIeda/R9nlNxadgEgtYUG VBqZOqeyXCgEpKkFBfJLt6DVEo6+GiU2NiS04PHYZ0Nj4+lTp85duECXoYIjEgg9/LcfQBqcNpaY TgEXMPhpG1Rgww6ZOOrgEaGG0WOThYRAEDa3tJw/f/7Ct98SCTQfihXT4AGcBApmCXtkTMATCfNy c/kNEVTEesZHyJfMY7LYZG/Uj7eQIQBZ39DAz6tkQvXY3W2HRxuLJeqo+D55MkdwIOGi/IgB4GRg xJw7NthkaTgUkPK5QI3R0kM/AwQkJgcSKKKmCIcxJUu+cyyxGWnEl4BEkTav8CIKCCnSNuPHqTEu 2MZJ1kSXHUvfTXTv8R7/f2zjreHxWT/hS4hkxLhy5QqHNVaYOnUqoX/4pS5wGNCFnE4CHH5wzLfu jS++eOXyZd5t2LBB9tu9e3d5eTk9a9as2bp1a/S0tWvXzp49+9VXXyVZ298iRFFR0dKlS+k0b196 6SUeQcVSJD0znpErV65kRzBs2bKF/mXLlsncYQYzbN26ddQFU6euf/ppGma6SLVz586TJ0/Sj/DO 24uKaFGki8Y5LTFJdt68efrNSCtE37t376lTp6InRABjQEVFxfPPP09+jxgMMKCKFpCBIoNf0fjN YPg4dOiQeTQNVIZRiHW4CwsLd+3axTtIWLx4Mad7oZF+M2HOnDlPPvmkeYxoGGY2btzIK4SOUAqq FVmLi4tXrFgBHlTAMFQbbZm8EskeeeQR5GFBoYKLtoh9GQmSiE4MyojqxpThFzzwtmrVKmNmdmxI tm/fPrOKWI55lAYGKQ2RLOKtPLIFPKBXZALkUGPoRyQBRhupMNdol2MjWImGZ5ZVsQSzZBBDsQex TCSw616MzcyJwIZr8UqYoQHJZqQ00KWoz74OW+BvBkDEFGEJecSm5C3jCwoKpM10BIZ8NBUx1zwq bMYsASa82UljgCjbzIloGKrpR4sYXsQAHn+3di0mhCeLwdODZDt27IjYyEzkrYyxLy6dMoaNkNau LDPXNBQ2Y5Zsb2aaETTQjTFie7+0MZivTp4UoQEW7UIyTJyNNmywkRjIZR2i7WsKIbzFaNmX6McY O3syWGgnRNkB29ehbZ1LltiUjedgRfZxfKoQD0xBOPtbTPShlSulJ1oI+omchEQizZEjR4hV9PCx J+ONl8ojtTAJIWVlZYL8iwrrZtqMkQZeE23/9jGKN4rdNuxteQsnkoLkMTpsogtmiUmDxO6rTEG1 ol2MUFaQGrvCZIyjSidWwDqMp6bYx0e3iaVoLbpfeixsGBI2I3qyR56YihH3jXBiHF0AIBDY7G8J GPDDecDIyiO7SEzCumQX4RC069evh38ZzFsEE6+jjdARg9GF/a0d5/8ActOtScHpPCkAAAAASUVO RK5CYII= --_004_CDBA63FB4FEACjgouldverisigncom_-- From francisco.arias@icann.org Thu May 16 16:29:59 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A2AD21F8FA9 for ; Thu, 16 May 2013 16:29:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CGiCfsqWiE7V for ; Thu, 16 May 2013 16:29:59 -0700 (PDT) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by ietfa.amsl.com (Postfix) with ESMTP id 6E8F321F8F6E for ; Thu, 16 May 2013 16:29:59 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Thu, 16 May 2013 16:29:59 -0700 From: Francisco Arias To: "provreg@ietf.org" Date: Thu, 16 May 2013 16:29:40 -0700 Thread-Topic: gtld-tech mailing list Thread-Index: Ac5SjUfrs6LLIneaQ5yXf6uhTUkTOw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [provreg] gtld-tech mailing list X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2013 23:29:59 -0000 Colleagues, This is to let you know that we are launching a public, open mailing list for technical discussions regarding gTLD registries and registrars. The intention is to provide a forum for discussion of issues that may appear during ongoing operation and particularly with the upcoming launch of new gTLDs. You can subscribe to the list at: https://mm.icann.org/mailman/listinfo/gtld-tech Regards, --=20 Francisco Arias ICANN technical staff From JGould@verisign.com Fri May 17 12:40:54 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF38021F971E for ; Fri, 17 May 2013 12:40:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.098 X-Spam-Level: X-Spam-Status: No, score=-6.098 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qTO1XzOS5P+H for ; Fri, 17 May 2013 12:40:50 -0700 (PDT) Received: from exprod6og117.obsmtp.com (exprod6og117.obsmtp.com [64.18.1.39]) by ietfa.amsl.com (Postfix) with ESMTP id B39E921F96FB for ; Fri, 17 May 2013 12:40:49 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob117.postini.com ([64.18.5.12]) with SMTP ID DSNKUZaHwRvubJhtTFdcMdzJz5s9fExjlT2H@postini.com; Fri, 17 May 2013 12:40:49 PDT Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id r4HJejwm025992 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 17 May 2013 15:40:47 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Fri, 17 May 2013 15:40:45 -0400 From: "Gould, James" To: EPP Provreg Thread-Topic: Launch Phase EPP Extension Version 11 Thread-Index: AQHOUzZroa/pdtX9ykm3lOzNAwvBBA== Date: Fri, 17 May 2013 19:40:44 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.173.152.4] Content-Type: multipart/alternative; boundary="_000_CDBBFFE94FFD4jgouldverisigncom_" MIME-Version: 1.0 Subject: [provreg] Launch Phase EPP Extension Version 11 X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 19:40:54 -0000 --_000_CDBBFFE94FFD4jgouldverisigncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Wil Tan, Gavin Brown and I have updated the Launch Phase EPP Extension Mapp= ing to Version 11. You can find the draft at the URL http://tools.ietf.org= /html/draft-tan-epp-launchphase-11. This version includes the following ch= ange: 1. Moved the claims check response element under the <= extension> element instead of the element based on the request fr= om Francisco Obispo. Thanks, JG James F. Gould Verisign "This message (including any attachments) is intended only for the use of t= he individual or entity to which it is addressed, and may contain informati= on that is non-public, proprietary, privileged, confidential and exempt fro= m disclosure under applicable law or may be constituted as attorney work pr= oduct. If you are not the intended recipient, you are hereby notified that = any use, dissemination, distribution, or copying of this communication is s= trictly prohibited. If you have received this message in error, notify send= er immediately and delete this message immediately." --_000_CDBBFFE94FFD4jgouldverisigncom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Wil Tan, Gavin Brown and I have updated the Launch Phase EPP Extension=  Mapping to Version 11.  You can find the draft at the URL&n= bsp;htt= p://tools.ietf.org/html/draft-tan-epp-launchphase-11.  This version includes the following change:

   1.  Moved the claims check response &=
lt;launch:chkData> element under the <extension> element instead o=
f the <resData> element based on the request from Francisco Obispo.

Thanks,

JG

James F. Gould
Verisign




“This message (including any attachments) is= intended only for the use of the individual or entity to which it is addre= ssed, and may contain information that is non-public, proprietary, privileg= ed, confidential and exempt from disclosure under applicable law or may be constituted as attorney work product. If yo= u are not the intended recipient, you are hereby notified that any use, dis= semination, distribution, or copying of this communication is strictly proh= ibited. If you have received this message in error, notify sender immediately and delete this message immedi= ately.”
--_000_CDBBFFE94FFD4jgouldverisigncom_-- From alexander.mayrhofer@nic.at Mon May 27 07:40:11 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC14E21F965C for ; Mon, 27 May 2013 07:40:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.43 X-Spam-Level: X-Spam-Status: No, score=-9.43 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r-ZzO0W8U2l4 for ; Mon, 27 May 2013 07:40:07 -0700 (PDT) Received: from mail.sbg.nic.at (mail.sbg.nic.at [83.136.33.227]) by ietfa.amsl.com (Postfix) with ESMTP id 138C221F962E for ; Mon, 27 May 2013 07:40:03 -0700 (PDT) Received: from nics-exch2.sbg.nic.at ([10.17.175.6]) by mail.sbg.nic.at over TLS secured channel (TLSv1:AES128-SHA:128) with XWall v3.49 ; Mon, 27 May 2013 16:36:24 +0200 Received: from NICS-EXCH2.sbg.nic.at ([fe80::a5b2:6e42:e54d:9d57]) by NICS-EXCH2.sbg.nic.at ([fe80::a5b2:6e42:e54d:9d57%12]) with mapi id 14.03.0123.003; Mon, 27 May 2013 16:39:54 +0200 From: Alexander Mayrhofer To: "tmch-tech@icann.org" , "provreg@ietf.org" Thread-Topic: SMD: Restriction of XML DSIG parameter space ... Thread-Index: Ac5a5qayJDKuV65tRkOV8qLAs8Y/HQ== Date: Mon, 27 May 2013 14:39:53 +0000 Message-ID: <19F54F2956911544A32543B8A9BDE0750A24F572@NICS-EXCH2.sbg.nic.at> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.10.0.162] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-XWALL-BCKS: auto Cc: Otmar Lendl Subject: [provreg] SMD: Restriction of XML DSIG parameter space ... X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 14:40:11 -0000 All, looking at http://tools.ietf.org/html/draft-lozano-tmch-smd-02, the draft c= urrently doesn't seem to restrict the set of XML Signature parameters to be= used. The signature and normalization algorithm examples look surprisingly= similar to RFC5105 (written by my colleague Otmar Lendl back in 2006/2007)= .=20 During his journey to implement the signature technoloy in our ENUM registr= y software, he found out that some options in XML DSIG (particularly the no= rmalization options) are rather cumbersome and error-prone (AFAIR whitespac= e changes created by the validating XML parser triggering validation error= s, etc.). Based on this practical experience, he restricted the parameter r= ange for XML DSIG in http://tools.ietf.org/html/rfc5105#section-3 of RFC510= 5, in order to increase interopability. The concept described in RFC5105 ha= s since been validated in implementations of a few ENUM registry installati= ons (servers), as well as their ENUM registrars (clients).=20 Since SMD essentially uses the same technology, i'm proposing that the auth= ors also consider restricting the parameter range of XML DSIG in order to r= educe implementation effort, and increase interopability. Comments? Alex From Anthony.Kirby@nominet.org.uk Tue May 28 03:14:10 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42A2421F95A0 for ; Tue, 28 May 2013 03:14:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bBVm1Pmgkg0l for ; Tue, 28 May 2013 03:14:05 -0700 (PDT) Received: from mx2.nominet.org.uk (mx2.nominet.org.uk [213.248.242.49]) by ietfa.amsl.com (Postfix) with ESMTP id 9425C21F955C for ; Tue, 28 May 2013 03:14:05 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:From:To:CC:Subject: Thread-Topic:Thread-Index:Date:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:x-originating-ip: Content-Type:Content-Transfer-Encoding:MIME-Version; b=BFa7CbrSHUgM7oADXVHfDpOSUQJHN6+eKx0kyfD/abF7uoHb1WJJhHAv d1Q56BqcQyZgmwSHxlxmQ62EgY86Yc2SpQhD6ebgBzcErLbnQ/m2EiC8O E3NVJfbtQwZpEMa; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1369736045; x=1401272045; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=VaxeI3iRC7Y6TX0F6JlA30QR8J99c5+FEd/kDSVkOJA=; b=Kod1aMy0CEeRr4Ft/niHSACrlWlHG49ONc3/lbw3XGl2jBtDQZwiVCGQ Jl81VMprITcIhA2DPFHwOTla8BpT3otJn7DbG+kYPdazVA4YzQp40pw2c xifHnbhW4NglbWs; X-IronPort-AV: E=Sophos;i="4.87,757,1363132800"; d="scan'208";a="810873" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx2.nominet.org.uk with ESMTP; 28 May 2013 11:14:04 +0100 Received: from WDS-EXC1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f]) by wds-exc2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4%17]) with mapi id 14.02.0318.004; Tue, 28 May 2013 11:14:04 +0100 From: Anthony Kirby To: Alexander Mayrhofer , "tmch-tech@icann.org" , "provreg@ietf.org" Thread-Topic: SMD: Restriction of XML DSIG parameter space ... Thread-Index: Ac5a5qayJDKuV65tRkOV8qLAs8Y/HQAo31m4 Date: Tue, 28 May 2013 10:14:03 +0000 Message-ID: References: <19F54F2956911544A32543B8A9BDE0750A24F572@NICS-EXCH2.sbg.nic.at> In-Reply-To: <19F54F2956911544A32543B8A9BDE0750A24F572@NICS-EXCH2.sbg.nic.at> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.2.1] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Otmar Lendl Subject: Re: [provreg] SMD: Restriction of XML DSIG parameter space ... X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2013 10:14:10 -0000 +1=0A= =0A= interoperability for ENUM tokens was hard to achieve, even with this specif= ied=0A= =0A= thanks=0A= Anthony=0A= =0A= =0A= ________________________________________=0A= From: provreg-bounces@ietf.org [provreg-bounces@ietf.org] on behalf of Alex= ander Mayrhofer [alexander.mayrhofer@nic.at]=0A= Sent: 27 May 2013 15:39=0A= To: tmch-tech@icann.org; provreg@ietf.org=0A= Cc: Otmar Lendl=0A= Subject: [provreg] SMD: Restriction of XML DSIG parameter space ...=0A= =0A= All,=0A= =0A= looking at http://tools.ietf.org/html/draft-lozano-tmch-smd-02, the draft c= urrently doesn't seem to restrict the set of XML Signature parameters to be= used. The signature and normalization algorithm examples look surprisingly= similar to RFC5105 (written by my colleague Otmar Lendl back in 2006/2007)= .=0A= =0A= During his journey to implement the signature technoloy in our ENUM registr= y software, he found out that some options in XML DSIG (particularly the no= rmalization options) are rather cumbersome and error-prone (AFAIR whitespac= e changes created by the validating XML parser triggering validation error= s, etc.). Based on this practical experience, he restricted the parameter r= ange for XML DSIG in http://tools.ietf.org/html/rfc5105#section-3 of RFC510= 5, in order to increase interopability. The concept described in RFC5105 ha= s since been validated in implementations of a few ENUM registry installati= ons (servers), as well as their ENUM registrars (clients).=0A= =0A= Since SMD essentially uses the same technology, i'm proposing that the auth= ors also consider restricting the parameter range of XML DSIG in order to r= educe implementation effort, and increase interopability.=0A= =0A= Comments?=0A= =0A= Alex=0A= =0A= _______________________________________________=0A= provreg mailing list=0A= provreg@ietf.org=0A= https://www.ietf.org/mailman/listinfo/provreg=0A= From gustavo.lozano@icann.org Tue May 28 06:06:55 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58C0121F96F6 for ; Tue, 28 May 2013 06:06:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A-6I5QCW9Lb0 for ; Tue, 28 May 2013 06:06:43 -0700 (PDT) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by ietfa.amsl.com (Postfix) with ESMTP id 8C34D21F96BB for ; Tue, 28 May 2013 06:06:42 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Tue, 28 May 2013 06:06:41 -0700 From: Gustavo Lozano To: Alexander Mayrhofer , "tmch-tech@icann.org" , "provreg@ietf.org" Date: Tue, 28 May 2013 06:06:39 -0700 Thread-Topic: [tmch-tech] SMD: Restriction of XML DSIG parameter space ... Thread-Index: Ac5bpDI8AGInR5DsSe2sJIWKLVY6yQ== Message-ID: In-Reply-To: <19F54F2956911544A32543B8A9BDE0750A24F572@NICS-EXCH2.sbg.nic.at> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3452565999_34540156" MIME-Version: 1.0 Cc: Otmar Lendl Subject: Re: [provreg] [tmch-tech] SMD: Restriction of XML DSIG parameter space ... X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2013 13:06:55 -0000 --B_3452565999_34540156 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Alex, all, Thank you for your feedback. TMVs (there is only one at the moment) are the only actors generating SMDs and TMVs must use: xml-exc-c14n, RSA-SHA256, SHA256 and the RSA key size is 2048 bits. During the LA meeting, we agreed on RSA2048 and SHA256. I will add text in the new version of the draft to clarify this. The SMD file downloaded by the TMH from the TMV is encoded in base64 (see 6.4 of draft-lozano-tmch-func-spec). The reason for the base64 encoding is to mitigate the possiblity that the signature is invalidated by mistake (e.g. sending the SMD by email). There is no recommendation/requirement for using an instead of in the communication channel between Registrars and Registries. Maybe a recommendation or requirement for using in this channel is worth it? Maybe the risk is low? Sometimes, it is cheaper wasting CPU cycles (decoding base64) instead of troubleshooting. Comments? Regards, Gustavo On 5/27/13 7:39 AM, "Alexander Mayrhofer" wrote: >All, > >looking at http://tools.ietf.org/html/draft-lozano-tmch-smd-02, the draft >currently doesn't seem to restrict the set of XML Signature parameters to >be used. The signature and normalization algorithm examples look >surprisingly similar to RFC5105 (written by my colleague Otmar Lendl back >in 2006/2007). > >During his journey to implement the signature technoloy in our ENUM >registry software, he found out that some options in XML DSIG >(particularly the normalization options) are rather cumbersome and >error-prone (AFAIR whitespace changes created by the validating XML >parser triggering validation errors, etc.). Based on this practical >experience, he restricted the parameter range for XML DSIG in >http://tools.ietf.org/html/rfc5105#section-3 of RFC5105, in order to >increase interopability. The concept described in RFC5105 has since been >validated in implementations of a few ENUM registry installations >(servers), as well as their ENUM registrars (clients). > >Since SMD essentially uses the same technology, i'm proposing that the >authors also consider restricting the parameter range of XML DSIG in >order to reduce implementation effort, and increase interopability. > >Comments? > >Alex > > --B_3452565999_34540156 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIITsQYJKoZIhvcNAQcCoIITojCCE54CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EX0wggb4MIIF4KADAgECAhAMNMzaaOCLlcX5TdjpURhNMA0GCSqGSIb3DQEBBQUAMGIxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xITAfBgNVBAMTGERpZ2lDZXJ0IEFzc3VyZWQgSUQgQ0EtMTAeFw0xMzA1MDgwMDAw MDBaFw0xNjA1MDgxMjAwMDBaMIGiMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5p YTEUMBIGA1UEBxMLTG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0aW9u IGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczERMA8GA1UECxMIUmVnaXN0cnkxFzAV BgNVBAMTDkd1c3Rhdm8gTG96YW5vMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA 3w18r+IUAk+jj+kX9oTY/E3q0GyAzR+0x8YvIlksG3cKpkVBqjAKnpZL+GaN98aXYqsIDo8g gctjo1fAx8QxgPkGeZ56EP5uaaN65I1guFa/mVTzSGg2WyXVMRjJmcLBBt//k9APKpvl4Qj4 o+ItgJAKcEA9mtErJB1UE6FtX6ubRd7l/t2BlYHaJLEmdtA4hXfE9TYiVSo4J8652aQ1ba7I g/Qzse32X4A6gm2w6EbEt7m8UVcH0pbxOXpi8Vvz1l6qG3+kxdtJUclg3os4mm0/Iz5glFzM a7OvDyGDbRZbL8ewlnsx3+mjNqDy2S5xNSYFKmdo65xJL1HItfJcSQIDAQABo4IDZzCCA2Mw HwYDVR0jBBgwFoAUFQASKxOYspkH7R7for5XDStnAs0wHQYDVR0OBBYEFDejkLO4b/vTq4z4 /ln0RuaCGgvuMCMGA1UdEQQcMBqBGGd1c3Rhdm8ubG96YW5vQGljYW5uLm9yZzAOBgNVHQ8B Af8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMH0GA1UdHwR2MHQwOKA2 oDSGMmh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRENBLTEuY3Js MDigNqA0hjJodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURDQS0x LmNybDCCAcUGA1UdIASCAbwwggG4MIIBtAYKYIZIAYb9bAQBAjCCAaQwOgYIKwYBBQUHAgEW Lmh0dHA6Ly93d3cuZGlnaWNlcnQuY29tL3NzbC1jcHMtcmVwb3NpdG9yeS5odG0wggFkBggr BgEFBQcCAjCCAVYeggFSAEEAbgB5ACAAdQBzAGUAIABvAGYAIAB0AGgAaQBzACAAQwBlAHIA dABpAGYAaQBjAGEAdABlACAAYwBvAG4AcwB0AGkAdAB1AHQAZQBzACAAYQBjAGMAZQBwAHQA YQBuAGMAZQAgAG8AZgAgAHQAaABlACAARABpAGcAaQBDAGUAcgB0ACAAQwBQAC8AQwBQAFMA IABhAG4AZAAgAHQAaABlACAAUgBlAGwAeQBpAG4AZwAgAFAAYQByAHQAeQAgAEEAZwByAGUA ZQBtAGUAbgB0ACAAdwBoAGkAYwBoACAAbABpAG0AaQB0ACAAbABpAGEAYgBpAGwAaQB0AHkA IABhAG4AZAAgAGEAcgBlACAAaQBuAGMAbwByAHAAbwByAGEAdABlAGQAIABoAGUAcgBlAGkA bgAgAGIAeQAgAHIAZQBmAGUAcgBlAG4AYwBlAC4wdwYIKwYBBQUHAQEEazBpMCQGCCsGAQUF BzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wQQYIKwYBBQUHMAKGNWh0dHA6Ly9jYWNl cnRzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRENBLTEuY3J0MAwGA1UdEwEB/wQC MAAwDQYJKoZIhvcNAQEFBQADggEBAGaf7RGm6z5gi7JPp8yiw4JQc1rNztSU2JyQfjy3XtFU rrkK3UhhhYKXVoTRL4bSEx2OTc7ejQ2uMNNKU0ew/hPWhx1jU3AMvf6f3FHFt8X/dAcse+TU QyHT822Kup802tVILAijiq+3SnpNoT2VbI1aw1M4lJpIUezERhbDSRkPXMdIK/nRl57KCXc/ PyM2AD4HvdT1OqXQ1j1baeooPcvofWewjD/WyHkpdVbQ+RJ7F1a9ndagERt4D1kTp1yiZwVH 8gKthT5JXVvA1yTOg8Z8nDl2c12SrVQcP/pIAz8VsTNFlIrcO22XGFfyIfj+WFeLkDJeMccK B1IlFAPPKO0wggbCMIIFqqADAgECAhAKBN8hdF1NK4zqM3IFAFDpMA0GCSqGSIb3DQEBBQUA MGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5k aWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0w NjExMTAwMDAwMDBaFw0yMTExMTAwMDAwMDBaMGIxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxE aWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xITAfBgNVBAMTGERpZ2lD ZXJ0IEFzc3VyZWQgSUQgQ0EtMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOiC LZn5ysJClaWAc0Bw0p5WVFypxNJBBo/JM/xNRZFcgZ/tLJz4FlnfnrUkFcKYubR3SdyJxAra r8tea+2tsHEx6886QAxGTZPsi3o2CAOrDDT+GEmC/sfHMUiAfB6iD5IOUMnGh+s2P9gww/+m 9/uizW9zI/6sVgWQ8DIhFonGcIj5BZd9o8dD3QLoOz3tsUGj7T++25VIxO4es/K8DCuZ0MZd EkKB4YNugnM/JksUkK5ZZgrEjb7SzgaurYRvSISbT0C58Uzyr5j79s5AXVz2qPEvr+yJIvJr GGWxwXOt1/HYzx4KdFxCuGh+t9V3CidWfA9ipD8yFGCV/QcEogkCAwEAAaOCA28wggNrMA4G A1UdDwEB/wQEAwIBhjA7BgNVHSUENDAyBggrBgEFBQcDAQYIKwYBBQUHAwIGCCsGAQUFBwMD BggrBgEFBQcDBAYIKwYBBQUHAwgwggHGBgNVHSAEggG9MIIBuTCCAbUGC2CGSAGG/WwBAwAE MIIBpDA6BggrBgEFBQcCARYuaHR0cDovL3d3dy5kaWdpY2VydC5jb20vc3NsLWNwcy1yZXBv c2l0b3J5Lmh0bTCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAg AHQAaABpAHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABl AHMAIABhAGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQBy AHQAIABDAFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABh AHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABs AGkAYQBiAGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0 AGUAZAAgAGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAPBgNVHRMB Af8EBTADAQH/MH0GCCsGAQUFBwEBBHEwbzAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGln aWNlcnQuY29tMEcGCCsGAQUFBzAChjtodHRwOi8vd3d3LmRpZ2ljZXJ0LmNvbS9DQUNlcnRz L0RpZ2lDZXJ0QXNzdXJlZElEUm9vdENBLmNydDCBgQYDVR0fBHoweDA6oDigNoY0aHR0cDov L2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEUm9vdENBLmNybDA6oDigNoY0 aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEUm9vdENBLmNybDAd BgNVHQ4EFgQUFQASKxOYspkH7R7for5XDStnAs0wHwYDVR0jBBgwFoAUReuir/SSy4IxLVGL p6chnfNtyA8wDQYJKoZIhvcNAQEFBQADggEBAIRhTkEeuHYEKrW274/yVYW5XVb+Cpjm5L1l in1AKdP8sV1F/Tq4KlszSyRczbm05HOtYV12rXQzimbVI69MH3JuRdl1QLuiO8+NSS/AQbDi KaNROENQmRSsMwY1Yol9d6lSB+VsIFe2gbpvvLPClO12AoDZfM6FqBzsx0NKS7FXz3LO3/Ul PMsiT/2fUtE3ywi7OD7g1T5veQmtW3wxs3c1w+Rj+WgKmAfnRjh3hNI+l7wKoKisJU9EbpHh 0lqva+8wHI2jREKzEIsj+tfmNXQ3rM/rq1gfyYgj/zbUB+o0akfqnZVsnilPU+3jK5UgTirP lmB6+CyA8JVSzimWgWIwggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3 DQEBBQUAMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBD QTAeFw0wNjExMTAwMDAwMDBaFw0zMTExMTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYD VQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMT G0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAK0OFc7kQ4BcsYfzt2D5cRKlrtwmlIiq9M71IDkoWGAM+IDaqRWVMmE8tbEohIqK 3J8KDIMXeo+QrIrneVNcMYQq9g+YMjZ2zN7dPKii72r7IfJSYd+fINcf4rHZ/hhk0hJbX/lY GDW8R82hNvlrf9SwOD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+WZyLdm3X8aJLDSv/C3La nmDQjpA1xnhVhyChz+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh5vqk2dUXMXWuhX0i rj8BRob2KHnIsdrkVxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Yd08CAwEAAaNj MGEwDgYDVR0PAQH/BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXroq/0ksuC MS1Ri6enIZ3zbcgPMB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3 DQEBBQUAA4IBAQCiDrzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwS TFjk0z2DSUVYlzVpGqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+Df wWdJs13rsgkq6ybteL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3 +owe3WLxvlBnt2y98/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMN FG7zfx9jEB76jRslbWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMYIB /DCCAfgCAQEwdjBiMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYD VQQLExB3d3cuZGlnaWNlcnQuY29tMSEwHwYDVQQDExhEaWdpQ2VydCBBc3N1cmVkIElEIENB LTECEAw0zNpo4IuVxflN2OlRGE0wCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBQ92Z2Q LMvAAYnX9E4JaZ7kMAjx+DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ BTEPFw0xMzA1MjgxMzA2MzlaMA0GCSqGSIb3DQEBAQUABIIBAMX8i7LTi+DpojXdWj+100hQ 7fNXAfw/5Pz6+8valnE8fwPB/BlWxoAi5Z7/vb17Bow5ToIzjDCYimn8MHUX5+buuZnNn/rb MtXa82CYuZZAbpmuUJVlH9LQQQKYeJ2BkIzoYZXjwa8Z6QQGzX5V2Tsjklx5u3/1KoCRL2oD U5pR3b2/7V7IoW/G63K1TZvEOgB/NxD448t0xrncNoSIyOBGQNuMX3xFn0wp2AMRshMHKUgu rlfTl2v20CRqGe5VgB3Qf8cmeZ7fhVEanms33vxeOcxR291sJ2kGHxUt/hXZg0S9god9aKJ/ xtDQ+bN272kzE9JDfoCZTJ/5AkqGJsM= --B_3452565999_34540156-- From JGould@verisign.com Tue May 28 06:30:18 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5ABB21F972E for ; Tue, 28 May 2013 06:30:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IhZyr9PLCsCJ for ; Tue, 28 May 2013 06:30:13 -0700 (PDT) Received: from exprod6og127.obsmtp.com (exprod6og127.obsmtp.com [64.18.1.78]) by ietfa.amsl.com (Postfix) with ESMTP id 4DC3921F9727 for ; Tue, 28 May 2013 06:29:44 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob127.postini.com ([64.18.5.12]) with SMTP ID DSNKUaSxQ1HsfY0ofHErnbBk2j5sD/kglhUE@postini.com; Tue, 28 May 2013 06:30:05 PDT Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id r4SDTahK026938 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 28 May 2013 09:29:36 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Tue, 28 May 2013 09:29:36 -0400 From: "Gould, James" To: Gustavo Lozano , Alexander Mayrhofer , "tmch-tech@icann.org" , "provreg@ietf.org" Thread-Topic: [provreg] [tmch-tech] SMD: Restriction of XML DSIG parameter space ... Thread-Index: AQHOW6dl+l8itVCcBkya0il05kA47A== Date: Tue, 28 May 2013 13:29:35 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-ID: <4B101937A9FD12429D23D7352FCB56B6@verisign.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Otmar Lendl Subject: Re: [provreg] [tmch-tech] SMD: Restriction of XML DSIG parameter space ... X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2013 13:30:18 -0000 Gustavo, My feedback is below. --=20 =20 JG =20 =20 James Gould Principal Software Engineer jgould@verisign.com =20 703-948-3271 (Office) 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On 5/28/13 9:06 AM, "Gustavo Lozano" wrote: >Alex, all, > >Thank you for your feedback. > >TMVs (there is only one at the moment) are the only actors generating SMDs >and TMVs must use: xml-exc-c14n, RSA-SHA256, SHA256 and the RSA key size >is 2048 bits. During the LA meeting, we agreed on RSA2048 and SHA256. I >will add text in the new version of the draft to clarify this. Providing clarifying text makes sense, but I would make them recommendations (SHOULD) and not requirements (MUST) to support use of draft-lozano-tmch-smd beyond the TMCH. I believe this should not be much of an issue considering that there is a single set of producers following the same policies.=20 > >The SMD file downloaded by the TMH from the TMV is encoded in base64 (see >6.4 of draft-lozano-tmch-func-spec). The reason for the base64 encoding is >to mitigate the possiblity that the signature is invalidated by mistake >(e.g. sending the SMD by email). > >There is no recommendation/requirement for using an > instead of in the communication >channel between Registrars and Registries. Maybe a recommendation or >requirement for using in this channel is worth it? >Maybe the risk is low? Sometimes, it is cheaper wasting CPU cycles >(decoding base64) instead of troubleshooting. Comments? I assume that you mean adding this as a requirement in draft-lozano-tmch-func-spec. I recommend not adding a requirement to use instead of , since draft-tan-epp-launchphase-11 supports both and there are performance advantages to using over . It would be up to server policy whether to support both and , where I see for TMCH interoperability that must be supported. The can be an option if performance is a factor based on server policy and based on the preference of the client. > >Regards, > > >Gustavo > >On 5/27/13 7:39 AM, "Alexander Mayrhofer" >wrote: > >>All, >> >>looking at http://tools.ietf.org/html/draft-lozano-tmch-smd-02, the draft >>currently doesn't seem to restrict the set of XML Signature parameters to >>be used. The signature and normalization algorithm examples look >>surprisingly similar to RFC5105 (written by my colleague Otmar Lendl back >>in 2006/2007).=20 >> >>During his journey to implement the signature technoloy in our ENUM >>registry software, he found out that some options in XML DSIG >>(particularly the normalization options) are rather cumbersome and >>error-prone (AFAIR whitespace changes created by the validating XML >>parser triggering validation errors, etc.). Based on this practical >>experience, he restricted the parameter range for XML DSIG in >>http://tools.ietf.org/html/rfc5105#section-3 of RFC5105, in order to >>increase interopability. The concept described in RFC5105 has since been >>validated in implementations of a few ENUM registry installations >>(servers), as well as their ENUM registrars (clients). >> >>Since SMD essentially uses the same technology, i'm proposing that the >>authors also consider restricting the parameter range of XML DSIG in >>order to reduce implementation effort, and increase interopability. >> >>Comments? >> >>Alex >> >> From JGould@verisign.com Fri May 31 13:34:52 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC25221F8F7A for ; Fri, 31 May 2013 13:34:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.998 X-Spam-Level: X-Spam-Status: No, score=-3.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WkjF0WZbAE-M for ; Fri, 31 May 2013 13:34:48 -0700 (PDT) Received: from exprod6og102.obsmtp.com (exprod6og102.obsmtp.com [64.18.1.183]) by ietfa.amsl.com (Postfix) with ESMTP id 996B421F8E41 for ; Fri, 31 May 2013 13:34:44 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob102.postini.com ([64.18.5.12]) with SMTP ID DSNKUakJZKXomnYX2ei9iaKWzz/cq5T6nRAp@postini.com; Fri, 31 May 2013 13:34:47 PDT Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id r4VKYhZA014851 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 31 May 2013 16:34:43 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Fri, 31 May 2013 16:34:43 -0400 From: "Gould, James" To: EPP Provreg Thread-Topic: Launch EPP SDK 2.2.0.0 Preview Thread-Index: AQHOXj5HJiLTaYiEg0S24GW0ggJbQw== Date: Fri, 31 May 2013 20:34:43 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.173.152.4] Content-Type: multipart/mixed; boundary="_004_CDCE805E50999jgouldverisigncom_" MIME-Version: 1.0 Subject: [provreg] Launch EPP SDK 2.2.0.0 Preview X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 20:34:52 -0000 --_004_CDCE805E50999jgouldverisigncom_ Content-Type: multipart/alternative; boundary="_000_CDCE805E50999jgouldverisigncom_" --_000_CDCE805E50999jgouldverisigncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Verisign has released the fourth release of a preview version of the Launch= EPP SDK, named Launch EPP SDK 2.2.0.0. This SDK fully implements draft-ta= n-epp-launchphase-11 ( http://tools.ietf.org/html/draft-tan-epp-launchphase= -11 ) and draft-lozano-tmch-smd-02 ( http://tools.ietf.org/html/draft-lozan= o-tmch-smd-02 ), referred to simply as 11/02, and includes the following fe= atures that can be of use to multiple stakeholders: 1. Packet encoder / decoder (CODEC) that will encode the XML from object= s and decode the objects from XML. 2. Creation and validation code for signed marks (SMD) using an XML sign= ed mark or a base64 encoded signed mark that complies with draft-lozano-tmc= h-smd-02. 3. Use of a test CA issued certificate that is included in the signed ma= rk or base64 encoded signed mark that is chained to the test CA certificate= by the EPP Stub Server. A test certificate in a test Certificate Revocati= on List (CRL) is also validated by the EPP Stub Server. 4. Sample of poll messaging compliant with draft-tan-epp-launchphase-11 = in the EPP Stub Server. 5. A client API that utilizes the packet encoder / decoder (CODEC) along= with other code (e.g. transport, configuration, XML parsing pooling) to in= terface with an EPP server. 6. An EPP Stub Server that includes pre-defined responses to support the= client tests. The EPP Stub Server behavior can be easily customized to su= ite your testing needs. The Launch EPP SDK includes support for RFC 5730, 5731, 5732, 5733, 5734, 3= 915, and 5910. Verisign will be integrating the preview of the Launch Phase EPP Extension = into its Verisign Bundle EPP SDK. The Launch EPP SDK is open source, requires Java 6 or higher, and below are= the distributions and documents: * Unix Binary Distribution (.tar.gz) - http://www.verisigninc.com/asset= s/2-2-0-0/epp-launch-bundle-2.2.0.0-bin.tar.gz * Unix Source Distribution (.tag.gz) - http://www.verisigninc.com/asset= s/2-2-0-0/epp-launch-bundle-2.2.0.0-src.tar.gz * Windows Binary Distribution (.zip) - http://www.verisigninc.com/asset= s/2-2-0-0/epp-launch-bundle-2.2.0.0-bin.zip * Windows Source Distribution (.zip) - http://www.verisigninc.com/asset= s/2-2-0-0/epp-launch-bundle-2.2.0.0-src.zip * Readme File - http://www.verisigninc.com/assets/2-2-0-0/epp-launch.RE= ADME * Install Instructions - http://www.verisigninc.com/assets/2-2-0-0/epp-= launch.INSTALL * Change Log - http://www.verisigninc.com/assets/2-2-0-0/changelog.txt -- JG [cid:922F2D86-FC79-472E-A0CF-F88984FFA29E] James Gould Principal Software Engineer jgould@verisign.com 703-948-3271 (Office) 12061 Bluemont Way Reston, VA 20190 VerisignInc.com "This message (including any attachments) is intended only for the use of t= he individual or entity to which it is addressed, and may contain informati= on that is non-public, proprietary, privileged, confidential and exempt fro= m disclosure under applicable law or may be constituted as attorney work pr= oduct. If you are not the intended recipient, you are hereby notified that = any use, dissemination, distribution, or copying of this communication is s= trictly prohibited. If you have received this message in error, notify send= er immediately and delete this message immediately." --_000_CDCE805E50999jgouldverisigncom_ Content-Type: text/html; charset="us-ascii" Content-ID: <5623265A51DF3C4195A21B78C0912E5B@verisign.com> Content-Transfer-Encoding: quoted-printable
Verisign has released the fourth release of a preview version of the L= aunch EPP SDK, named Launch EPP SDK 2.2.0.0.  This SDK fully implement= s draft-tan-epp-launchphase-11 ( http://tools.ietf.org/html/draft-tan-epp-lau= nchphase-11 ) and draft-lozano-tmch-smd-02 ( http://tools.ietf.org/html/draft-lozano-tmch-smd-02 ), referred to simply as 11/02, and includes the following fea= tures that can be of use to multiple stakeholders:

  1. Packet encoder / decoder (CODEC) that will encode the XML from objects = and decode the objects from XML.    
  2. Creation and validat= ion code for signed marks (SMD) using an XML signed mark or a base64 encode= d signed mark that complies with draft-lozano-tmch-smd-02.
  3. Use of a= test CA issued certificate that is included in the signed mark or base64 e= ncoded signed mark that is chained to the test CA certificate by the EPP St= ub Server.  A test certificate in a test Certificate Revocation List (= CRL) is also validated by the EPP Stub Server.
  4. Sample of poll messaging compliant with = draft-tan-epp-launchphase-11 in the EPP Stub Server.
  5. A client API t= hat utilizes the packet encoder / decoder (CODEC) along with other code (e.= g. transport, configuration, XML parsing pooling) to interface with an EPP = server.  
  6. An EPP Stub Server that includes pre-defined respons= es to support the client tests.  The EPP Stub Server behavior can be e= asily customized to suite your testing needs.  
The Launch EPP SDK includes support for RFC 5730, 5731, 5732, 5733, 57= 34, 3915, and 5910.  

Verisign will be integrating the preview of the Launch Phase EPP Exten= sion into its Verisign Bundle EPP SDK.  

The Launch EPP SDK is open source, requires Java 6 or higher, and belo= w are the distributions and documents:

-- 

 

JG

 

 

Jame= s Gould

Princ= ipal Software Engineer

jgould@verisign.com

 = ;

703-9= 48-3271 (Office)

12061= Bluemont Way

Resto= n, VA 20190

Veri= signInc.com

“This message (including any attachments) is= intended only for the use of the individual or entity to which it is addre= ssed, and may contain information that is non-public, proprietary, privileg= ed, confidential and exempt from disclosure under applicable law or may be constituted as attorney work product. If yo= u are not the intended recipient, you are hereby notified that any use, dis= semination, distribution, or copying of this communication is strictly proh= ibited. If you have received this message in error, notify sender immediately and delete this message immedi= ately.”
--_000_CDCE805E50999jgouldverisigncom_-- --_004_CDCE805E50999jgouldverisigncom_ Content-Type: image/png; name="8A7A655D-9ED0-4D38-898D-E9E8B754666E[21].png" Content-Description: 8A7A655D-9ED0-4D38-898D-E9E8B754666E[21].png Content-Disposition: attachment; filename="8A7A655D-9ED0-4D38-898D-E9E8B754666E[21].png"; size=4109; creation-date="Fri, 31 May 2013 20:34:43 GMT"; modification-date="Fri, 31 May 2013 20:34:43 GMT" Content-ID: <922F2D86-FC79-472E-A0CF-F88984FFA29E> Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAEkAAABACAIAAADZHs1DAAAP1ElEQVRoBe2aa3CU1RnHN3vLJtmQ hEtiwlUBtZUUCiU6tU7wVhinjOB0xmJnFIdpO1Y6DY586Iwdo36gLc4Iip3pVAL9IKjTDnhDEEWC 1GoICHLRctEkXHIPuZHr7qa/c553T152N9lsNvnWM5nDec97Ls//+T+X854lZWBgwDFuRRaXOiUl hX2kHrcNr1vYfd1T0g/ACIVCQV0CgQD/8miwOZ1Ol8vldrupKTyOK9QU2ThpUA4w9Pf39/X19fT0 UCsYYHA6QcLiYKCwF2MEMNh8Pp/X6/V4PAxOXoDoFcYAG7ICplsXNvClpSFvipAimGy1wQmrMgV4 aUzxekEbLV8yPUlhE66u6YJkqT6fMjKDyjRs2GgaeNKA587OTqZnZGSMLYejx4biEautrQ3eUlNT LUiCx6AyjWHhAbKrqwuEwMNQxYyTYUzmjhIbboMo7e3tyIwoMYA5nZ+duXiyur6ju88u5ZL5s+ff mJ+TmUan4JUGNVbQ2tqKNvx+PwTaZ42uPRpseBeoYMygUvRoijp7AnuPXdhz9PyeyvPI7khxqtoU yTcDofk35j1674LH7luY7U8zVsoo2qgMc5gwYQIeaOaNrpEwNoCBqraujgBALDeoOnr6X9t/4rX9 x9t7gg6Xx+F0K1QEQOBRFKoBVYdCjoGgI6T+MtO9j9+74Nlf3gNChhiQHR0dwMvKykoSXmLYMEUY u3T5MoyxMZEDbJTK81fWlR242NrrcHsdToBpSBZpsKeps0gDocYWDDhC6i8zzbO9ZOWKH38/Ah5K hL1kjDMBbMQMDKa6pgaE6enpggp4r+z5cvOeLx0en6bLpRkTbIKKWjGnijoCgQ3qdB3sdwR6FcJg 8NF7Crc99XNeG/ZQIvkQ3xt1bhgpNrYhlMFYY0NDVna2Bczp/MPrh3dVVjncAHOrvxSwuSw3U3SF SVPIxDKpBVuYQOABMtg3f+aUA39aY/fApqYmLB89CmBZY+T1SA8EcIWb1dfXk8QIaFIUsKM1Dk+a w+1xuLQ1Ag9s1p9uC9rBTk2sUoRLq8Ojp6cy/UR100MvvK41oPkdGMjJySF3svXI8dhHjggbSDhD ED8wSxgTYLsqLihgbsRCULBp3gghBobyN5AY33NalKoeuA2rgInYs1rHU37m4rq/vW/gsReZk63Z 0S70CNsjwiakNTU2etxuAXax5dpf3juuuBJgFiQtPdgUKv3n1DZpPdrawFPDwvBoW/C8L79bceD4 eQOPcELMHB118bHhab29vYq0UIhjvGB77p+VHeRk7MpCIn5lgobRrHY5noCnQgrD5JX5sJJOPZ0Y q/h3rdn0NpsaePgbAkiPWXckjfjfOJytMHrcmngltnGsqqmyqllZUYozK82z4MY8tZNYmtnT6T5+ saWtV1DpXuARRYLB4ltyVWw0hZRA4VDS1Xfiu3pe1TR3vLDz4B9XLSGEAIlw0tzcTJ1oPoiPDXto uXoVzfkzM/kyQ4y/f3JW0QVpig3H7vXLJfkqEW3l4OlLd/95n7JbU0KB4rkTDz6z3HTYGyVlH5+o alTjQ6FtHx575hfFvAUeXodaESNRbHFsErWRQxsaGpRBpqRQX2ru/LKmRScxZZBtnd0lr31oF9G0 l9w2rfjmXJWppdDo79n+xL1mgL1RVd+6+f1jWmUq9dc0tb/z+TfsTmEYB2jEkLZ91vDtONgwQhgj ZavPaf1N/enZegUM3uTP7f3Hga8OnqyKuc323xQ7OH9ICQaefWjRrCkTYo5c/fK7yshlTXVkc739 +RlGanQDREvEEI+IOT1mZxxsBH0WlfO+uioIhQ6dbdSuhffrUI5Aqf7SNz6NuTpInl2xQHlXKJDl CZU8sCDmsN1fnC0/16wCiVqTU6jS3cGvqoUoakk87B9z+lCdcbChKoAJY7SBV9PUobMTE3VwQ9Me X/nXtds/Ph5zj5JlhVk+J2erTY/+JDvDF3tM2ceaNI41kjzw5BTMsrWzx8DD8caBt76+YEDZlaYt 1N4bUqo1fyBE39700rf+09rZHS16dkbqplWL5xf4Vy9Rp+HoUvrG4eo2/emgzmgUWVzBO/Fdrdgk vZjlGPPG0nClCVP1uXpIE6qtPKVBOtF6dUv3pt2faeEiK1Bt/+39kb36ufVaz6YPz6jEDf+WvvQL Mor+WhVsSozwfVnMdWJ2DpcDZF0MElj9+kKuvZuERdEJ16p1B/nAk/bcv46svn/RrLxs3XVdBaUp KzYoR7UX1IS7qg+I62+BLALVUGSQGQbkyM/N129m31jnFukQ3kBoey9bWhuTudWXmze9ZOsQ+aBw 1oN3znOkZTsyJg3+pecQh3QCDFvB4AaqR1NlgZI3IwfG+OGwqdda0xg6qRPjnJGdqveIAKb7OBx6 fG8frR4qH2xaXZzl12diuDJ/KjbiYNevqriytGboMsLooSOq4mBDT1wbWLwFgz5sx3xZyh1B2GaU fDqolJR9FHNn8kHJT2+77rRlH6ew8EUnqHRjYGD65Ex1Ka0Lyk2INJaLg43DzqRJk8BG4WQAgd/L y9ASKFfQsoWl4UH7z4lL7cPkg5k5sdKAAFPLWahYnNuU6ZMnWDFkYEBpOcIt9fbDVHGwyRcUVyNg 6+ntxeVmT0pVx6jBb2cjjd6FtOtJKyk7MFQ+KF35Qz6xBwViHWV++m9wzRD03nXrVIs09tZxUhxk cG68VhxsqIrEkpOdDWPwxi43TUzVt1TcC+g/uyHRxnncqW39rtK3hsgHxbfOn04g1WFJARNcRkE0 9LKh4AOL5hjSerq7EWOMecMSIC0/Px9UwOMzceE0/+QMtyUBcqg7Of5EOK1Jwo/Ht/m9So6/0Zol oVXVNmueBJidNFmKNdVF2LKFsxVvmjTUihhj7G8GG1KyC2dLEN4xw69ub7QEgyAlDIgT6qCijr9R pfTNf7f1Ch4YE1O0kabW5Nqr/+E7b8HfLN50Khh7bMjGVSQ2mX/DDRBHsEKFS+dOSHMNqAO+OgSL 74VVrkxUZUYss/ybuoh8UNXYvnnfaXUNQRkExly9iFpKX10G+p56sMgAQ6EYJGJEKSpORxx/YzZW zlf9DwoL+aUQeHyDp7oGfnW7/nYWNataY6OWBtN0UFm95QP7/qu37FUpnnAKfqWFsEbURI0KfQFs +aJpE/3GIFEoAiTqbEoE+95DtbGHvLy8adOmCTwunublehfc4NWWGWZPtG6FUO1Lbm91c9emdypk WT7DYVJhpoijGkiWjrilDMzLz/j9zxYpLwt7mvwEOZRsw/SPCBs649ejosWLyePA69W/jD6+aNL0 TKe+NhV42j5F/cKeTnelbx6WfKDcT04h8lZpQXOlv+5knUxP8K+/vl9QCTyiCVuPgjQwu0pLS4eB Lq+IKOQWNiDF1dXVYVB89fi8njtmZp6u62rvjfpk5IwiQcXh6O3rr2u6WtXQ/mZFtcKmStjBFHth eMFApjuwY+19N+XlMEIdwrjCCAYzMzPBlmhmU5uwAIqRVtyaKNLS0rJv//5Lly6xGT/iZPj9AYfr xU8bLnaElNzqRkDukuUTUx8TddxT0UUNIHnoqIizKfYEWBBVwdi2J+6bN30SK8tPKMjD3dbEiRPx iLiyxRyQADa0QH6rra19b88efkayw3v3m7aPLnQp0YmB6kssjA1IFKU+/cVptXUUUf7JlZ6y5x/N yN782J1ZGT4FTBcuDjP9fo57OFuiac3gTAAbc/ABAsmV2toP9u418Pgxghh9rrlv29Hmpi5NINjI 4NQUqa0NNWkqPMIbpAVmZPseL5774KJZYVBwlkLQz87Kys3NhTf6ramJ/5MYNtYHHj/ocM1sh+f2 eOTHpM8vdh3+ruPrhm7NXvhT2vqGYbZgA1VozpSMh4tmLl84w6CiweJYfu4UVYj7yQBjs4SxCTzY u3r16ifl5TU1NUigfkB1uVAzJkTIaekOfl3f9d/G3sbOvsZr/U3X1HVLps81c2J6flba3Dz/XTfn FWSnMYW5jBcM5DHaBfn5+FiSjLEdZTTYmCYK5grs9JkzlZWVJAaBh5QKIeda/R9nlNxadgEgtYUG VBqZOqeyXCgEpKkFBfJLt6DVEo6+GiU2NiS04PHYZ0Nj4+lTp85duECXoYIjEgg9/LcfQBqcNpaY TgEXMPhpG1Rgww6ZOOrgEaGG0WOThYRAEDa3tJw/f/7Ct98SCTQfihXT4AGcBApmCXtkTMATCfNy c/kNEVTEesZHyJfMY7LYZG/Uj7eQIQBZ39DAz6tkQvXY3W2HRxuLJeqo+D55MkdwIOGi/IgB4GRg xJw7NthkaTgUkPK5QI3R0kM/AwQkJgcSKKKmCIcxJUu+cyyxGWnEl4BEkTav8CIKCCnSNuPHqTEu 2MZJ1kSXHUvfTXTv8R7/f2zjreHxWT/hS4hkxLhy5QqHNVaYOnUqoX/4pS5wGNCFnE4CHH5wzLfu jS++eOXyZd5t2LBB9tu9e3d5eTk9a9as2bp1a/S0tWvXzp49+9VXXyVZ298iRFFR0dKlS+k0b196 6SUeQcVSJD0znpErV65kRzBs2bKF/mXLlsncYQYzbN26ddQFU6euf/ppGma6SLVz586TJ0/Sj/DO 24uKaFGki8Y5LTFJdt68efrNSCtE37t376lTp6InRABjQEVFxfPPP09+jxgMMKCKFpCBIoNf0fjN YPg4dOiQeTQNVIZRiHW4CwsLd+3axTtIWLx4Mad7oZF+M2HOnDlPPvmkeYxoGGY2btzIK4SOUAqq FVmLi4tXrFgBHlTAMFQbbZm8EskeeeQR5GFBoYKLtoh9GQmSiE4MyojqxpThFzzwtmrVKmNmdmxI tm/fPrOKWI55lAYGKQ2RLOKtPLIFPKBXZALkUGPoRyQBRhupMNdol2MjWImGZ5ZVsQSzZBBDsQex TCSw616MzcyJwIZr8UqYoQHJZqQ00KWoz74OW+BvBkDEFGEJecSm5C3jCwoKpM10BIZ8NBUx1zwq bMYsASa82UljgCjbzIloGKrpR4sYXsQAHn+3di0mhCeLwdODZDt27IjYyEzkrYyxLy6dMoaNkNau LDPXNBQ2Y5Zsb2aaETTQjTFie7+0MZivTp4UoQEW7UIyTJyNNmywkRjIZR2i7WsKIbzFaNmX6McY O3syWGgnRNkB29ehbZ1LltiUjedgRfZxfKoQD0xBOPtbTPShlSulJ1oI+omchEQizZEjR4hV9PCx J+ONl8ojtTAJIWVlZYL8iwrrZtqMkQZeE23/9jGKN4rdNuxteQsnkoLkMTpsogtmiUmDxO6rTEG1 ol2MUFaQGrvCZIyjSidWwDqMp6bYx0e3iaVoLbpfeixsGBI2I3qyR56YihH3jXBiHF0AIBDY7G8J GPDDecDIyiO7SEzCumQX4RC069evh38ZzFsEE6+jjdARg9GF/a0d5/8ActOtScHpPCkAAAAASUVO RK5CYII= --_004_CDCE805E50999jgouldverisigncom_--