Re: comments on draft-tan-epp-launchphase-09

Alexander,

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

I did notice a compatibility issue of draft-tan-epp-launchphase-09 with
draft-lozano-tmch-func-spec-05, where the noticeIDType in
draft-tan-epp-launchphase-09 being of XSD type base64Binary would not work
with the idType in draft-lozano-tmch-func-spec-05 being of XSD type token.
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.

Thanks,


-- 
 
JG
 

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





On 4/22/13 4:45 PM, "Alexander Mayrhofer" <[email protected]>
wrote:

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

Fixed

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

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


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

Fixed.


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

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

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

Fixed

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

Fixed

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

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

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

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

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


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

This just comes down to being explicit and consistent for both
registrations and applications.  I agree that an applicationID MAY and
really SHOULD be unique across all phases; although I don't believe we can
make unique applicationID's across all phases a MUST at this point.

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

Yes, I believe that the Security Considerations section covers it.

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

Good point, a fourth form "Mixed Create Form" will be created in its own
section.

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

Fixed, this was a hold over when there were the separate claims1 and
claims2 phases.

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

Fixed

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

>
>tia,
>
>Alex Mayrhofer
>nic.at
>
>_______________________________________________
>provreg mailing list
>[email protected]
>https://www.ietf.org/mailman/listinfo/provreg

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