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

[Alexander Mayrhofer <[e-mail]>]

> 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