Organization Extension for the Extensible Provisioning Protocol (EPP)
RFC 8544
Yes
No Objection
Note: This ballot was opened for revision 09 and is now closed.
Alvaro Retana No Objection
(Adam Roach; former steering group member) Yes
(Alexey Melnikov; former steering group member) No Objection
(Alissa Cooper; former steering group member) No Objection
(Ben Campbell; former steering group member) No Objection
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”.
(Benjamin Kaduk; former steering group member) (was Discuss) No Objection
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).
(Deborah Brungard; former steering group member) No Objection
(Eric Rescorla; former steering group member) No Objection
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.
(Martin Vigoureux; former steering group member) No Objection
(Mirja Kühlewind; former steering group member) No Objection
(Spencer Dawkins; former steering group member) No Objection
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?
(Suresh Krishnan; former steering group member) No Objection