Re: [tmch-tech] FW: Launch Phase EPP Extension Version 06

Rubens,

Technically draft-tan-epp-launchphase can be used at any point.  Use of signedMark's and use of applications can be used in any of the phases defined in section 2.2 of the draft.  I'm not sure the use case that you are describing is a common one, but it can be supported.

Do you have a description for the proposed "restricted" phase?

Good feedback on the statuses.  We got a request from Trung Tran that is related, "Remove "pending" and "pendingAuction" in favor of "pendingValidation" and "pendingAllocation", that we wanted to discuss on the list.  Do you support Trung's request?

The name blocking sounds a lot like the Defensive Registration mapping implemented in DotName.  In .xxx could there be multiple overlapping blocks similar to the Defensive Registration extension?

Jim
________________________________
From: Rubens Kuhl [[email protected]]
Sent: Tuesday, February 26, 2013 10:09 AM
To: Gould, James
Cc: [email protected] ([email protected]); EPP Provreg ([email protected])
Subject: Re: [tmch-tech] FW: [provreg] Launch Phase EPP Extension Version 06

James,

I'm looking for something that does not assume applications are only used during launch phases. Although this could be viewed as semantics ("just keep the TLD in eternal launch"), this has implications.  This would require renaming methods such as launch:create to async:create.

This would imply in another phase status (section 2.2) called restricted, renaming Auction (states values 2.3.1) to Election (which could be auction or any process that chose between 2 or more applications), and to
dig somewhat further into land rush instead of just mentioning (landrush
The EPP <create> command with the "landrush" launch phase is undefined but the form supported is up to server policy.
)

On a topic that I don't recall seeing either at draft-tan or Chris Wright's, is the possibility of asking for name block instead of domain creation. This has occurred in .xxx sunrise and some registries could allow simultaneous askings in a single phase. This could be some kind of custom flag with parameters "registration", "block" and possible expansions to include new values.


Rubens





Em 26/02/2013, às 11:51:000, Gould, James escreveu:

Rubens,

The Launch Phase draft does support asynchronous operations with support for applications versus registrations.  Take a look at section 2.1 Application Identifiers in the draft that defines the Application Identifier and its use.  This can be used during any launch phase.  Are you looking for something different?

Jim

________________________________
From: Rubens Kuhl [[email protected]<mailto:[email protected]>]
Sent: Tuesday, February 26, 2013 9:38 AM
To: Gould, James
Cc: EPP Provreg ([email protected]<mailto:[email protected]>)
Subject: Re: [provreg] Launch Phase EPP Extension Version 06


James,

The main advantage I see in ARI's competing draft for this task is the suitability to registries that operates asynchronously during its normal operations. This happens with a lot of ccTLDs, and most community or restricted new gTLDs could also benefit.
Do you see a way to incorporate such mechanisms into your draft ? In this way we could have a general mechanism for domain registrations that cannot be completed based just of name availability: auctions, no-money bids (like who proposes the best use of a generic name on a TLD), registration restrictions that cannot be checked online (membership, taxpayer status) etc.

It could even have a new name like draft-tan-epp-asynchronous, but the two drafts model Chris Wright suggest could work better.


Rubens




Em 26/02/2013, às 11:30:000, Gould, James escreveu:

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


  1.  Removed the definition of the mark-1.0 and signedMark-1.0 and replaced with reference to draft-lozano-smd, that contains the definition for the mark, signed marked, and encoded signed mark.
  2.  Split the <launch:timestamp> into <launch:generatedDate> and <launch:acceptedDate> based on feedback from Trung Tran.
  3.  Added the "includeMark" optional attribute to the <launch:info> element to enable the client to request whether or not to include the mark in the info response.
  4.  Fixed state diagram to remove redundant transition from "invalid" to "rejected"; thanks Klaus Malorny.

Please reply with any feedback.

Thanks,

JG

James Gould
Verisign
<draft-tan-epp-launchphase.txt><draft-tan-epp-launchphase.html>_______________________________________________
provreg mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/provreg

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