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

James and all,

Should different, custom, types of "other phases" be described in the draft? or it is "custom" a sufficient placeholder here?

In general, most community and most geo will have at least one (top) priority phase beyond "trademark sunise" (for instance: "public administrations with competences over the geographic territory", as defined, or other). Most of our geo-TLDs will have two launch phases beyond trademarks (one with priority over TMs, the other below YMs). But as said, I am uncertain on whether providing definitions or at least, reference to different relative priority is necessary or not.

In amy case I'd suggest that the definition of "land rush" changes from "non-trademark holders are allowed.." to a more generic "non-priority applications…." On one hand, it is better to refer to applications than to applicants or holders as the qualification for the phase is based in the applicant's nature, but the concrete right. And second, land rush will come, in  many cases, not just after TMs, but other rights with priority on the given TLD.

Amadeu

El 26/02/2013, a les 16:30, "Gould, James" <[email protected]> va escriure:

> 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]]
>> Sent: Tuesday, February 26, 2013 9:38 AM
>> To: Gould, James
>> Cc: EPP Provreg ([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:
>>> 
>>> 	• 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.
>>> 	• Split the <launch:timestamp> into <launch:generatedDate> and <launch:acceptedDate> based on feedback from Trung Tran.
>>> 	• 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.
>>> 	• 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]
>>> https://www.ietf.org/mailman/listinfo/provreg
> 
> 

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