Subject: Re: [provreg] Launch Phase EPP Extension Version 07

From: "Wodjenski, Sharon" <[email-masked]>
Date: Mon, 4 Mar 2013 16:40:21 -0500

Hi Jim and Team,

Thank you for the latest draft.

We have a few questions, or thoughts, for which we would like confirmation.

1.       On the Launch Status transition and Poll Message for a Launch Registration (FCFS) we envision the following:

a.       Assuming it is the first valid, the LaunchRegistration object immediately goes to a launch Status of pendingAllocation.

b.      When the LaunchRegistration is provisioned into General Availability (Steady State), it goes to a launch status of allocated.

c.       Additionally, when provisioning occurs, a poll message is inserted which uses the domain:panData and launch:infData elements to indicate that the object is allocated.

d.      The applicationID is not included in the launch:infData on the Poll message for LaunchRegistration objects.

2.       For an Info command:

a.       if includeMark=true, then the <mark:mark> element is returned  - not the <smd:signedMark> or the <smd:encodedSignedMark> .

b.      the response does not differ depending on whether the requestor is the sponsoring or non-sponsoring registrar.

Thanks in advance for your assistance.

Regards,

Sharon

From: [email-masked] [mailto:[email-masked]] On Behalf Of Gould, James
Sent: Monday, March 04, 2013 10:08 AM
To: [email-masked]
Subject: [tmch-tech] Launch Phase EPP Extension Version 07

Wil Tan, Gavin Brown and I have updated the Launch Phase EPP Extension Mapping to Version 07.  The IETF Internet-Draft Submission page is suspended until 2013-03-11, so the draft is attached.  We will post the draft once the IETF Internet-Draft Submission page opens.  This version includes the following changes:

 1.  Proof-read grammar and spelling.
 2.  Changed "pendingAuction" status to "pendingAllocation", changed "pending" to "pendingValidation" status, per proposal from Trung Tran and seconded by Rubens Kuhl.
 3.  Added text related to the use of RFC 5731 pendingCreate to the Application Identifier section.
 4.  Added the Poll Messaging section to define the use of poll messaging for intermediate state transitions and pending action poll messaging for final state transitions.
Please reply with any feedback.

Thanks,

JG

James F. Gould
Verisign

---

From: "Gould, James" <[email-masked]>
Date: Mon, 4 Mar 2013 22:17:23 +0000

Sharon,

My answers to your questions are below prefixed with "JG-".

Jim

________________________________
From: Wodjenski, Sharon [[email-masked]]
Sent: Monday, March 04, 2013 4:40 PM
To: Gould, James; [email-masked]; [email-masked]'
Subject: RE: Launch Phase EPP Extension Version 07

Hi Jim and Team,

JG - I believe that a launch registration immediately allocates so there is no use of the launch statuses or the poll messaging.  The allocation is taking one of the launch applications and transitioning it to a standard domain name.  Do you have a need to ensure that a launch registration, via a FCFS model, does not immediately resolve?

2.       For an Info command:

a.       if includeMark=true, then the <mark:mark> element is returned  – not the <smd:signedMark> or the <smd:encodedSignedMark> .

JG - Yes, if the includeMark=true just the <mark:mark> element is returned.  Inclusion of the wrapping <smd:signedMark> and <smd:encodedSignedMark> is needed only to trust the validity of the <mark:mark>, but since the registry has already done the validation on the create the info response can just include the <mark:mark>.  The inclusion of the <mark:mark> element may be based on server policy.  The draft does not specify that now, but I believe that it should be added.  What do you believe?

Regards,

Sharon

Thanks,

JG

James F. Gould
Verisign

---

From: "Wodjenski, Sharon" <[email-masked]>
Date: Mon, 4 Mar 2013 17:41:58 -0500

Hi Jim -

Thanks for the really quick response!  My notes prefixed with 'SEW".

Sharon

From: Gould, James [mailto:[email-masked]]
Sent: Monday, March 04, 2013 5:17 PM
To: Wodjenski, Sharon; [email-masked]; [email-masked]'
Subject: RE: Launch Phase EPP Extension Version 07

Sharon,

Jim

To: Gould, James; [email-masked]<mailto:[email-masked]>; [email-masked]'

SEW - There may be some lag time between accepting a valid launch registration and allocation/resolution.  We would like to account for that possibility in the model.

2.       For an Info command:

SEW - Thanks for the confirmation on returning the <mark:mark>.  Yes - it would be great if the draft called out that the return of the <mark:mark> is based on server policy.  We are not really sure how sensitive the mark information is and may want to consult IP experts for advice on server policy/when to return <mark:mark>.

Regards,

Sharon

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Gould, James
Sent: Monday, March 04, 2013 10:08 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [tmch-tech] Launch Phase EPP Extension Version 07

Thanks,

JG

James F. Gould
Verisign

---

From: "Gould, James" <[email-masked]>
Date: Mon, 4 Mar 2013 22:58:45 +0000

Sharon,

So you would like the launch registration to be able to have the same application statuses and launch poll messaging but to just not support the use of the application id?  Would you still classify your launch registration as a pendingCreate?  I see the following options:

  1.  Treat a launch registration as a pendingCreate domain name according to RFC 5731 with the pending action poll message and without the launch specific statuses.  In this case the launch registration is accepted using the launch extension, put in pendingCreate, but without the ability for someone else to submit an application for the same domain name.  The use of the pending action poll message would be used as defined in RFC 5731 once it is accepted.  No change is needed to the launch extension with this option.
  2.  Have both launch applications and launch registrations support the use of the launch statuses and poll messaging defined in the launch extension.  The only difference between the two is that multiple launch applications can be submitted for the same domain name with a unique applicationID assigned for each.  A launch application always uses the pendingCreate RFC 5731 status while a launch registration MAY use the the pendingCreate RFC 5731 status.  We would need to add text to the launch extension to describe the hybrid use of the launch statuses and poll messaging.

Can you think of any other options?  Which option do you prefer?

Thanks,

Jim

Sent: Monday, March 04, 2013 5:41 PM

Hi Jim –

Thanks for the really quick response!  My notes prefixed with ‘SEW”.

Sharon

Sharon,

Jim

SEW – There may be some lag time between accepting a valid launch registration and allocation/resolution.  We would like to account for that possibility in the model.

2.       For an Info command:

SEW – Thanks for the confirmation on returning the <mark:mark>.  Yes – it would be great if the draft called out that the return of the <mark:mark> is based on server policy.  We are not really sure how sensitive the mark information is and may want to consult IP experts for advice on server policy/when to return <mark:mark>.

Regards,

Sharon

Thanks,

JG

James F. Gould
Verisign

---

From: "Tran, Trung" <[email-masked]>
Date: Wed, 6 Mar 2013 12:15:33 -0500

Jim,
I'm not quite sure I've grasped those options.  Let me try to make it clearer on what different sunrise systems behaviors could be and why we think the applicationID should be optional in the poll message.

Launch Registration (First-come First served):

 *   No application id as it is not needed
 *   Assuming there's no additional validation needed, when application is successfully created, the application status will immediately to go "pendingAllocation".  Though this application will eventually be the "winner", the status IS NOT "allocated" as it might not be provisioned as a domain.  This potential delay could be minutes/hours/days depending on different factors.  Registry might have rules and not want domains in the zone until some date in future.  Registries might want to do additional processing on these applications before provisioning them in the live system.  Also no poll message is needed for this as the "pendingAllocation" status is a direct result of the create request from the registrar.
 *   When the application moves to "allocated" status (meaning the registrar can now manage the domain and have it resolvable in dns), a poll message will be created for the registrar.
 *   Theoretically, the application could be moved "rejected" status.  The additional processing/policies by the registry might have decided to reject the application.  A poll message will be created for the registrar.  For this case, registry would probably have to re-open this domain name for another application.

Launch Application (allows multiple applications for same domain name):

 *   Application id as it is REQUIRED.
 *   Assuming there's no additional validation needed, when application is successfully created, the application status will immediately to go "pendingAllocation".  No poll message is needed for this as the "pendingAllocation" status is a direct result of the create request from the registrar.
 *   When the application moves to "allocated" status or "rejected" status  a poll message will be created for the registrar.

In both Launch Registration and Launch Application cases above, there's a need for poll message.  So application ID should be optional in the poll message depending if it's a Launch Registration or Launch Application.

I'm not sure if the EPP pendingCreate status plays much of a role in either case. I could see the need for it for Launch Application.  But if it's been allocated, should the pendingCreate status be removed?

Thanks,
Trung

From: <Gould>, James <[email-masked]<mailto:[email-masked]>>
Date: Monday, March 4, 2013 5:58 PM
To: "Wodjenski," <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>'" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [provreg] Launch Phase EPP Extension Version 07

Sharon,

Thanks,

Jim

________________________________
From: Wodjenski, Sharon [[email-masked]<mailto:[email-masked]>]
Sent: Monday, March 04, 2013 5:41 PM
To: Gould, James; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>'
Subject: RE: Launch Phase EPP Extension Version 07

Hi Jim –

Sharon

From: Gould, James [mailto:[email-masked]]
Sent: Monday, March 04, 2013 5:17 PM
To: Wodjenski, Sharon; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>'
Subject: RE: Launch Phase EPP Extension Version 07

Sharon,

Jim

________________________________
From: Wodjenski, Sharon [[email-masked]<mailto:[email-masked]>]
Sent: Monday, March 04, 2013 4:40 PM
To: Gould, James; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>'
Subject: RE: Launch Phase EPP Extension Version 07
Hi Jim and Team,

2.       For an Info command:

Regards,

Sharon

From:[email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Gould, James
Sent: Monday, March 04, 2013 10:08 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [tmch-tech] Launch Phase EPP Extension Version 07

Thanks,

JG

James F. Gould
Verisign

---

From: "Gould, James" <[email-masked]>
Date: Wed, 6 Mar 2013 17:54:59 +0000

Trung,

I believe the key is what the definition is for an application and for the term "allocation".  Currently, an application supports overlapping registrations for the same domain name that has one of the applications allocated to a domain.   I view the term "allocation" as the mechanism of selecting one of the applications that is "allocated".  I believe that you are extending the use of the term allocation to also apply to the delay in a launch registration in resolving.  In the case of launch registrations (first-come first-serve) there are multiple steps that the server can take to accomplish this independent of the use of the launch statuses (e.g. "pendingAllocation").  These include:

  1.  The server could treat the registration as a standard RFC 5731 pendingCreate, with offline validation or processing, that once the offline validation or processing is complete will be either approved or denied.  Once approved it is assumed that it would resolve.  In this case the <domain:panData> poll message would be used to inform the client of the result without the use of the launch extension.
  2.  The server sets the initial status to serverHold that will get removed once it follows the server processing to enable it to resolve.  It would be up to server policy what those steps are and how long the steps take.  The removal of the serverHold status should result in a poll message as well which should contain the <domain:infData> element.  I believe this option is a stretch, but it is an option.

If there is the desire to support the launch statuses and the poll messaging for launch registrations as well as launch applications that can be done; although we would need to be clear on the definition of allocation.  The <launch:applicationID> element is already optional for the <launch:infData> element, so it is really only a text update to support the statuses and poll messaging for launch registrations  as well as launch applications.

If the launch registration does utilize the launch statuses and poll messaging, it should follow the pendingCreate flow to be consistent for the clients.

What method do you feel is needed?  Any thoughts from others on this support?

Thanks,

Jim

________________________________
From: Tran, Trung [[email-masked]]
Sent: Wednesday, March 06, 2013 12:15 PM
To: Gould, James; Wodjenski, Sharon; [email-masked]; [email-masked]'
Subject: Re: [provreg] Launch Phase EPP Extension Version 07

Jim,

Thanks,
Trung

From: <Gould>, James <[email-masked]<mailto:[email-masked]>>
Date: Monday, March 4, 2013 5:58 PM
To: "Wodjenski," <[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>'" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [provreg] Launch Phase EPP Extension Version 07

Sharon,

Thanks,

Jim

Hi Jim –

Sharon

Sharon,

Jim

2.       For an Info command:

Regards,

Sharon

Thanks,

JG

James F. Gould
Verisign

---

From: "Gould, James" <[email-masked]>
Date: Wed, 6 Mar 2013 17:54:59 +0000

Trung,

Thanks,

Jim

Jim,

Thanks,
Trung

Sharon,

Thanks,

Jim

Hi Jim –

Sharon

Sharon,

Jim

2.       For an Info command:

Regards,

Sharon

Thanks,

JG

James F. Gould
Verisign