Den 06. des. 2017 20:18, skrev Gould, James:
> Harald,
>
> Thank you for your review and feedback, below are my answers to your feedback.
>
Thanks for the quick response!
Deleting all below where you said "yes, we'll do that" and where I have
no further comment.
> 2.4
>
> This sentence: "if a launch status is supported and the launch status
> is not one of the final statuses, including the "allocated" and
> "rejected" statuses." makes equal grammatical sense if "allocated" and
> "rejected" are final statuses or non-final statuses. Could be clearer.
>
> Would the use of parenthesis work better as in the sentence below?
> “if a launch status is supported and the launch status is not one of the
> final statuses ("allocated" and "rejected").”
This is much more readable, thank you.
> It is not clear what causes the transition from "validated" to
> "pendingAllocation". It is also not clear if a transition possibility
> exists straight from "validated" to "allocated" for the case where no
> external process is needed.
>
> The transitions between the statuses is up to the server policy. There is no
> pre-defined timeframe that a domain must remain in a status. In general, the
> processing is done asynchronously and based on a batch schedule, where a
> batch may validate thus putting the domains in the “validated” status. A
> separate batch may prepare the domains for the allocation process thus
> putting the domains in the “pendingAllocation” status. Finally, a batch will
> allocate the domains thus putting the domains in either the “allocated” or
> the “rejected” status.
>
> Yes, there can be a server policy that supports moving domains to the
> “validated” or “invalid” status in one step and then deciding on the
> allocation in a separate step synchronously. In this case, there is no need
> for the “pendingAllocation” status.
>
> One scenario is that a pendingValidation domain may skip the validated status
> and transition immediately to the pendingAllocation status, or
In that case, it would be clearer if the drawing was preceded by a
sentence saying: "The transitions between states is a matter of server
policy. One possible set of permitted transitions is given in the
diagram below".
This will make it clear to people that this isn't a total map of
possible transitions.
>
> 2.5
>
> "A Launch Application MUST and a Launch Registration MAY" would be
> clearer if there were commas around "and a Launch Registration MAY".
>
> How about trying to fix the sentence overall, with the following two
> sentences?
>
> “A Launch Application MUST be handled as an EPP domain name object, as
> specified in RFC 5731 [RFC5731], with the "pendingCreate" status and with the
> launch status values defined in Section 2.4. A Launch Registration MAY be
> handled as an EPP domain name object, as specified in RFC 5731 [RFC5731],
> with the "pendingCreate" status and with the launch status values defined in
> Section 2.4.”
>
This looks good to me.
> 2.6.3
>
> This section's sentence structure is unclear due to a missing comma
> before "or the <smd:encodedSignedMark>".
>
> I believe the fix here is to remove “either” and the comma from the sentence
> as in:
>
> “Digital signatures MAY be used by the server to validate the mark
> information when using the "signed mark" validation model with the
> <smd:signedMark> (Section 2.6.3.1) element or the <smd:encodedSignedMark>
> (Section 2.6.3.2) element.”
>
> Do you agree that this is better?
I'm still a bit confused about where the beginning of the sentence is
that ends with "or". Is it obvious to everyone that the "signed mark"
validation model is used both with <smd:signedMark> and with
<smd:encodedSignedMark>? It's possible to read this as there being two
validation models, one that is called "signed mark and uses
<smd:signedMark>, and another one that's not named, but uses
<smd:encodedSignedMark>.
>
> 3.1
>
> It is completely unclear what functional difference there is between
> the "Claims Check Form" (3.1.1) and the "Trademark Check Form"
> (3.1.3). I suspect the idea behind "whether or not there are any
> matching trademarks, in the specified launch phase, for each domain
> name passed in the command, that requires the use of the "Claims
> Create Form" on a Domain Create Command." (3.1.1) versus "whether or
> not there are any matching trademarks for each domain name passed in
> the command, independent of the active launch phase of the server and
> whether the "Claims Create Form" is required on a Domain Create
> Command." (3.1.3) is that the latter will return claims info in cases
> where the former would not, but it's not clear when this makes a
> difference to the caller - the same reply info seems to be returned in
> both cases.
>
> Another interpretation is that there exist trademarks that match in a
> given phase and do not match outside that phase, so that the "claims
> check form" may return matches that "trademark check form" would not -
> this seems a bit bizarre.
>
> The Trademark Check Form was explicitly requested on the list to support
> checking for the existence of trademarks independent of the active or
> specified phase and without requiring an indication that a claims notice is
> required on a domain create. The primary purpose of a check is to indicate
> to the client whether a create will work, which is the goal of the Claims
> Check Form. Depending on the phase, the Claims Check Form may not return the
> claims information because the create does not require it. However, the
> Trademark Check Form will always return the claims information if there is at
> least one trademark associated with the domain name. This is a subtle
> difference, but an important difference since some systems require providing
> the raw trademark information without including the extra phase-specific
> logic of the Claims Check Form.
>
>
This makes perfect sense (if I interpret it correctly), and was the most
reasonable interpretation I had.
Would it make sense to add a sentence saying "The Trademark Check Form
will always return at least the marks returned by a similiar Claims
Check Form, but may return additional marks"?
Happy that the review was useful!
Harald
_______________________________________________
regext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/regext
