Organization Extension for the Extensible Provisioning Protocol (EPP)
draft-ietf-regext-org-ext-11

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?