Subject: Re: [provreg] comments on draft-tan-epp-launchphase-09

From: Alexander Mayrhofer <[email-masked]>
Date: Wed, 24 Apr 2013 10:17:03 +0000

> Thank you for the detailed review and feedback. I provide responses to your
> feedback below.

[Alexander Mayrhofer] 
Thanks - response inline where appropriate.
 
> This will get incorporated into draft-tan-epp-launchphase-10 along with your
> feedback.  All changes are checked into my github repository available at
> https://github.com/james-f-gould/EPP-Launch-Phase-Extension-
> Specification.g
> it.  Let us know if anything was missed or if any additional changes are
> needed.

[Alexander Mayrhofer] 
I will check out the diff - thanks for the pointer.

> >- Section 2.2: I think that 2004 is an inappropriate response code for
> >this case, since the value might not be "outside the range of values
> >specified by the protocol" - it actually *is* a valid value, just not
> >appropriate at that certain time. Therefore, i think that 2306 might be
> >more appropriate.
> 
> Yes, selecting the appropriate return code for this one was a challenge.
> This one could go either way, but I don't have an issue switching it to 2306.
> What do others think?

[Alexander Mayrhofer] 
What we found is that 2306/2308 gets used quite often, so we're sometimes 
not sure whether we use it *too often*. However, it seems most appropriate
for policy driven errors..

> >- Section 2.2: Is the server allowed to validate names of sub-phases? I
> >think some text like "Servers MAY validate the  sub-phase elements, and
> >respond with 2306 if a sub-phase is required that is not active" would
> >do good. I wouldn't make it required, though.
> > 
> How about "The server SHOULD validate the phase and MAY validate the
> sub-phase of the <launch:phase> element against the active phase and
> OPTIONAL sub-phase of the server on a create command, and return an EPP
> error result code of 2306 if there is a mismatch."?

[Alexander Mayrhofer] 
perfect.

> >- Section 2.3, last sentence ("If the domain:create command
> >processes...") - why is that sentence in this section? If required at
> >all, it would be more appropriate in Section 2.1. Also, remove the
> >"along with the application status" from this sentence?
> 
> The last sentence was moved un to section 2.1 and the "along with the
> application status" was removed.

[Alexander Mayrhofer] 
perfect.

> >- Section 2.3.1: The bottom horizontal line connecting
> >pendingAllocation, invalid, allocated and rejected confuses the hell
> >out of me - What is the directionality of that transition, and what are
> >the decisions where it connects to the other lines?
> 
> All of the transitions flow down, where an application in "pendingAllocation"
> could transition to either the "allocated" or the "rejected" status.  The same
> thing holds true to the "invalid" status.  An application in the "invalid" status
> could be fixed and transition to the "allocated" status or could transition to
> the "rejected" status.  Does this make sense?  Does anything else need to be
> added?

[Alexander Mayrhofer] 
Hmm... wouldn't an "invalid" application transition back to "pendingValidation" in order to get the application fixed, and subsequently transition "down straight"? The transition from pendingAllocation to rejected sounds logical to me, but the direct transition from invalid to allocated not so much. Anyway, since i wasn't involved in all discussions, i assume that there's a reason for this "shortcut" - and, i think we should be open about the possible transitions, rather than restricting it too much.

So, this reduces my comment on the representation of those transitions? Seperate lines to those two states (would create four lines, and they would cross in the middle :-/ ), or maybe just some clarifying text? 

> >- Section 3.1.1: The first two paragraphs both start with "The Claims
> >Check Form defines", and therefore those two definitions contradict
> >each other a bit. Maybe they could be merged into a single definition.
> 
> The paragraphs have been merged, with the last sentence of the first
> paragraph being added to the end of the second paragraph.

[Alexander Mayrhofer] 
perfect.

> >- Section 3.1.1: Why is returning normal availability information a
> >MUST NOT? I don't see a reason why i shouldn't return the availability
> >information together with the mark exists information. Can we change
> >that to "MAY be excluded"? I can understand that availability
> >information would be ambigious *if* the server would return also
> >information for future phases - but see my comment for 3.1.2 below..
> 
> This is because the command defines a new verb (Claims Check) and the
> response does not return <domain:chkData> under <resData>, but instead
> returns <launch:chkData> under <resData>.  In this case the Claims Check
> Response is not an extension of the Domain Check Response, so mixing the
> availability check and the claims check information is not possible.

[Alexander Mayrhofer] 
Ok, understood - thanks for the clarification.
 
> >- Section 3.1.1: Name of "Trademark exists" attribute: I find
> >"<launch:name exists=..> a bit misleading, because it could be
> >interpreted as "the name itself exists"... Rename it to "tmExists=.."
> >or "trademark=.."?
> 
> The "exists" attribute is generic but is relevant to the context that it is being
> used, which in this case is being used as part of a <launch:chkData> (Claims
> Check Response) that is defining whether a trademark exists.  I don't believe
> changing the attribute name will help much in this case considering the
> context of its use.  What do others think?

[Alexander Mayrhofer] 
Given the definition is clear enough for each context, i'm fine with keeping it that way.

> >- Section 3.1.2: Typo in second paragraph "extensed".. Also, related to
> >my point above, why is there an explicit "availability" check if there
> >is a "base" availability check already in the check command?
> 
> Fixed the "extensed".  The check command with the type="claims" is a new
> domain verb (Claims Check Command) that returns different information
> from the domain check command.  The check command with the
> type="avail" is a standard domain check extension, that defines the phase
> that the domain check (availability) is executed for.

[Alexander Mayrhofer] 
understood now, thanks...
 
> >- Section 3.1.2: I would like to see text like "Servers MAY reject
> >availability checks for launch phases that are not currently active"
> >(or even a SHOULD?), because i think it doesn't make much sense to
> >"look into the future"... Maybe there are use cases i haven't thought
> >of yet, though..? I understand that might be the reason to disallow the
> >server to return "unqualified" (without phase designation) availability
> information?
> 
> Support for doing an availability check for the non-active phase is really the
> purpose of the Availability Check Form that was requested by James
> Mitchell.  The text in the section 3.1 paragraph was meant to enable the
> server to define the forms that it supports based on server policy.  The
> server MAY support either form, but I would anticipate that all will support
> the Claims Check Form and a few will support the Availability Check Form.
> I'm not sure if adding more guidance text will help.  What do others think
> about this?

[Alexander Mayrhofer] 
I'm concerned that availability information for future phases might depend on outcome of phases that precede that current phase, specifically allocations. It's a bit of a "back to the future" problem to indicate whether a domain name will be available in a future phase, since the inventory of the allocations during that future phase is yet unknown...?

for example, an availability check for the "open" phase would need to understand the set of domains allocated in the "sunrise" phase... which is obviously not possible. 

So, the command could only "estimate" the availability of a domain name during a future phase, based on the current inventory of the registry. So, it actually returns "availability of a name *if the specified phase would be active right now*" - which is only an indication...

The section 3.1 text looks fine to me, though.
 
[...]

> >- Section 8. Rather then returning 2303 (which is just plain "lying" in
> >case the object exists), 2201 would be a better choice. I think we can
> >still return 2201 not matter whether the application exists or not -
> >2308 would be another option.
> 
> I agree that 2201 should cover the case of an unauthorized client attempting
> to operate on an application object.  If the application does not exist then
> 2303 is appropriate, but I'm not sure if we need to even state this.

[Alexander Mayrhofer] 
I understand that exposing whether or not an application exists might be undesired, so we could allow for both response codes? Unauthorized could be returned, no matter whether or not an application exists...

Alex

---

From: "Gould, James" <[email-masked]>
Date: Wed, 24 Apr 2013 12:21:00 +0000

Alexander,

My feedback is below.

-- 
 
JG

James Gould
Principal Software Engineer
[email-masked]
 
703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com

>for policy driven errors..

I had the same concern with the overuse of the 2306 return code, but I
agree it's applicable here.

>Hmm... wouldn't an "invalid" application transition back to
>"pendingValidation" in order to get the application fixed, and
>subsequently transition "down straight"? The transition from
>pendingAllocation to rejected sounds logical to me, but the direct
>transition from invalid to allocated not so much. Anyway, since i wasn't
>involved in all discussions, i assume that there's a reason for this
>"shortcut" - and, i think we should be open about the possible
>transitions, rather than restricting it too much.
>
>So, this reduces my comment on the representation of those transitions?
>Seperate lines to those two states (would create four lines, and they
>would cross in the middle :-/ ), or maybe just some clarifying text?

I'll work with Gavin and Wil on this feedback and see what we can do to
clarify things.  

>I'm concerned that availability information for future phases might
>depend on outcome of phases that precede that current phase, specifically
>allocations. It's a bit of a "back to the future" problem to indicate
>whether a domain name will be available in a future phase, since the
>inventory of the allocations during that future phase is yet unknown...?
>
>for example, an availability check for the "open" phase would need to
>understand the set of domains allocated in the "sunrise" phase... which
>is obviously not possible.
>
>So, the command could only "estimate" the availability of a domain name
>during a future phase, based on the current inventory of the registry.
>So, it actually returns "availability of a name *if the specified phase
>would be active right now*" - which is only an indication...

The use case described by James Mitchell on the list was a special
release, using a custom phase like <launch:phase name="idn-release">, of
IDN domain names that would not be available in previous phases and
clients could use the availability check form to determine what domain
names will be available.  It might help if James Mitchell helped to
describe other use cases for this optional feature.

>I understand that exposing whether or not an application exists might be
>undesired, so we could allow for both response codes? Unauthorized could
>be returned, no matter whether or not an application exists...

There is no definition of an unauthorized client for a non-existing
application, so I'm not sure whether we would want to return 2201 instead
of 2303 for that case.  Is the existence or non-existence of an
application, which would be easy to identify using the 2303 and 2201
return codes, a concern from a security perspective.  I'm just not sure
whether a security concern would override accurately representing the
error via the 2303 return code for a non-existing application.  What do
others think about this?

---

From: Seth Goldman <[email-masked]>
Date: Wed, 24 Apr 2013 09:45:17 -0400

> error via the 2303 return code for a non-existing application.  What do
I think it's a non-issue. Exposing the existence of a particular
application id does not have any security implications AFAICT.  A
non-sponsoring registrar can't do anything with that application id, so the
information is neither useful nor sensitive.

---

From: Wil Tan <[email-masked]>
Date: Thu, 25 Apr 2013 23:30:58 +1000

Hi Alex,

On Wed, Apr 24, 2013 at 8:17 PM, Alexander Mayrhofer <
[email-masked]> wrote:

> "pendingValidation" in order to get the application fixed, and subsequently
> transition "down straight"? The transition from pendingAllocation to
> rejected sounds logical to me, but the direct transition from invalid to
> allocated not so much. Anyway, since i wasn't involved in all discussions,
> i assume that there's a reason for this "shortcut" - and, i think we should
> be open about the possible transitions, rather than restricting it too much.
>
> Seperate lines to those two states (would create four lines, and they would
> cross in the middle :-/ ), or maybe just some clarifying text?
>
>
I agree that the overlapping lines in the diagram is confusing, so I've
split them:

https://github.com/wil/EPP-Launch-Phase-Extension-Specification/blob/master/draft-tan-epp-launchphase.txt#L396

Is it better?

I believe the "invalid" => "pendingAllocation" transition is meant to
address a fairly common use case in "traditional" (non-TMCH) sunrises where
the trademark validation agent or the registry would edit minor typos
directly after checking with the registrant.

You're right that it's conceivable that a registry might allow registrant
to modify the application object after it failed validation, moving it to
"pendingValidation" status again. However, I don't know how common this use
case is. Thoughts?

.wil

---

From: Alexander Mayrhofer <[email-masked]>
Date: Fri, 26 Apr 2013 08:57:45 +0000

Wil,

thanks for fixing the transitions – this makes it much clearer. Regarding your question, i think that the most logical approach would be that a modified „invalid“ application transitions back to „pendingValidation“, since my assumption is that a registry would review those changes in the same manner as it did for the original application. However, this is currently not possible in the flow chart, and i htink that is definitely a problem. Therefore:

In its „purest“ form, the transition from „invalid“ to „pendingAllocation“ should be replaced by a transition from „invalid“ to „pendingValidation“. I understand that in practice Registries will have „shortcuts“ that transition directly from one status to another, and i actually think even with the change i just described (no line from „invalid“ to „pendingAllocation“), it would be possible to create the direct transition in the following way, because:

-          We already have text in the draft that says „Additionally, certain statuses MAY be skipped“.

-          which allows us to create „virtual“ transitions between any phases that are „connected“

Eg. the „pure“ flow for the use case you just described would be:

-          invalid -> pendingValidation -> validated -> pendingAllocation

With skipping certain statuses, this can looke as follows:

-          invalid -> (SKIP pendingValidation) -> (SKIP validated) -> pendingAllocation

Which would exactly create your desired transition. However, in your proposal, it would actually be *impossible* to transition back from „invalid“ to „pendingValidation“ – which might be a very common use case in case of corrections to the applications.

So, i suggest replacing the transitions as outlined above, and maybe add some text  below the diagram that other transitions can be implemented by skipping steps. (such as („Note that other transitions can be achieved by skipping intermediate steps. For example, a transition from „invalid“ to „pendingAllocation“ can be achieved by ....“ (see above))..

comments?

Alex

(and sorry for the crappy quoting.. or, rather, not quoting at all)

Von: Wil Tan [mailto:[email-masked]]
Gesendet: Donnerstag, 25. April 2013 15:31
An: Alexander Mayrhofer
Cc: Gould, James; [email-masked]; [email-masked]
Betreff: Re: [provreg] comments on draft-tan-epp-launchphase-09

Hi Alex,

[Alexander Mayrhofer]

I agree that the overlapping lines in the diagram is confusing, so I've split them:

Is it better?

I believe the "invalid" => "pendingAllocation" transition is meant to address a fairly common use case in "traditional" (non-TMCH) sunrises where the trademark validation agent or the registry would edit minor typos directly after checking with the registrant.

You're right that it's conceivable that a registry might allow registrant to modify the application object after it failed validation, moving it to "pendingValidation" status again. However, I don't know how common this use case is. Thoughts?

.wil

---

From: Wil Tan <[email-masked]>
Date: Mon, 29 Apr 2013 18:45:16 +1000

Hi Alex,

On Fri, Apr 26, 2013 at 6:57 PM, Alexander Mayrhofer <
[email-masked]> wrote:

>  So, i suggest replacing the transitions as outlined above, and maybe add
> some text  below the diagram that other transitions can be implemented by
> skipping steps. (such as („Note that other transitions can be achieved by
> skipping intermediate steps. For example, a transition from „invalid“ to
> „pendingAllocation“ can be achieved by ....“ (see above))..
>

I have redrawn the diagram so that "invalid" transitions to
"pendingValidation" per your suggestion. Yes, it makes a lot of sense.

I've also added the following sentence in Section 2.3:

> Server policies permitting, it may transition back into
"pendingValidation" for revalidation,
> after modifications are made to ostensibly correct attributes that caused
the validation failure.

Since there's already language in 2.3 about the possibility of skipping
statuses, I believe that should suffice.

You can review the changes here:
https://github.com/wil/EPP-Launch-Phase-Extension-Specification

.wil