Adam,
Thank you for the review and feedback. I provide a response to your feedback
embedded below with a “JG – “ prefix. I can post
draft-ietf-regext-launchphase-06 once there is agreement to the set of changes.
Thanks,
—
JG
James Gould
Distinguished Engineer
jgo...@verisign.com
703-948-3271
12061 Bluemont Way
Reston, VA 20190
Verisign.com <http://verisigninc.com/>
On 7/25/17, 11:18 PM, "Adam Roach" <a...@nostrum.com> wrote:
EPP Launchphase Authors --
This is my AD review of draft-ietf-regext-launchphase-05.
I have a number of questions and comments about the draft, although I
freely admit that many of them may stem from a lack of knowledge on my
part about the operational models in which EPP is deployed. Please bear
with me on those points. Comments are in document order, and constitute
a mix of substantive and minor editorial comments.
As a general comment, I believe the document could benefit from either
some introductory text about how claims operate or a pointer to a
document that explains how they operate. I skimmed the documents cited
in the references section and couldn't easily locate information along
these lines.
JG – Section 2.3.1 “Trademark Claims Phase” was added in
draft-ietf-regext-launchphase-02 to remove the reference to
draft-ietf-regext-tmch-func-spec and briefly describe the trademark claims
phase. Please indicate any information from draft-ietf-regext-tmch-func-spec
that would help provide clarity without having to add the reference back to
draft-ietf-regext-tmch-func-spec.
The introduction talks about "registrations" and "applications" without
defining what these terms mean or citing a definition. As far as I can
tell, EPP does not define these terms, and I'm having a hard time
figuring out the difference. It's probably worth adding a few words in
section 1.1 that talks about these terms (and, in particular, indicates
that "application" in this context is very different from how that term
is generally used in computer science).
JG-An attempt was made to differentiate a Launch Application from a Launch Registration in the Introduction with “…registries often accept multiple application for the same domain name during the “Sunrise” launch phase, referred to as a Launch Application. A Launch Registration refers to a registration made during a launch phase when the server uses a first-come, first-served model”. A more formal definition can be added to section 1.1 for a Launch Application and a Launch Registration to clarify it further. How about the following definitions?
“A Launch Registration is a domain name registration during a launch phase when the
server uses a "first-come, first-served" model. Only a single registration for
a domain name can exist in the server at a time.”
“A Launch Application represents the intent to register a domain name
during a launch phase when the server accepts multiple applications for a
domain name and the server later selects one of the applications to allocate as
a registration. Many Launch Applications for a domain can exist in the server
at a time.”
Section 2.2 indicates that the Validator Identifier and Issuer
Identifier must be unique; however, it's not clear how this uniqueness
is enforced. Is there a registry somewhere? Are these derived from some
previously allocated identifiers? Are UUIDs expected? Or is it expected
that the community simply self-organizes to achieve this somehow? I
think this document needs to clearly state how this uniqueness is
expected to happen.
JG-The uniqueness of the “validatorID” is associated within a specific server
(registry), so it is enforced by the servers (registries) that accept them.
For example, if a registry supports the default “tmch” Validator Identifier, it
could define the requirement for another validator to be used, where the
registry would enforce that the validator identifier of the additional
validator is unique. The server policy would define the accepted set of
validators and their associated validator identifiers. I added some additional
language to section 2.2 like “The Validator Identifier is the identifier, that
is unique to the server, for …” and “The unique set of Validator Identifier
values supported by the server is up to server policy”. Do you agree with this
update?
The sequence diagram in Figure 1 has an unlabeled response (to the left
of "Does Domain have Claims?") -- this should indicate what kind of
information is being conveyed to the client.
JG-With both the “No” and “Yes” branch from the “Does Domain have Claims?”
decision node, the Domain Claims Check Response is returned. The Domain Claims
Check Response will include a Boolean value of indicating whether claims
(trademarks) exist and a claims key if a claims (trademarks) do exist. Maybe
to clarify this, the label for the “No” branch can be set to “Claims Don’t
Exist” and the “Yes” branch label can be changed from “Claims Key” to “Claims
Exist with Claims Keys”. Do you believe that is better?
The <launch:applicationID> and <launch:status> elements on page 13 are
indented further than one would normally expect. The same goes for the
<launch:status> element on page 14.
JG-Done
The final paragraph of section 2.6 indicates that multiple instances of
certain elements MAY be supported by a server, without indicating how
such support might be indicated or negotiated. Minimally, I'd expect to
see a unique status code here that allows the client to determine that
the server does not support such multiplicity, and that the lack of such
support is why a message was rejected. Ideally, there would be some
proactive indication of support before the message is sent, but I don't
know enough about EPP to determine whether this is reasonable.
JG-The method for providing more than one <launch:codeMark>, <smd:signedMark> or <smd:encodedSignedMark> is better described in section 3.3.1 “Sunrise Create Form”. The last paragraph may just add confusion, so my recommendation is to remove it. The number of code, marks, and signed marks supported is up to server policy and the best mechanism to communicate that policy in a separate server policy object extension. This is similar to the discussion around communicating the schedule of launch phases. You can find an example object extension (Registry Mapping) for the purpose of communicating the zones (TLDs) available to the client and the features and policies supported by the server at https://www.verisign.com/assets/epp-sdk/verisign_epp-extension_registry_v00.html. Such a policy object extension can be extended (Launch Phase Policy Extension or Registry Fee Policy Extension) to define the policies of extensions like the Launch Phase extension and the Registry Fee Extension. A command-response extension like the Launch Phase Extension does not provide the framework to support defining server policy. Let me know whether removing the last paragraph of section 2.6 makes sense and whether additional language needs to be added to section 3.3.1 for clarification.
Section 3.1 has language indicating that the server "SHOULD validate the
value against the active server launch phase." Minor comment: shouldn't
this be "launch phase(s)"? More substantive comment: If such validation
fails, the server presumably rejects the request? I'd like to see this
stated explicitly, and to indicate which response code is used for such
a rejection.
JG –I assume that you’re referring to the description of the <launch:phase> element in
section 3.1.1. The <launch:phase> element is used across multiple commands, so it may be
best to update the expected validation behavior centrally in section 2.3 “Launch Phases”. There
is already a description of the validation in the first paragraph of section 2.3, where a 2306
EPP error result code is returned. How about updating the first paragraph of section 2.3 to be
more generic by not just applying to a create command and using a MUST for returning the 2306 EPP
result code if there is a mismatch? Then update any references to the <launch:phase>
element in the commands to state “The server SHOULD validate the value according to section 2.3.“
when comparing against the active launch phases. Some of the commands like Check Command using
the Availability Check Form, the Info Command, the Update Command, and the Delete Command refer
to future or past phases, so I explicitly added the text “The server SHOULD validate the value
and return an EPP error result code of 2306 if it is invalid.”. Do you agree with these updates?
Section 3.1.3 indicates that availability MUST NOT be returned when a
trademark check is performed. It's not clear why this restriction is in
place, and it would seem to make scaling more difficult (as clients
desiring both sets of information need to launch two requests). I'd like
to see some explanation in the document why this restriction is desirable.
JG-The reason why is that the Trademark Check Form defines a new command called the Trademark Check Command. Its purpose is separate and distinct from an available check, where the Trademark Check Command is answering the question of whether there is a trademark associated with the domain name independent on the active launch phase and independent on the availability of the domain name. The language exists for the Claims Check Form in creating a Claims Check Command. As you’ll notice in both cases (Trademark Check Command and Claims Check Command), the response does not include the <domain:chkData> which greatly simplifies the response. The language matches the XML schema definition and the examples. The Availability Check Form in section 3.1.2 does not define a new command and appropriately mixes the domain check command with launch phase logic. I’m not sure whether additional language is needed to describe why mixing commands with different purposes is not allowed, but I’m open to providing it if needed.
Section 3.2: "The Application Identifier (Section 2.1) returned in the
<launch:creData> element of the create response (Section 3.3) is used
for retrieving information for a Launch Application." This makes such
use sound mandatory, which I don't think it is. Would rephrase as
"...can be used for retrieving..."
JG-Done
Section 3.2: "<mark:mark> Zero or more <mark:mark> (Section 2.6.2)
elements" -- I would qualify this with "only if 'includeMark' is
indicated in the client response" or something similar.
JG – I updated it to read “Zero or more <mark:mark> (Section 2.6.2.) elements
only if the “includeMark” attribute is “true” in the command.” Do you agree with
this update?
Section 3.3.1 says the server should validate the "type" attribute in
the request. If such validation fails, the server presumably rejects the
request? I'd like to see this stated explicitly, and to indicate which
response code is used for such a rejection.
JG-I modified it to “The server SHOULD validate the "type" attribute, when passed, against the type of object that will be created, and return an EPP error result code of 2306 if the type is incorrect.” Do you agree with this update?
Section 3.3.1: How does a client know which of the four different
approaches are supported by the server? Minimally, I'd expect to see a
unique status code here that allows the client to determine that the
model it has selected is not supported by the server, and that the lack
of such support is why a message was rejected (preferably with some
indication of which model *is* supported). Ideally, there would be some
proactive indication of support before the message is sent, but I don't
know enough about EPP to determine whether this is reasonable.
JG-The approach supported by the server is defined by registry policy. The
launch phase extension provides the interface to support the various launch
phases and registry policies, and the policies are either defined out-of-band
of EPP or in an EPP extension designed for that purpose like the Registry
Mapping (
https://www.verisign.com/assets/epp-sdk/verisign_epp-extension_registry_v00.html
).
Page 31 contains an example that uses an unsigned <mark:mark> section
containing Trademark information without any unique identification. How
does this work? For example: who is allowed to claim what? This would
seem to require some explanation and possibly some text in section 7.
JG- In section 2.6 “Mark Validation Models”, it states “The mark information is
passed without any other validation element. The server will use some custom
form of validation to validate that the mark information is authentic.” The
launch phase extension simply enables the passing of the mark without dictating
the method that the server validates it (validate directly, validate via API or
data feed from an external validator, etc.). Do you want to add something
like this in section 7?
Section 3.3.2: Same question about type validation as for Section 3.3.1,
above.
JG-I added “, and return an EPP error result code of 2306 if the type is incorrect” to the end of the sentence like 3.3.1. Do you agree with this update?
Section 3.3.3: Same question about phase validation as for section 3.1,
above.
JG-I added “, and return an EPP error result code of 2306 if the type is incorrect” to the end of the sentence like 3.3.1. Do you agree with this update?
Section 3.3.4: If the server does not support Mixed Create forms, how
does the client determine this? Minimally, I'd expect to see a unique
status code here that allows the client to determine that the server
does not support this form, and that the lack of such support is why a
message was rejected. Ideally, there would be some proactive indication
of support before the message is sent, but I don't know enough about EPP
to determine whether this is reasonable.
JG-The approach supported by the server is defined by registry policy. The launch phase extension provides the interface to support the various launch phases and registry policies, and the policies are either defined out-of-band of EPP or in an EPP extension designed for that purpose like the Registry Mapping ( https://www.verisign.com/assets/epp-sdk/verisign_epp-extension_registry_v00.html ).
Section 3.3.5: It is easy to read "...MAY reply with..." as saying that
a reply is optional. I don't get the impression that this is the
intention, however; I suspect the intention is that the addition of a
<launch:creData> to the (required) reply is optional. Suggest rephrasing
along the lines of "...server MAY add a <launch:creData> element to the
regular EPP <resData>..."
JG-Done
Page 46 contains literal &qt; and > strings. Comment 1: shouldn't
these just be < and > or quotes? Comment 2: If not, I'll point out that
&qt; is not an XML escape sequence: you probably either mean " (and
want the > to be ") or you mean <.
JG-Done, this had to be changed to just use “.
Section 5.1: Please set the registrant information to the IESG.
JG-Done
Section 7: The first paragraph appears to start with an extraneous "As".
JG-I believe you meant the last paragraph. I changed “As information” to
“Information” to start the last paragraph of section 7.
Thanks!
/a
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
