Ballot for draft-ietf-regext-org-ext
Yes
No Objection
Note: This ballot was opened for revision 09 and is now closed.
Thanks for the work on this. I have a few comments: *** Substantive Comments *** §1: "An organization mapping object defined in [ID.draft-ietf-regext-org] SHOULD be created first." First before what? *** Editorial Comments *** - General: I'm a little confused by the split in material between draft-ietf-regext-org and draft-ietf-regext-org-ext, especially how the command mapping and related info seems to span both documents. It seems a bit reader-unfriendly. But it's late enough in the process that it's probably not worth changing. - Abstract: Please expand EPP on first mention both in the abstract and in the body. §2, 3rd paragraph: I know we are not consistent about this, but I find the word “conforming” to be a red flag. Standards track RFCs should be about interoperability, not conformance. I suggest striking all after “presented”.
Thank you for addressing my Discuss points! [Original Comment section preserved below] Section 1 In the business model of domain registration, we usually have 3 roles of entities: a registrant, a registrar and a registry. There may be other roles of entities involved in the domain registration process which are not formally defined, such as resellers, DNS service operators, privacy proxies, etc. nit: Perhaps I am misreading, but are we not going to formally define these entities in the next paragraph (in which case "yet" might be worth adding)? An organization mapping object defined in [ID.draft-ietf-regext-org] SHOULD be created first. The organization information specified in this document MUST reference the existing organization identifier. What does "first" refer to? "prior to the use of that object"? Section 2 The XML namespace prefix "orgext" is used, but implementations MUST NOT depend on it and instead employ a proper namespace-aware XML parser and serializer to interpret and output the XML documents. [This could probably be written more clearly; see my comment on the companion document] Section 9 IIRC the authorization model for EPP does not allow arbitrary clients to retrieve information about arbitrary (unrelated) domains. If that's not the case, there would be privacy considerations with respect to exposing the linkages of the organization mappings (and roles).
Rich version of this review at: https://mozphab-ietf.devsvcdev.mozaws.net/D3938 COMMENTS S 4.2.1. > C: <domain:pw>fooBAR</domain:pw> > C: </domain:authInfo> > C: </domain:create> > C: </create> > C: <extension> > C: <orgext:create FWIW, this would be easier to read if the new fields were decorated in some way.
If "huh?" was a ballot position, I would have used it. I'm actually too confused to ballot Discuss :-) I see several subsections of the form This extension does not add any elements to the EPP <check> command or <check> response described in the EPP object mapping. I see other subsections in the same section that say what the extension DOES, not just what the extension does not do. Is there anything that can be included in these sections to tell the reader more about what the effect of using the extension actually is?