Subject: [regext] Benjamin Kaduk's No Objection on draft-ietf-regext-org-ext-10: (with COMMENT)

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 29 Nov 2018 19:07:13 -0800

Benjamin Kaduk has entered the following ballot position for
draft-ietf-regext-org-ext-10: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-regext-org-ext/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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).

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Fri, 30 Nov 2018 12:15:15 +0000

> -----Original Message-----
> From: regext <[email-masked]> On Behalf Of Benjamin Kaduk
> Sent: Thursday, November 29, 2018 10:07 PM
> To: The IESG <[email-masked]>
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: [EXTERNAL] [regext] Benjamin Kaduk's No Objection on draft-ietf-
> regext-org-ext-10: (with COMMENT)
>
> 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)?

If definitions are needed, it may make sense to cite those described in draft-ietf-dnsop-terminology-bis. The Datatracker says it's in the RFC Editor's AUTH48 state, so it should be available as an RFC in a matter of days.

Scott