Subject: [provreg] Launch Phase EPP Extension Version 06

From: "Gould, James" <[email-masked]>
Date: Tue, 26 Feb 2013 14:30:27 +0000

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

---

From: Rubens Kuhl <[email-masked]>
Date: Tue, 26 Feb 2013 11:38:40 -0300

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:

> 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.
> <draft-tan-epp-launchphase.txt><draft-tan-epp-launchphase.html>_______________________________________________
> provreg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/provreg

---

From: "Gould, James" <[email-masked]>
Date: Tue, 26 Feb 2013 14:43:06 +0000

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-masked]]
Sent: Tuesday, February 26, 2013 9:38 AM
To: Gould, James
Cc: EPP Provreg ([email-masked])
Subject: Re: [provreg] Launch Phase EPP Extension Version 06

James,

Rubens

Thanks,

JG

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

---

From: Michael Young <[email-masked]>
Date: Tue, 26 Feb 2013 09:51:40 -0500

I want to second Rubens suggestion to avoid competing drafts - we have enough largely unnecessary divergence in overlapping extensions with existing TLDs. This is an opportunity to avoid further disparity. 

Michael Young

M:647-289-1220

On 2013-02-26, at 9:38, Rubens Kuhl <[email-masked]> wrote:

> _______________________________________________
> provreg mailing list
> [email-masked]

---

From: Michael Young <[email-masked]>
Date: Tue, 26 Feb 2013 09:55:22 -0500

Rubens it sounds like you are referring to the concept of a pending create in General Availability?

Michael Young

M:647-289-1220

---

From: "Gould, James" <[email-masked]>
Date: Tue, 26 Feb 2013 15:04:09 +0000

Both draft-tan-epp-launchphase and draft-rbp-application-epp-mapping support applications in the same way, where draft-rbp-application-epp-mapping splits it out into a separate draft and draft-tan-epp-launchphase makes it an option similar to the support for synchronous or asynchronous operations in RFC 5731.  A launch application in my view is a domain in pendingCreate status, where there can be more then one application at a time for the same domain name.

Jim

________________________________
From: Michael Young [[email-masked]]
Sent: Tuesday, February 26, 2013 9:55 AM
To: Gould, James
Cc: Rubens Kuhl; EPP Provreg ([email-masked])
Subject: Re: [provreg] Launch Phase EPP Extension Version 06

Michael Young

M:647-289-1220

On 2013-02-26, at 9:43, "Gould, James" <[email-masked]<mailto:[email-masked]>> wrote:

Rubens,

Jim

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

James,

Rubens

Thanks,

JG

James Gould
Verisign

---

From: Rubens Kuhl <[email-masked]>
Date: Tue, 26 Feb 2013 12:09:02 -0300

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

---

From: Gavin Brown <[email-masked]>
Date: Tue, 26 Feb 2013 15:09:12 +0000

> I want to second Rubens suggestion to avoid competing drafts - we have
> enough largely unnecessary divergence in overlapping extensions with
> existing TLDs. This is an opportunity to avoid further disparity. 

This is probably going to happen anyway (I can hear various registrars
groaning in pain: I feel your pain!). Various registries have different
extensions baked into their gTLD applications. They can't be changed
without cost, risk, or delay.

Wil and I (and later Jim) have been advocating development of a single
EPP extension for registry launches since 2011 or earlier: some of you
may recall a meeting we organised at the 2011 ICANN meeting in San
Francisco. We had some interest but obviously not enough to gain any
momentum, which is unfortunate.

Given that there will probably now inevitably be fragmentation, the most
important issue to re-use as much as possible between competing
extensions. That's why we now have an extension-agnostic draft to
describe signed mark data. This won't take away the pain, but it might
help sooth it a little.

G.

-- 
Gavin Brown
Chief Technology Officer
CentralNic Ltd
Innovative, Reliable and Flexible Registry Services
for ccTLD, gTLD and private domain name registries
https://www.centralnic.com/

CentralNic Ltd is a company registered in England and Wales with company
number 4985780. Registered Offices: 35-39 Moorgate, London, EC2R 6AR.

---

From: Michael Young <[email-masked]>
Date: Tue, 26 Feb 2013 10:24:35 -0500

I can't disagree about the current state you've described, and the effort you and others are putting into this draft is really appreciated. Sure there is going to be divergence but we should always attempt standardization where there is common requirements - it's never an easy or 100% successful effort but its better than where we started :-)

Michael Young

M:647-289-1220

---

From: "Gould, James" <[email-masked]>
Date: Tue, 26 Feb 2013 15:30:40 +0000

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-masked]]
Sent: Tuesday, February 26, 2013 10:09 AM
To: Gould, James
Cc: [email-masked] ([email-masked]); EPP Provreg ([email-masked])
Subject: Re: [tmch-tech] FW: [provreg] Launch Phase EPP Extension Version 06

James,

Rubens

Rubens,

Jim

James,

Rubens

Thanks,

JG

James Gould
Verisign

---

From: Wil Tan <[email-masked]>
Date: Wed, 27 Feb 2013 03:06:59 +1100

Rubens,

Thanks for your feedback.

 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.
>
>
The primary use case supported by our draft is indeed that of launch phases
-- be it initial launch (pilot, sunrise, land rush, etc.) or later
restricted releases such as "newly available IDN language" or "2-character
release". We didn't rule out perpetual async operation though. In fact, the
special case of phase="open" was envisioned for steady-state operation. The
common method for async processing that I know of goes like this:

    The registry requires additional data to be submitted. Once submitted,
the domain is placed in pendingCreate until it is (perhaps manually)
validated. Multiple applications for the same domain is usually not
supported.

In this case, the launch phase extension can be used primarily for
transporting trademark data.

Do you have a different model in mind?

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

A "restricted" phase does sound like a useful value to add.

Election could work quite well since it's more generic. We could go one
step further and just use "processing" to indicate that something is
happening (i.e. replace "pendingAuction" with "processing" in Section
2.3.1).

> The EPP <create> command with the "landrush" launch phase is undefined but
> the form supported is up to server policy.
> )
>
>
Do you mean we should specify further, or provide more textual description
to guide implementers?

> 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.
>
>
This is probably best handled with a separate extension, which can be mixed
in with either our draft or ARI's. That said, if the community feels that
there is value in having it defined in one place, we're open to adding it.

.wil

---

From: Rubens Kuhl <[email-masked]>
Date: Tue, 26 Feb 2013 14:29:15 -0300

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

> Rubens,
> 
> Technically draft-tan-epp-launchphase can be used at any point.  

Technically, yes. But there are contract implications of following or not agreed practices and standards, and there are market implications like having registrars support or not parameters. 

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

Reading new gTLD apps showed to me a few business models that won't fit strict-first-come-first-serve-if-no-such-name-exists-create. 

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

It's seems Wil Tan would call it "open" instead, but the phase would be the steady state of the registry that doesn't provide synchronous registrations, so application would make more sense than create. 

> 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 d…

Yes, Validation and Allocation are good words to use. 

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

I don't know the specifics of .xxx, but there is at least one registry I know of where there will be multiple overlapping blocks. That could be implemented by a possible response to "block check" like "registry doesn't support verifying pre-existences of block requests".  

Rubens

---

From: Rubens Kuhl <[email-masked]>
Date: Tue, 26 Feb 2013 14:32:48 -0300

> Do you mean we should specify further, or provide more textual description to guide implementers?

Both. I'm currently busy but as soon as I can I will steal... borrow... the text from ARI's draft. 

> This is probably best handled with a separate extension, which can be mixed in with either our draft or ARI's. That said, if the community feels that there is value in having it defined in one place, we're open to adding it.
> 

I think the value is having it defined. It can be one draft or more than one non-competing drafts, like draft-lozano-smd and draft-tan-launchphase already are. 

Rubens

---

From: "Gould, James" <[email-masked]>
Date: Tue, 26 Feb 2013 17:41:30 +0000

Rubins,

My feedback is below prefixed with "JG-".

Jim

Sent: Tuesday, February 26, 2013 12:29 PM

Rubens,

JG- I'm not sure if I understand this.  Can you describe a use case where the draft-tan-epp-launchphase cannot be used?

JG - The draft-tan-epp-launchphase supports both FCFS, which is referred to as registrations, as well as asynchronous applications.  Is there an issue that you believe the draft-tan-epp-launch can not handle as defined?

JG - Are you talking about a registry that uses a pendingCreate of RFC 5731?  There is no need to a new extension for registries that support the pendingCreate, since it is already fully supported by RFC 5731. The use of an application in combination with pendingCreate is only needed if there can be overlapping registrations, which again is supported by draft-tan-epp-launchphase.

JG - It's sounds like use of the pendingValidation and pendingAllocation statuses work for you.

JG - Blocks or Defensive Registrations sound like new objects that would use an EPP extension in place of an extension to domain.  The Defensive Registration Mapping for DotName is available at the URL http://www.verisigninc.com/assets/defensive-registration-mapping.pdf.  The Defensive Registration Mapping went meant to support blocks and there could be multiple overlapping defensive registrations for the same domain strings.

Rubens

---

From: Amadeu Abril i Abril <[email-masked]>
Date: Tue, 26 Feb 2013 18:02:17 +0100

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-masked]> va escriure:

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

---

From: Rubens Kuhl <[email-masked]>
Date: Tue, 26 Feb 2013 15:00:28 -0300

Em 26/02/2013, às 14:41:000, 
> JG- I'm not sure if I understand this.  Can you describe a use case where the draft-tan-epp-launchphase cannot be used?  

James, use cases are part of technical side of this question. There are no use cases that I mentioned that wouldn't fit. 
The analogy I make is with yes/no cards to the color-blinded. One could write "green" or "red" in the cards so color-blinded know what card to use (that's what I see happening here), or they could have "yes" and "no" written. 

> JG - The draft-tan-epp-launchphase supports both FCFS, which is referred to as registrations, as well as asynchronous applications.  Is there an issue that you believe the draft-tan-epp-launch can…

No. 

> JG - Are you talking about a registry that uses a pendingCreate of RFC 5731?  There is no need to a new extension for registries that support the pendingCreate, since it is already fully supported…

No, I'm not. I'm talking about overlapping registrations during day to day operations of a registry. 
> JG - Blocks or Defensive Registrations sound like new objects that would use an EPP extension in place of an extension to domain.  The Defensive Registration Mapping for DotName is available at the…

Agreed. I'll read it and let the group know. 

Rubens

---

From: "Gould, James" <[email-masked]>
Date: Tue, 26 Feb 2013 19:16:45 +0000

Rubens,

My reply is below prefixed with "JG2-".

Jim

Sent: Tuesday, February 26, 2013 1:00 PM

JG2 - I'm still trying to understand what you're saying in relation to the draft-tan-epp-launchphase draft.  We have tried to make it as specific as possible but also to be flexible to support a variety of launches.  Where you get into trouble is if you are too specific or too flexible.  If you have any proposals for text changes to clarify things or more formal XML schema changes, please let us know.
Reading new gTLD apps showed to me a few business models that won't fit strict-first-come-first-serve-if-no-such-name-exists-create.

No.

JG2 - So you saying the use of applications during the "open" phase, correct?  If so, the draft-tan-epp-launchphase can be used.  If you're talking about a new object type like Blocks or Defensive Registrations, I believe it is best met with a new object mapping.

Rubens

---

From: Klaus Malorny <[email-masked]>
Date: Wed, 27 Feb 2013 12:12:07 +0100

On 26/02/13 15:30, Gould, James wrote:
> 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:
>
>  [...]
>

Hi James,
I just browsed through the schema and asked myself what the rationale could be 
to be able to submit multiple marks with one request. What is the processing 
expectation? Also, while I can submit multiple, I cannot mix, for example, 
codes, unsigned and signed marks.

Another point is the <codeMark> element. As the SMD draft was allegedly 
developed with Verisign's input, why was the <code> element not integrated into 
the <mark:mark> element of the draft? It violates a bit the principle of the 
separation of concerns.

Regards,

Klaus

---

From: "Gould, James" <[email-masked]>
Date: Wed, 27 Feb 2013 13:15:51 +0000

Klaus,

Let me first address your question about mixing validation models.  In section 2.4 "Mark Validation Models", "a server MUST support one of four models for validating the trademark information", which include "code", "mark", "code with mark" and "signed mark".  These are higher level models for the validation of the mark information by the server.  The mixing of validation models will add a great deal of complexity for the clients.  In the case of the gTLD's and the TMCH, the "signed mark" is the model that must be supported.  The other models could be selected for use by ccTLD's or for other custom launches.  

A second question was related to the rationale of submitting multiple marks (or signed marks) with one request.  There might be multiple marks that are applicable for the domain name that can be taken into consideration by the server.  There can be multiple allocation policies used by the servers, so having multiple valid marks for an application can be taken into account based on server policy.  The expected behavior is that the server would validate all passed marks for the domain name.

The last question was related to the reason why the <launch:code> was not integrated into the <mark:mark> element.  I want to point out that SMD draft used the definition of the mark, signed mark, and encoded signed mark as the starting point in cooperation of the three co-authors of the Launch Phase draft (me, Gavin Brown, and Wil Tan).  The separation of concerns was first done in the 04 draft by the creation of the separate launch-1.0, signedMark-1.0, and mark-1.0 XML schemas.  The <launch:code> fell into the launch-1.0 XML schema since it is not an attribute of the mark but is an external element that is used to support some of the higher level validation models ("code" and "code with mark").  The signedMark-1.0 and mark-1.0 XML schemas were moved out into the SMD draft and updated to integrate with the data model of the TMCH.           

Let me know if you have any additional questions or proposals to make things more clear in draft-tan-epp-launchphase.

Thanks,

Jim
 
________________________________________
From: [email-masked] [[email-masked]] on behalf of Klaus Malorny [[email-masked]]
Sent: Wednesday, February 27, 2013 6:12 AM
To: [email-masked]
Subject: Re: [provreg] Launch Phase EPP Extension Version 06

Hi James,

Regards,

Klaus