Re: Launch Phase EPP Extension Version 07

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 protected]<mailto:[email protected]>>
Date: Monday, March 4, 2013 5:58 PM
To: "Wodjenski," <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, "'[email protected]<mailto:'[email protected]>'" <[email protected]<mailto:[email protected]>>
Subject: Re: [provreg] Launch Phase EPP Extension Version 07

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

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

Hi Jim –

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

Sharon

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

Sharon,

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

Jim

________________________________
From: Wodjenski, Sharon [[email protected]<mailto:[email protected]>]
Sent: Monday, March 04, 2013 4:40 PM
To: Gould, James; [email protected]<mailto:[email protected]>; '[email protected]<mailto:'[email protected]>'
Subject: RE: Launch Phase EPP Extension Version 07
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.





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?



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:

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.

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?

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

Thanks in advance for your assistance.

Regards,

Sharon

From:[email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Gould, James
Sent: Monday, March 04, 2013 10:08 AM
To: [email protected]<mailto:[email protected]>
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

_______________________________________________
provreg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/provreg