headers
Gould, James | 17 May 2013 21:40
Picon
Favicon

Launch Phase EPP Extension Version 11

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 http://tools.ietf.org/html/draft-tan-epp-launchphase-11.  This version includes the following change:

1. Moved the claims check response <launch:chkData> element under the <extension> element instead of 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 addressed, and may contain information that is non-public, proprietary, privileged, confidential and exempt from disclosure under applicable law or may be constituted as attorney work product. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this message in error, notify sender immediately and delete this message immediately.” 
_______________________________________________
provreg mailing list
provreg <at> ietf.org
https://www.ietf.org/mailman/listinfo/provreg
Permalink | Reply | 0 comments |
headers
Francisco Arias | 17 May 2013 01:29
Picon
Favicon

gtld-tech mailing list

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,

--

-- 
Francisco Arias
ICANN technical staff

_______________________________________________
provreg mailing list
provreg <at> ietf.org
https://www.ietf.org/mailman/listinfo/provreg
Permalink | Reply | 0 comments |
headers
James Mitchell | 16 May 2013 07:23
Picon

Custom phases 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 "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 to provide sub-phase information during claims. Claims information may be provided with other phases (landrush, open) without explicitly providing a "claims" phase value, and servers have to code for missing claims information regardless (e.g. It is possible to provide "sunrise" with claims information, and "claims"  with mark information).

I also dislike the use of the term "custom" - registries will operate sunrises 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 instead 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

_______________________________________________
provreg mailing list
provreg <at> ietf.org
https://www.ietf.org/mailman/listinfo/provreg
Permalink | Reply | 1 comment |
headers
Francisco Obispo | 11 May 2013 17:44

Path to standard?

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 
Director of Applications and Services - ISC
email: fobispo <at> isc.org
Phone: +1 650 423 1374 || INOC-DBA *3557* NOC
PGP KeyID = B38DB1BE

_______________________________________________
provreg mailing list
provreg <at> ietf.org
https://www.ietf.org/mailman/listinfo/provreg
Permalink | Reply | 2 comments |
headers
Francisco Obispo | 10 May 2013 07:07

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 provisioning an object
   using the <create> 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 <extension> section:

   S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
   S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
   S:  <response>
   S:    <result code="1000">
   S:     <msg>Command completed successfully</msg>
   S:    </result>
   S:    <resData>
   S:     <launch:chkData
   S:      xmlns:launch="urn:ietf:params:xml:ns:launch-1.0">
   S:      <launch:phase>claims</launch:phase>
   S:      <launch:cd>
   S:        <launch:name exists="0">example1.tld</launch:name>
   S:      </launch:cd>
   S:      <launch:cd>
   S:        <launch:name exists="1">example2.tld</launch:name>
   S:        <launch:claimKey>abc123</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="1.0" encoding="UTF-8" standalone="no"?>
   S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
   S:  <response>
   S:    <result code="1000">
   S:     <msg>Command completed successfully</msg>
   S:    </result>
   S:    <extension>
   S:     <launch:chkData
   S:      xmlns:launch="urn:ietf:params:xml:ns:launch-1.0">
   S:      <launch:phase>claims</launch:phase>
   S:      <launch:cd>
   S:        <launch:name exists="0">example1.tld</launch:name>
   S:      </launch:cd>
   S:      <launch:cd>
   S:        <launch:name exists="1">example2.tld</launch:name>
   S:        <launch:claimKey>abc123</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 unnecessary processing and confusion.

Does anyone feel the same?


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

_______________________________________________
provreg mailing list
provreg <at> ietf.org
https://www.ietf.org/mailman/listinfo/provreg
Permalink | Reply | 2 comments |
headers
Keith Gaughan | 9 May 2013 15:12
Favicon
Gravatar

Re: Implementation of EPP AuthInfo

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 <fobispo <at> isc.org> 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
<contact:panData> 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. <http://blacknight.com/>
12A Barrowside Business Park, Carlow, Ireland
Registered in Ireland, Company No.: 370845
_______________________________________________
provreg mailing list
provreg <at> ietf.org
https://www.ietf.org/mailman/listinfo/provreg
Permalink | Reply | 0 comments |
headers
Gould, James | 8 May 2013 16:43
Picon
Favicon

Launch EPP SDK 2.1.0.0 Preview

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 features 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 validation code for signed marks (SMD) using an XML signed mark or a base64 encoded 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 encoded signed mark that is chained to the test CA certificate by the EPP Stub 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 that 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 responses to support the client tests.  The EPP Stub Server behavior can be easily customized to suite your testing needs.  
The Launch EPP SDK includes support for RFC 5730, 5731, 5732, 5733, 5734, 3915, 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:

-- 

 

JG

 

 

James Gould

Principal Software Engineer

jgould <at> 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 the individual or entity to which it is addressed, and may contain information that is non-public, proprietary, privileged, confidential and exempt from disclosure under applicable law or may be constituted as attorney work product. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this message in error, notify sender immediately and delete this message immediately.” 
_______________________________________________
provreg mailing list
provreg <at> ietf.org
https://www.ietf.org/mailman/listinfo/provreg
Permalink | Reply | 0 comments |
headers
Michele Neylon :: Blacknight | 7 May 2013 11:35
Favicon
Gravatar

Re: Implementation of EPP AuthInfo

Volker

I *think* I've seen a couple of ccTLDs offer a sort of "self service" portal that allows registrants to do
some maintenance using this kind of method, though the problem is that doing this means the data we (the
registrar) hold is out of date.

We've also seen ccTLD registries allow domain holder (registrant) transfers without informing the
registrar of record.
Very very annoying

Regards

Michele


Mr Michele Neylon
Blacknight Solutions ♞
Hosting & Domains
ICANN Accredited Registrar
http://www.blacknight.co

http://blog.blacknight.com/

Intl. +353 (0) 59  9183072
US: 213-233-1612 
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

_______________________________________________
provreg mailing list
provreg <at> ietf.org
https://www.ietf.org/mailman/listinfo/provreg
Permalink | Reply | 0 comments |
headers
Michele Neylon :: Blacknight | 7 May 2013 10:44
Favicon
Gravatar

Re: Implementation of EPP AuthInfo


On 7 May 2013, at 07:51, Vlad Dinculescu <sasha <at> dnservices.co.za> wrote:

> Hi Francisco,
> 
> Thanks for the reply, please see responses inline below.
> 
> On 07 May 2013, at 8:33 AM, Francisco Obispo <fobispo <at> isc.org> 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.

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

> 
>> 
>> Some thoughts below:
>> 
>> 
>> On May 6, 2013, at 11:23 PM, Vlad Dinculescu <sasha <at> dnservices.co.za> 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.
>>> 
>> 
>> 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.
> 
> We did identify this issue as well, knowing that the sponsoring registrar would have access to the code. 
> Does an implementation exist where the AuthInfo is used as an out-of-band means of authorisation from the registrant.
> 
>> 
>>> 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.
>>> 
>> 
>> 
>> 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.
>> 
> 
> 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.
> 
>> 
>>> Regards,
>>> Vlad Dinculescu
>>> --------------------------------
>>> Domain Name Services
>>> _______________________________________________
>>> provreg mailing list
>>> provreg <at> ietf.org
>>> https://www.ietf.org/mailman/listinfo/provreg

>> 
>> Francisco Obispo 
>> Director of Applications and Services - ISC
>> email: fobispo <at> isc.org
>> Phone: +1 650 423 1374 || INOC-DBA *3557* NOC
>> PGP KeyID = B38DB1BE
>> 
> 
> _______________________________________________
> provreg mailing list
> provreg <at> ietf.org
> https://www.ietf.org/mailman/listinfo/provreg


Mr Michele Neylon
Blacknight Solutions ♞
Hosting & Domains
ICANN Accredited Registrar
http://www.blacknight.co

http://blog.blacknight.com/

Intl. +353 (0) 59  9183072
US: 213-233-1612 
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

_______________________________________________
provreg mailing list
provreg <at> ietf.org
https://www.ietf.org/mailman/listinfo/provreg
Permalink | Reply | 2 comments |
headers
Vlad Dinculescu | 7 May 2013 08:23
Picon

Implementation of EPP AuthInfo

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 <at> ietf.org
https://www.ietf.org/mailman/listinfo/provreg
Permalink | Reply | 5 comments |
headers
Francisco Obispo | 6 May 2013 21:19

New Version Notification for draft-obispo-epp-idn-03.txt

Just updated the draft to the latest comments/suggestions.

Begin forwarded message:

> From: internet-drafts <at> 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 <lem <at> isc.org>, Francisco Obispo <fobispo <at> isc.org>, Luis Enrique Munoz <lem <at> isc.org>
> 
> 
> 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.
> 
> 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=draft-obispo-epp-idn-03
> 
> 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.
> 
> 
> 
> 
> The IETF Secretariat

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

_______________________________________________
provreg mailing list
provreg <at> ietf.org
https://www.ietf.org/mailman/listinfo/provreg
Permalink | Reply | 1 comment |

Gmane