Re: Launch Phase EPP Extension Version 07

Sharon,

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

Jim

________________________________
From: Wodjenski, Sharon [[email protected]]
Sent: Monday, March 04, 2013 4:40 PM
To: Gould, James; [email protected]; '[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?




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?

Thanks in advance for your assistance.

Regards,

Sharon

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