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

["Gould, James" <[e-mail]>]

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


[cid:[e-mail]]

James Gould
Distinguished Engineer
[e-mail]

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

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

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


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.


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.

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

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.


#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?


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

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


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

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


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 <[e-mail]<mailto:[e-mail]>> 写道：

Submitted for DE evaluation.

Scott

-----Original Message-----
From: Amanda Baber via RT [mailto:[e-mail]]
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., [e-mail]

TLDs: Any

IPR Disclosure: https://datatracker.ietf.org/ipr/2553/

Status: Active

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

—


JG





James Gould
Distinguished Engineer
[e-mail]

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
[e-mail]
https://www.ietf.org/mailman/listinfo/eppext


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