Subject: Re: [eppext] [IANA #814928] INSERT “Related Domain Extension for the Extensible Provisioning Protocol (EPP)"

From: Ning Kong <[email-masked]>
Date: Sun, 5 Apr 2015 18:52:06 +0800

I have completed my review of the extension as DE and and I have the following comments to share:
#1 It seems to me that this extension proposes to meet more flexible requirements than draft-kong-eppext-bundling-registration. Adding more detailed explanation about the problem statement and requirements of this extension in the Introduction section would be helpful for the readers to understand.

#2 Based on section 3.1.2.1, each <relDom:field> can be differently set to be synchronized across all of the related domains or not. But <relDom:update> defined in section 3.2.5 support batch update across multiple related domains. IMO, this flexible mechanism may cause correct maintaining related domains to be a complicate work especially when there are lots of related domains and lots of different and asynchronous <relDom:field>. I wonder if additional result codes about error info should be added as hints for clients.

#3 Based on the examples in section 3.1.2, <info> response for a domain using the Domain Info Form only contains the "variant" related domain information which belongs to the same TLD as the queried domain name. But <info> response for a domain using the Related Info Form contains the "variant" related domain information within all TLDs. Is it a potential different rule between the Domain Info Form and the Related Info Form? Or just a coincidence?

#4 It would be better that <relDom:lang> in this extension be in line with "IDN Language Tag for the Extensible Provisioning Protocol (EPP)”.

#5 As for the variants domains, a ulabel attribute or element would help user to understand the unicode form of the domain.

Nits,
In each last example in section 3.2.2 and 3.2.3, exampleX.com rather than exampleX.tld is actually used.

Ning

> 在 2015年3月24日，上午1:43，Hollenbeck, Scott <[email-masked]> 写道：
> 
> Submitted for DE evaluation.
> 
> Scott
> 
> -----Original Message-----
> From: Amanda Baber via RT [mailto:[email-masked]] 
> Sent: Monday, March 23, 2015 12:49 PM
> Cc: Hollenbeck, Scott
> Subject: [IANA #814928] INSERT “Related Domain Extension for the Extensible Provisioning Protocol (EPP)"
> 
> #18 of 18.
> 
> -----BEGIN FORM-----
> Name of Extension:
> “Related Domain Extension for the Extensible Provisioning Protocol (EPP)"
> 
> Document Status: 
> Informational
> 
> Reference: 
> http://www.verisigninc.com/assets/epp-sdk/verisign_epp-extension_related-domain_v00.html
> 
> Registrant Name and Email Address:
> VeriSign Inc., [email-masked]
> 
> TLDs: Any
> 
> IPR Disclosure: https://datatracker.ietf.org/ipr/2553/
> 
> Status: Active
> 
> Notes: None
> -----END FORM-----
> 
> —
> 
> 
> JG
> 
> 
> 
> 
> 
> James Gould
> Distinguished Engineer
> [email-masked]
> 
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
> 
> VerisignInc.com
> 
> “This message (including any attachments) is intended only for the use of the individual or entity to which it is addressed, and may contain information that is non-public, proprietary, privileged, confidential and exempt from disclosure under applicable law or may be constituted as attorney work product. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this message in error, notify sender immediately and delete this message immediately.”
> 
> Download BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png
> 
> image/png 4KiB
> Image not shown because display is disabled in system configuration.
> _______________________________________________
> EppExt mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/eppext

---

From: "Gould, James" <[email-masked]>
Date: Mon, 6 Apr 2015 02:03:49 +0000

Ning,

Thank you for the review.  Below is my feedback.  As mentioned at the EPPEXT WG meeting, there may be interest in bundling the bundling extensions (play on words) that I’m assuming will come up.

—

JG

James Gould
Distinguished Engineer
[email-masked]

703-948-3271
12061 Bluemont Way
Reston, VA 20190

VerisignInc.com<http://VerisignInc.com>

On Apr 5, 2015, at 6:52 AM, Ning Kong <[email-masked]<mailto:[email-masked]>> wrote:

Yes, the Related Domain Extension is broader than draft-kong-eppext-bundling-registration to address a different approach to related domain names that apply across TLD’s (related TLD’s) and within a TLD (e.g. variants and client-defined relationships).  I took note that additional context could be provided in the Introduction section.

The <relDom:field> elements in section 3.1.2.1 define server enforced synchronized fields of related domains, which can apply to any set of fields.  The flexibility built into the update extension, in section 3.2.5, is needed to enable the client to ensure that the related domains are always kept in sync, since the update would apply to a set of domains in one command.  If the domains are not already synchronized, I do agree that handling a multi-domain update may result in some complex error conditions.  It’s best to leverage the multi-domain update of the related domain extension on domains that are already synchronized.

The difference between the two forms of the info command really doesn’t apply to what is related (inter or intra TLD), but more to whether or not the client is interested in the information for an existing domain (Domain Info Form) or just the relationship information (Related Info Form).

I’m not sure what you mean by this.  The intend of the <relDom:lang> element is to be in line with the <idnLang:tag> element of the “IDN Language Tag for the Extensible Provisioning Protocol (EPP)”.

Thanks for that suggestion.

Nits,
In each last example in section 3.2.2 and 3.2.3, exampleX.com<http://exampleX.com> rather than exampleX.tld is actually used.

Good catch, thanks.

Ning

在 2015年3月24日，上午1:43，Hollenbeck, Scott <[email-masked]<mailto:[email-masked]>> 写道：

Scott

-----Original Message-----
From: Amanda Baber via RT [mailto:[email-masked]]
Sent: Monday, March 23, 2015 12:49 PM
Cc: Hollenbeck, Scott
Subject: [IANA #814928] INSERT “Related Domain Extension for the Extensible Provisioning Protocol (EPP)"

#18 of 18.

-----BEGIN FORM-----
Name of Extension:

Document Status:
Informational

Reference:

TLDs: Any

Status: Active

Notes: None
-----END FORM-----

—

JG

James Gould
Distinguished Engineer
[email-masked]

703-948-3271
12061 Bluemont Way
Reston, VA 20190

VerisignInc.com

image/png 4KiB

_______________________________________________
EppExt mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/eppext

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 6 Apr 2015 21:29:13 +0000

I have sent a note to IANA indicating DE approval for this request.

Scott

> From: EppExt [mailto:[email-masked]] On Behalf Of Hollenbeck,
> Scott
> Sent: Monday, March 23, 2015 1:43 PM
> To: [email-masked]
> Subject: [eppext] FW: [IANA #814928] INSERT “Related Domain Extension
> for the Extensible Provisioning Protocol (EPP)"
> 
> “This message (including any attachments) is intended only for the use
> of the individual or entity to which it is addressed, and may contain
> information that is non-public, proprietary, privileged, confidential
> and exempt from disclosure under applicable law or may be constituted
> as attorney work product. If you are not the intended recipient, you
> are hereby notified that any use, dissemination, distribution, or
> copying of this communication is strictly prohibited. If you have
> received this message in error, notify sender immediately and delete
> this message immediately.”
>