comments on draft-tan-epp-launchphase-09

Hi,

i've done a more thorough review of the current version of the launchphase documents. Generally, i think the draft is pretty mature, and that the document could proceed to publication, i haven't found any *really* major issues that would prevent implementation - thanks for the great work so far. 

The few issues that i found are listed below (disclaimer: Some of them might have been discussed in past conf calls or mailing list discussions that i have missed - if that is the case, please disregard them). I also haven't looked at the schema definition itself, but i assume that would be done during a final NITS review.

Here we go:

- Introduction: The last paragraph says "extension to the domain name extension" - i suppose that should read "extension to the domain name mapping".

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

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

- Section 2.3, description of "allocated" and "rejected": Swap the two sentences in each description - first describe what it is, and then describe that it's one of the two possible states.

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

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

- Section 2.6 / 2.7: Document structure: I think those would be more appropriate as sub-sections of 2.5 (e.g. 2.5.2 and 2.5.3), since both are "Mark Validation Models" (Title of 2.5), and 2.5 only contains one sub-section.

- Section 3, last paragraph before 3.1: I would like to see an RFC2119-style MAY at "Registries MAY choose"..

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

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

- 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=.."?

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

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

- Section 3.2: Why not make both "launch:phase" and "launch:applicationID" optional, and require that at least one of them has to be provided? I don't see the value of requiring the launch phase identifier if an applicationID is given -  unless someone plans to re-use application identifiers across applications of multiple phases (which i doubt someone would?) 

- Section 3.2: It could be useful to include text,  that the server MAY refuse to respond to info commands issues by a client that didn't create the application? There might be security / privacy issues with exposing applications of a different client, particularly the mark information (Addendum: I can see some text is contained in the Security Considerations section - so that is probably enough).

- Section 3.3: I think the text & example of a "mixed" create command deserves its own section at the end of 3.3. ("3.5. Mixed Create Form"). It would appear more logical to me to explain the "mixed" variant after the "basic" ones have been explained.

- Section 3.3.2: Description of "launch:acceptedDate": I think it's imprecise to allow that field to contain when the notice was "displayed or accepted", since those are different things. Let's keep it with the "accepted" data, since i might very well "display" the notice without the registrant "accepting" it (which might not be intended).

- Section 3.3.4: "applications of a given domain name are supported" instead of "is supported"?

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

tia,

Alex Mayrhofer
nic.at

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