Ben, Thanks again, I provide responses to your feedback below. — JG
James Gould Distinguished Engineer [email protected] 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 11/29/17, 4:32 PM, "Ben Campbell" <[email protected]> wrote: Thanks for your quick response. Please see inline: Thanks! Ben. > On Nov 29, 2017, at 6:17 PM, Gould, James <[email protected]> wrote: > > Ben, > > Thank you for the review. I include the responses to your feedback embedded below. > > Thanks, > > — > > JG > > […] > > > 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? > > The scope of uniqueness is at the server-level, where “tmch” is reserved. If a server supports additional validators, the “server MUST define the list of supported validator identifiers and MUST make this information available to clients using a mutually acceptable, out-of-band mechanism.” Hopefully, this answers you question. Would it be reasonable to say, near the uniqueness requirement, that that the identifiers need to be unique for a particular server? (I assume this means that two servers do not need to use the same ID for the same validator). Correct, two servers do not need to use the same ID for the same validator. How about modifying “Both the Validator Identifier and the Issuer Identifier used MUST be unique” to “Both the Validator Identifier and the Issuer Identifier used MUST be unique in the server”? > > -2.2, last paragraph: > I don't understand what is meant by this paragraph. Please elaborate. > > I assume that you’re referring to “The Validator Identifier MAY define a non-Trademark Validator that supports a form of claims.”. The concept of claims and a Validator Identifier is based on the use of a Trademark Validator, but it is understood that other forms for validators MAY develop that go beyond trademarks. Adding text to that effect would be helpful. (except for the upper case MAY, since I think it’s a statement of fact.) How about “The Validator Identifier may define a non-Trademark Validator that supports a form of claims, where claims and a Validator Identifier can be used for purposes beyond trademarks.”? > > > -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? > > The use of the “lang” attribute is based on what has been done in RFC 5731 (normative). Sure, but do you think it’s reasonable to leave out the tag? Allowing that in 5731 might not have been the best precedent. The use of the optional the “lang” attribute with the “en” default is used throughout the EPP RFCs, so I believe that it should follow the precedent of 5731. > > > -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? > > The custom status value is defined to support corner cases and is not recommended using SHOULD NOT of RFC 2119? Are there corner cases you have in mind? As written, that seems to say “here’s an extension point, but we hope you won’t use it”. Is the point that people SHOULD NOT use it for cases where an existing status value would be appropriate? We believe that the set of statuses will meet the needs for launching a TLD, but we don’t want to limit the use of the launch phase extension. It is important to have a concrete set of statuses along with an extension point. The guidance is that use of the extension point should be avoided if possible. > > > -3.4, 2nd paragraph, first sentence: Is a client expected to know in advance > whether the server supports launch applications? If so, how? > > The client is expected to know based on either an out-of-band mechanism, or an in-band mechanism that is being discussed now within the REGEXT working group. It would help to say something to that effect in the text. I believe the mechanism of communicating the policy of the server is out-of-scope for the launch phase extension. The extension defines what is expected from the client (MUST NOT) and the server (return a 2102 error) to match the server policy. This is a slippery slope, since there are other server policy elements (e.g., mark validation models, check forms, create forms) defined in the extension that the client needs to know out-of-band currently and in-band in the future. [ I leave resolution of my editorial comments to your discretion.] _______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
