Launch Phase Mapping for the Extensible Provisioning Protocol (EPP)
RFC 8334

Note: This ballot was opened for revision 06 and is now closed.

Alvaro Retana No Objection

Warren Kumari No Objection

Comment (2017-11-28 for -06)
No email
send info
I agree with Scott Bradner's OpsDir review -- in Section 1.1 the use of the uppercase REQUIRED seems incorrect.

In addition (nit), in Section 2.2.  Validator Identifier
"The Validator Identifier is the identifier, that is unique..." -- this comma seems incorrect.

I have not validated the XML, and am relying on the DS / AD to have done so.

(Adam Roach; former steering group member) Yes

Yes ( for -06)
No email
send info

(Alexey Melnikov; former steering group member) No Objection

No Objection (2017-11-29 for -06)
No email
send info
This is a well written document. I have several clarifying questions and comments that you should consider.

2.3.  Launch Phases

   The server MAY support multiple launch phases sequentially or
   simultaneously.  The <launch:phase> element MUST be included by the
   client to define the target launch phase of the command.  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, and return an EPP error result code of 2306 if
   there is a mismatch.

Is there a registry for codes like 2306? Either way, I couldn't figure out if this is a new code or already assigned one.


2.4.  Status Values

   Each status value MAY be accompanied by a string of human-readable
   text that describes the rationale for the status applied to the
   object.  The OPTIONAL "lang" attribute MAY be present to identify the
   language if the negotiated value is something other than the default
   value of "en" (English).

You need to have a Normative Reference to Language Tags here (RFC 5646).

Nit on page 19:
Typo: identifer --> identifier

Nit on page 47:

<!--
     Enumeration of for launch phase values.
     -->

Drop "for"?

(Alia Atlas; former steering group member) No Objection

No Objection ( for -06)
No email
send info

(Alissa Cooper; former steering group member) No Objection

No Objection ( for -06)
No email
send info

(Ben Campbell; former steering group member) No Objection

No Objection (2017-11-29 for -06)
No email
send info
Substantive Comments:

-2.2, 2nd to last paragraph: "Both the Validator Identifier and the Issuer ot
Identifier used MUST be unique."
At what scope must they be unique? Can you offer guidance on how to ensure uniqueness?

-2.2, last paragraph:
I don't understand what is meant by this paragraph. Please elaborate.

-2.4, paragraph after definitions: "The OPTIONAL "lang" element MAY be present..."
Why is this only a MAY? Is it really reasonable to leave out the language tag for non-English languages?

-2.4, 3rd to last paragraph:
Why does the custom status value exist if the server should not use it? Are there cases where a client uses it?

-3.4, 2nd paragraph, first sentence: Is a client expected to know in advance whether the server supports launch applications? If so, how?

Editorial Comments:

- There are lowercase instances of 2119 keywords. I assume those are not meant as normative keywords. If so, please consider using the boilerplate from RFC 8174 instead of 2119.

- General: I urge a pass to check the use of 2119/8174 keywords. I think there may be some instances where the author typed words in upper case from habit where the keywords don't make sense.  I point out some of these below, but I suspect I did not get all of them.

-1-1, 3rd paragraph: "REQUIRED" seems like a statement of fact.

-2.2, first sentence: s/that/which

-2.3, definitions: Please consider avoiding 2119 keywords in definitions? As written, they read more like statements of fact than normative requirements. (Please feel free to ignore this, since it is really a style issue.)
Also, please try to add white space between hanging indent list entries. They are hard to read when run together. (Same for other definition sections.)

-2.3, last paragraph: Please avoid 2119 keywords in examples.

-2.3.1: The "MUST" and "MAY" seem like statements-of-fact.

-2.4, 2nd to last paragraph: 2119 keywords in examples.

-2.6.1, first paragraph: The "that" might should be a "which". But it's not clear to me whether the word is intended to constrain which codemark elements are being discussed ("that") , or to just mention that codemark elements are used in those models. ("which")

(Deborah Brungard; former steering group member) No Objection

No Objection ( for -06)
No email
send info

(Eric Rescorla; former steering group member) No Objection

No Objection (2017-11-29 for -06)
No email
send info
   qualified by the previously assigned application identifier using the
   <launch:applicationID> element.
Maybe I'm not following, but you say above that launch phase is FCFS, but then how do multiple applications work?



   not used or multiple Trademark Validators are used, the Validator
   Identifier MUST be defined using the "validatorID" attribute.
Does this mean that you must use some validator?



   The following launch phase values are defined:
Nit: you say that these are launch phase values but then below define things as non-launch phase.



   Claims Check Form  Claims Check Form (Section 3.1.1) is used to
      determine whether or not there are any matching trademarks for a
You seem to have duplication here.



      retrieving the claims information.
   Claims Create Form  Claims Create Form (Section 3.3.2) is used to
      pass the Claims Notice acceptance information in a create command.
And here.



   schema for the encoded signed mark that has an element that
   substitutes for the <smd:encodedSignedMark> element from [RFC7848].
I know that 7848 defines signedMark, but probably a good idea to say you have to validate it.



   C:         xmlns:smd="urn:ietf:params:xml:ns:signedMark-1.0">
   C:         ...
   C:        </smd:encodedSignedMark>
I am assuming the base64 goes here. Could you indicate that a bit more clearly than ... somehow?

(Kathleen Moriarty; former steering group member) No Objection

No Objection ( for -06)
No email
send info

(Mirja K├╝hlewind; former steering group member) No Objection

No Objection (2017-11-06 for -06)
No email
send info
One nit (in security consideration section):
OLD:
"Updates to, and deletion of an application object must be restricted
   to clients authorized to perform the said operation on the object."
MAYBE:
"Updates to, and deletion of an application object MUST be restricted
   to clients authorized to perform the said operation on the object."

(Spencer Dawkins; former steering group member) No Objection

No Objection (2017-11-29 for -06)
No email
send info
I wondered about the use of "launch" in the title and Abstract of this document, as possibly not easily parsable for some readers. I'm looking at 

   It is typical for domain registries to operate in special modes
   during their initial launch to facilitate allocation of domain names,
   often according to special rules.  This document uses the term
   "launch phase" and the shorter form "launch" to refer to such a
   period.

and wondering if 

   It is typical for domain registries to operate in special modes
   during their initial launch to facilitate allocation of domain names,

s/during their initial launch/as they begin operation/

   often according to special rules.  This document uses the term
   "launch phase" and the shorter form "launch" to refer to such a
   period.

might be correct, and easier for some folks to parse (especially since the first paragraph is basically saying 'This document uses "launch phase" and "launch" to refer to "launch"', which doesn't add as much as I hoped :-)

If that makes sense, I'll leave you to decide whether a similar substitution might make sense in the Abstract, but do the right thing.

(Suresh Krishnan; former steering group member) No Objection

No Objection ( for -06)
No email
send info

(Terry Manderson; former steering group member) No Objection

No Objection ( for -06)
No email
send info