Launch Phase Mapping for the Extensible Provisioning Protocol (EPP)
draft-ietf-regext-launchphase-07

[Ballot comment]
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.

[Ballot comment]
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")

[Ballot comment]
  qualified by the previously assigned application identifier using the
    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  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:       
I am assuming the base64 goes here. Could you indicate that a bit more clearly than ... somehow?

[Ballot comment]
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  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
    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:



Drop "for"?

[Ballot comment]
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.

[Ballot comment]
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."

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-ietf-regext-launchphase-06. If any part of this review is inaccurate, please let us know.

The IANA Services Operator understands that, upon approval of this document, there are three actions which we must complete.

First, in the ns registry on the IETF XML Registry page located at:

https://www.iana.org/assignments/xml-registry/

a single, new namespace will be registered as follows:

ID: launch-1.0
URI: urn:ietf:params:xml:ns:launch-1.0
Filename: [ TBD-at-Registration ]
Refernce: [ RFC-to-be ]

As this document requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

Second, in the schema registry also on the IETF XML Registry page located at:

https://www.iana.org/assignments/xml-registry/

a single, new schema will be registered as follows:

ID: launch-1.0
URI: urn:ietf:params:xml:schema:launch-1.0
Filename: [ TBD-at-Registration ]
Refernece: [ RFC-to-be ]

As before, this document requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

Third, in the Extensions for the Extensible Provisioning Protocol (EPP) on the Extensions for the Extensible Provisioning Protocol (EPP) registry page located at:

https://www.iana.org/assignments/epp-extensions/

a single, new extension is to be registerd as follows:

Name of Extension: Launch Phase Mapping for the Extensible Provisioning Protocol (EPP)"
Document status: Standards Track
Refernce: [ RFC-to-be ]
Registrant: IESG,
TLDs: Any
IPR Disclosure: None
Status: Active
Notes: None

As before, this document requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

The IANA Services Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.


Thank you,

Sabrina Tanamal
IANA Services Specialist

The following Last Call announcement was sent out (ends 2017-11-03):

From: The IESG
To: IETF-Announce
CC: adam@nostrum.com, regext-chairs@ietf.org, Ulrich Wisser , ulrich@wisser.se, draft-ietf-regext-launchphase@ietf.org, regext@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Launch Phase Mapping for the Extensible Provisioning Protocol (EPP)) to Proposed Standard


The IESG has received a request from the Registration Protocols Extensions WG
(regext) to consider the following document: - 'Launch Phase Mapping for the
Extensible Provisioning Protocol (EPP)'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2017-11-03. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  This document describes an Extensible Provisioning Protocol (EPP)
  extension mapping for the provisioning and management of domain name
  registrations and applications during the launch of a domain name
  registry.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-regext-launchphase/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-regext-launchphase/ballot/


No IPR declarations have been submitted directly on this I-D.

AD Review (version -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.

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

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.

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.

The  and  elements on page 13 are indented further than one would normally expect. The same goes for the  element on page 14.

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.

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.

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.

Section 3.2: "The Application Identifier (Section 2.1) returned in the  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..."

Section 3.2: "  Zero or more  (Section 2.6.2) elements" -- I would qualify this with "only if 'includeMark' is indicated in the client response" or something similar.

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.

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.

Page 31 contains an example that uses an unsigned  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.

Section 3.3.2: Same question about type validation as for Section 3.3.1, above.

Section 3.3.3: Same question about phase validation as for section 3.1, above.

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.

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  to the (required) reply is optional. Suggest rephrasing along the lines of "...server MAY add a  element to the regular EPP ..."

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

Section 5.1: Please set the registrant information to the IESG.

Section 7: The first paragraph appears to start with an extraneous "As".

After speaking with a REGEXT chair, I am expecting a small, payment-related update to this document before putting it into IETF last call (hence: Revised I-D Needed). I plan to complete my evaluation of the current version, and will review the payment-related addition during IETF LC.

Technical Summary

This document describes an Extensible Provisioning Protocol (EPP)
extension mapping for the provisioning and management of domain name
registrations and applications during the launch of a domain name
registry.

Working Group Summary

draft-ietf-regext-launchphase is on standards track.  This extension adds
additional elements to the EPP domain name mapping  defined in RFC 5731,
which is an internet standard.

Document Quality

This document has been widely discussed on the mailing lists of the regext, eppext
and provreg. working groups. The authors have addressed all comments and many
changes have been incorporated in the document.

At IETF 97 the working group came up with a solution to remove the dependency on
a normative reference to a draft document.

ICANN has required of all participants in the newGTLD program to implement some
version of this document.

Verisign, Neustar, CentralNIC and others have working implementations of
this specification.

Personnel

Document shepherd  is Ulrich Wisser, ulrich@wisser.se
Area Director is Adam Roach, adam@nostrum.com

Shepherd Comments

As document shepherd I have verified that all XML examples against the provided 
schema and EPP schemas from RFC 5730 and RFC 5371. Some examples have left
out part of the XML to be more concise and better show the point of the introduced
changes. These examples have been verified by the document shepherd with added
XML data.

The author has confirmed following BCP78 and BCP79 in the document header.
No IPR disclosures have been submitted for this document.

The IANA considerations follow the defined format for the submission to the XML and
EPP registries.

All normative and informative references have been verified.

After carefully reviewing the mailings lists of the regext, eppext and provreg working
groups I have found no objections to this document. From IETF meetings I recall
broad consensus that this document is ready for publication.

As document shepherd I believe this document is ready for publication.

Technical Summary

This document describes an Extensible Provisioning Protocol (EPP)
extension mapping for the provisioning and management of domain name
registrations and applications during the launch of a domain name
registry.

Working Group Summary

draft-ietf-regext-launchphase is on standards track.  This extension adds
additional elements to the EPP domain name mapping  defined in RFC 5731,
which is an internet standard.

Document Quality

This document has been widely discussed on the mailing lists of the regext, eppext
and provreg. working groups. The authors have addressed all comments and many
changes have been incorporated in the document.

At IETF 97 the working group came up with a solution to remove the dependency on
a normative reference to a draft document.

ICANN has required of all participants in the newGTLD program to implement some
version of this document.

Verisign, Neustar, CentralNIC and others have working implementations of
this specification.

Personnel

Document shepherd  is Ulrich Wisser, ulrich@wisser.se
Area Director is Adam Roach, adam@nostrum.com

Shepherd Comments

As document shepherd I have verified that all XML examples against the provided 
schema and EPP schemas from RFC 5730 and RFC 5371. Some examples have left
out part of the XML to be more concise and better show the point of the introduced
changes. These examples have been verified by the document shepherd with added
XML data.

The author has confirmed following BCP78 and BCP79 in the document header.
No IPR disclosures have been submitted for this document.

The IANA considerations follow the defined format for the submission to the XML and
EPP registries.

All normative and informative references have been verified.

After carefully reviewing the mailings lists of the regext, eppext and provreg working
groups I have found no objections to this document. From IETF meetings I recall
broad consensus that this document is ready for publication.

As document shepherd I believe this document is ready for publication.

Technical Summary

This document describes an Extensible Provisioning Protocol (EPP)
extension mapping for the provisioning and management of domain name
registrations and applications during the launch of a domain name
registry.

Working Group Summary

draft-ietf-regext-launchphase is on standards track.  This extension adds
additional elements to the EPP domain name mapping  defined in RFC 5731,
which is an internet standard.

Document Quality

This document has been widely discussed on the mailing lists of the regext, eppext
and provreg. working groups. The authors have addressed all comments and many
changes have been incorporated in the document.

At IETF 97 the working group came up with a solution to remove the dependency on
a normative reference to a draft document.

ICANN has required of all participants in the newGTLD program to implement some
version of this document.

Verisign, Neustar, CentralNIC and others have working implementations of
this specification.

Personnel

Document shepherd  is Ulrich Wisser, ulrich@wisser.se
Area Director is Adam Roach, adam@nostrum.com

Shepherd Comments

As document shepherd I have verified that all XML examples against the provided 
schema and EPP schemas from RFC 5730 and RFC 5371. Some examples have left
out part of the XML to be more concise and better show the point of the introduced
changes. These examples have been verified by the document shepherd with added
XML data.

The author has confirmed following BCP78 and BCP79 in the document header.
No IPR disclosures have been submitted for this document.

The IANA considerations follow the defined format for the submission to the XML and
EPP registries.

There are no informative references. All normative references have been verified.

After carefully reviewing the mailings lists of the regext, eppext and provreg working
groups I have found no objections to this document. From IETF meetings I recall
broad consensus that this document is ready for publication.

As document shepherd I believe this document is ready for publication.

Technical Summary

This document describes an Extensible Provisioning Protocol (EPP)
extension mapping for the provisioning and management of domain name
registrations and applications during the launch of a domain name
registry.

Working Group Summary

draft-ietf-regext-launchphase is on standards track.  This extension adds
additional elements to the EPP domain name mapping  defined in RFC 5731,
which is an internet standard.

#### WG DISCUSSION
-> NORMATIVE REFERENCE TMCH ???
-> REFERENCE ICANN ???

Document Quality

This document has been widely discussed on the mailing lists of the regext, eppext
and provreg. working groups. The authors have addressed all comments and many
changes have been incorporated in the document.

ICANN has
required of all participants in the newGTLD program to implement some version
of this document.

Verisign, Neustar, CentralNIC and other have working implementations of
this specification.

Personnel

Document shepherd  is Ulrich Wisser, ulrich@wisser.se
Area Director is Alexey Melnikov, aamelnikov@fastmail.fm

Shepherd Comments

As document shepherd I have verified that all XML examples against the provided 
schema and EPP schemas from RFC 5730 and RFC 5371. Some examples have left
out part of the XML to be more concise and better show the point of the introduced
changes. These examples have been verified by the document shepherd with added
XML data.

The author has confirmed following BCP78 and BCP79 in the document header.
No IPR disclosures have been submitted for this document.

The IANA considerations follow the defined format for the submission to the XML and
EPP registries.

There are no informative references. All normative references have been verified.
TODO:
#### REFERENCES
->7451 INFORMATIONAL ???
->6982 REPLACED by 7942
->TMCH-FUNC-SPEC


After carefully reviewing the mailings lists of the regext, eppext and provreg working
groups I have found no objections to this document. From IETF meetings I recall
broad consensus that this document is ready for publication.

As document shepherd I believe this document is ready for publication.

Technical Summary

This document describes an Extensible Provisioning Protocol (EPP)
extension mapping for the provisioning and management of domain name
registrations and applications during the launch of a domain name
registry.

Working Group Summary

draft-ietf-regext-launchphase is on standards track.  This extension adds
additional elements to the EPP domain name mapping  defined in RFC 5731,
which is an internet standard.

#### WG DISCUSSION
-> NORMATIVE REFERENCE TMCH ???
-> REFERENCE ICANN ???

Document Quality

This document has been widely discussed on the mailinglist(s).

#### ISSUES DICUSSED ...

ICANN has
required of all participants in the newGTLD program to implent some version
of this document.

Verisign, Neustar, CentralNIC and other have working implementations of
this specification.

Personnel

Document shepherd  is Ulrich Wisser, ulrich@wisser.se
Area Director is Alexey Melnikov, aamelnikov@fastmail.fm

Shepherd Comments

As document shepherd I have verified that all XML examples against the provided 
schema and EPP schemas from RFC 5730 and RFC 5371. Some examples have left
out part of the XML to be more concise and better show the point of the introduced
changes. These examples have been verified by the document shepherd with added
XML data.

The author has confirmed following BCP78 and BCP79 in the document header.
No IPR disclosures have been submitted for this document.

The IANA considerations follow the defined format for the submission to the XML and
EPP registries.

There are no informative references. All normative references have been verified.
TODO:
#### REFERENCES
->7451 INFORMATIONAL ???
->6982 REPLACED by 7942
->TMCH-FUNC-SPEC


After carefully reviewing the mailings lists of the regext, eppext and provreg working
groups I have found no objections to this document. From IETF meetings I recall
broad consensus that this document is ready for publication.

As document shepherd I believe this document is ready for publication.