Scott, Thanks for review the draft. My responses to your feedback are embedded below with a “JG-“ prefix.
— JG James Gould Distinguished Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com <http://verisigninc.com/> On 4/27/17, 9:29 AM, "regext on behalf of Hollenbeck, Scott" <regext-boun...@ietf.org on behalf of shollenb...@verisign.com> wrote: > -----Original Message----- > From: regext [mailto:regext-boun...@ietf.org] On Behalf Of James Galvin > Sent: Wednesday, April 26, 2017 3:25 PM > To: Registration Protocols Extensions <regext@ietf.org> > Subject: [EXTERNAL] [regext] WG Last Call: > https://datatracker.ietf.org/doc/draft-ietf-regext-launchphase/ > > At the last IETF meeting, it was agreed in the REGEXT meeting that the > following document is ready for submission to the IESG to be considered > for publication as a Proposed Standard: > > Launch Phase Mapping for the Extensible Provisioning Protocol (EPP) > https://datatracker.ietf.org/doc/draft-ietf-regext-launchphase/ > > Ulrich Wisser is the document shepherd and in that role he agrees the > document is ready for publication. > > If any working group member objects to the publication of this document > please respond on the list by close of business everywhere, Wednesday, 3 > May 2017. If there are no objections the document will be submitted to > the IESG. I have re-read and re-reviewed draft-ietf-regext-launchphase. I have not attempted to validate the schema or examples. I support publication, but I do have some comments to share: Section 1: s/In addition, the [RFC7848] defines/In addition, RFC 7848 [RFC7848] defines/ Section 2.1: "Upon receiving a valid request to create a Launch Application, the server MUST" There's no mention of what a "valid request to create a Launch Application" looks like, so I'm reading this paragraph and not understanding what the trigger for this MUST clause is. I think it would be helpful to say something like "Upon receiving a valid <domain:create> command" instead. JG- The trigger in creating a Launch Application or Launch Registration is done via the <domain:create>, so the draft can be updated based on your proposed text. "If the <domain:create> command processes a request synchronously without the use of an intermediate Launch Application, then an application identifier MAY not be needed." Does "MAY not be needed" mean that an application identifier will not be returned in this case? Is it more accurate to say "then an application identifier is not needed and will not be returned"? "MAY" implies "optional", and I don't quite get if it's OK to return an application identifier or not. JG- I believe the second paragraph of 2.1 can be removed, since I don’t believe there is a valid use case of an application identifier for a Launch Registration. Section 2.2: "The Internet Corporation for Assigned Names and Numbers (ICANN) Trademark Clearinghouse (TMCH) is the default Trademark Validator and is reserved the Validator Identifier of "tmch"." And "The list of validator identifiers and the relationship to issuer identifiers is out of scope for this document." This sounds like we might need an IANA registry of trademark validator identifiers. If we don't have a registry, how do processors know which values are valid? Does it matter? The text should be clear about this. I don't the text can say "out of scope" while reserving a specific value for one validator. JG-There is no intention on setting up an IANA registry for trademark validator identifiers. The processor in this case is the server who will define the set of accepted trademark validator identifiers based on registry policy (e.g., what validators they decide to support). The only generic trademark validator identifier that is known is “tmch”. The intent of the extension is not to manage the set of validator identifiers but to allow for the passing of the validator identifiers from client to server. It is the responsibility of the server to ensure that the set of acceptable validator identifiers are unique, which could be added to the draft. Do you agree? Section 2.5: "A Launch Application MUST and a Launch Registration MAY be handled as a domain name of [RFC5731] in "pendingCreate" status" What does "a domain name of [RFC5731]" mean? I *think* this is trying to say "an EPP domain name object as specified in RFC 5731 [RFC5731]". If that's the case, please consider changing the text. JG-Yes, “a domain name of [RFC5731]” does mean “an EPP domain name object as specified in RFC 5731 [RFC5731]”. The draft can be updated based on your recommended text. Section 2.6: "A server MUST support at least one of the following models" I'm looking at the schema where the createType is defined. It says that the mark type is choice with minOccurs="0". Does this mean that the mark can be omitted? If so, that appears to be inconsistent with "MUST support at least one" above. JG- The choice with minOccurs=”0” means that the create command can be submitted without the trademark information, as defined in section 2.6, to support the Claims Create Form, as defined in section 3.3.2, and the General Create Form, as defined in section 3.3.3. The Claims Create Form and the General Create Form do not include the trademark information, so section 2.6 is not applicable. The trademark information, as defined in section 2.6, is associated with the Sunrise Create Form and the Mixed Create Form, which do include trademark information. Section 4.1: please update the copyright date. JG-This will be updated. Scott _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
