gmane.ietf.provreg

Launch Phase EPP Extension Version 11

Gould, James — 2013-05-17T19:40:44

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."

gtld-tech mailing list

Francisco Arias — 2013-05-16T23:29:40

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,

Re: Custom phases with claims

Gould, James — 2013-05-16T14:31:27

James,

My feedback is below.

--

JG

[cid:A9AFE7A3-373A-4E10-A8E0-34ACE123DC68]

James Gould
Principal Software Engineer
jgould< at >verisign.com<mailto:jgould< at >verisign.com>

703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com

From: James Mitchell <james.mitchell< at >ausregistry.com.au<mailto:james.mitchell< at >ausregistry.com.au>>
Date: Thursday, May 16, 2013 1:23 AM
To: EPP Provreg <provreg< at >ietf.org<mailto:provreg< at >ietf.org>>
Subject: [provreg] 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?

The passing of the "claims" and the "landrush" in the phase element together in the draft is to cover a common use case of the overlapping "claims" phase with a "landrush".  Since SHOULD is used, this is recommended and i

Custom phases with claims

James Mitchell — 2013-05-16T05:23:05

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

Re: Launchphase and

Francisco Obispo — 2013-05-14T19:38:05

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" <JGould< at >verisign.com> wrote:

  that the servers implement is very undesirable, so please provide your feedback.  

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

Re: Launchphase and

Gould, James — 2013-05-14T16:43:41

Francisco,

I believe what you propose makes sense.  Changing to use the <extension> section instead of the <resData> 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.

Thanks,

--

JG

[cid:C52435F1-F67B-4EC0-8F83-03FB0E79EBE3]

James Gould
Principal Software Engineer
jgould< at >verisign.com

703-948-

Re: Path to standard?

Hollenbeck, Scott — 2013-05-13T11:07:35

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
_______________________________________________
provreg mailing list
provreg< at >ietf.org
https://www.ietf.org/mailman/listinfo/provreg

Re: Path to standard?

Andrew Sullivan — 2013-05-12T15:12:41

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

Path to standard?

Francisco Obispo — 2013-05-11T15:44:34

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

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

Patrick Mevzek — 2013-05-10T11:03:54

Hello Francisco,

Francisco Obispo <fobispo< at >isc.org> 2013-05-06 21:19

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.

Launchphase and

Francisco Obispo — 2013-05-10T05:07:25

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:

Re: Implementation of EPP AuthInfo

Keith Gaughan — 2013-05-09T13:12:40


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 sugge

Launch EPP SDK 2.1.0.0 Preview

Gould, James — 2013-05-08T14:43:51

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 wit

Re: Implementation of EPP AuthInfo

Rubens Kuhl — 2013-05-07T13:37:41

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. 


Rubens


Em 07/05/2013, às 10:00:000, Vlad Dinculescu escreveu:


_______________________________________________
provreg mailing list
provreg< at >ietf.org
https://www.ietf.org/mailman/listinfo/provreg

Re: Implementation of EPP AuthInfo

Vlad Dinculescu — 2013-05-07T13:00:35

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" <JGould< at >verisign.com> wrote:


_______________________________________________
provreg mailing list
provreg< at >ietf.org
https://www.ietf.org/mailman/listinfo/provreg

Re: Implementation of EPP AuthInfo

Gould, James — 2013-05-07T12:42:39

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

Re: Implementation of EPP AuthInfo

Michele Neylon :: Blacknight — 2013-05-07T09:35:15

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/mail

Re: Implementation of EPP AuthInfo

InterNetX - Volker Janzen — 2013-05-07T09:10:22

Hi,

On 05/07/2013 10:44 AM, Michele Neylon :: Blacknight wrote:

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

Re: Implementation of EPP AuthInfo

Vlad Dinculescu — 2013-05-07T09:04:38

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" <michele< at >blacknight.com> wrote:


Kind Regards,
Vlad Dinculescu
-------------------------
Domain Name Services
_______________________________________________
provreg mailing list
provreg< at >ietf.org
https://www.ietf.org/mailman/listinfo/provreg

Re: Implementation of EPP AuthInfo

Michele Neylon :: Blacknight — 2013-05-07T08:44:35

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


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


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

Re: Implementation of EPP AuthInfo

Vlad Dinculescu — 2013-05-07T06:51:55

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:


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.


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.


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.


_______________________________________________
provreg mail