Re: [eppext] Fw: New Version Notification for draft-kong-eppext-bundling-registration-01.txt

["Jiankang Yao" <[e-mail]>]

thanks for your kind comments.
the comments are inline.



Jiankang Yao

发件人： Jiankang Yao
发送时间： 2015-06-25 11:17
收件人： Jiankang
主题： 
From: Patrick Mevzek
Date: 2015-06-21 05:33
To: Jiankang Yao
CC: eppext
Subject: Re: [eppext] Fw: New Version Notification for draft-kong-eppext-bundling-registration-01.txt
Jiankang Yao <[e-mail]> 2015-04-14 03:45
> Dear all,
> 
>      During last IETF EPPEXT meeting, the WG showed the interests to
>      the EPP extension to the bundle domain name registrations.
> 
>      This is the new version for this document.
>     http://www.ietf.org/internet-drafts/draft-kong-eppext-bundling-registration-01.txt
>   
> 
>      any comments are welcome.

I've just implemented it in my Net::DRI toolkit.
[Jiankang Yao] 
thanks a lot. it is great. 

Please find below my comments, both on deep issues and nitpicks in the
document.


I would recommand using another namespace & prefix than b-dn which is
not very descriptive.
Same for rdb/bdn nodes names.
[Jiankang Yao] 
ok, we will consider it. 

1. Introduction

* "are shared in the different TLDs."
=> remove the

* "For example, public Interest Registry, request"
=> For example, Public Interest Registry requested

* "in which the second level labels (V-label) are varants"
=> are variants

* "It does not specify how to register the bindled names which share
* the same contributes."
=> It does not specify how to register the bundled names which share
the same attributes.

[Jiankang Yao] 
ok, we will update it. 

5.  Requirement for Bundling Registration of Names

* "should share some parameter or attributes assoicated with domain
* names."
=> attributes associated

* "When performing a domain check,"
[…]
"When performing a domain query"

Isn't the query the domain:check command? Hence the second part could
be removed.

[Jiankang Yao] 
ok, we will update it.  

6.1.  RDN

"   The RDN is an ASCII name or an IDN with the A-label [RFC5890] form
   which is converted from the corresponding RDN.
"

I do not fully understand this definition, specifically since there is
a kind of circular reference: The RDN is ... from the corresponding
RDN"
[Jiankang Yao] 
My origianl meaning is that A-label is converted from the unicode form of RDN(IDN).

will update it to "The RDN is an ASCII name or an IDN with the A-label [RFC5890] form"
 

"For example: <b-dn:rdn uLabel="U+5B9E""U+4F8B".example> xn--
   fsq270a.example</b-dn:rdn>
"

=> you should explain somewhere (maybe in section 2) the syntax with
"U+XXXX"
Also, in terms of syntax there are missing quotes for the attributes
uLabel, it should be uLabel="something" or uLabel='something'


Same remarks for the next paragraph about "BDN".
[Jiankang Yao] 
ok, we will update it.   



7.1.1 domain:check

If I understand correctly, it means that even if the registrar
provides only one name in the domain:check he may receive multiple answers.
I believe this to be confusing and not in the spirit of EPP.

I would offer the following recommandations:
- extend the domain:check query so that the registrar has to
  explicitly allow this behavior or not
- in the reply, mark specifically the rdn and the bdn
 
[Jiankang Yao] 

the current way is 

S:        <domain:cd>
S:                  <domain:name avail="1">xn--fsqz41a.example</domain:name>
S:                  <domain:reason>This associated domain name is a produced name
                according to some bundle domain name policy.</domain:reason>
S:        </domain:cd>


in the reason field, which says something.

do u think that it is ok?
 

or, another way to do it,
just leave the standard domain:check response as is but extend it and
put specifically the rdn and bdn in the extension part.

7.2.  EPP Transform Commands

You explain there basically that all commands replies will be
extended.
But then for each command later on you again state they are extended.
I believe this is redundant.

You should either remove the generic explanation and keep each
specific ones,
or keep the generic ones and then remove all specific ones.

I would favor the first option.
[Jiankang Yao] 
ok, we will update it.    

7.2.1.  EPP <create> Command

I do not understand the aim of the empty extension.
Does that convey the information that the registrar wants to register
the bundle?
But then, it is really optionnally? Since if a registry has variants,
they are always on or always off, no? It is not per domain.
[Jiankang Yao] 
thanks for pointing out it.
It should not be empty extension. 

In your example you have:
   C:        <extension:
where it should be: <extension>

Also the associated schema has:
      <!--
      Child elements found in EPP     commands.
      -->
      <element name="create" type="b-dn:createDataType"/>

      <!--
      Child elements of the <b-dn:create>     command
      All     elements must be present at     time of creation
      -->
      <complexType name="createDataType">
        <sequence>
              <element name="rdn" type="b-dn:rdnType"
               minOccurs="0" maxOccurs="unbounded" />
        </sequence>
      </complexType>

Which is not explained at all…
[Jiankang Yao] 
will consider to update it. 

7.2.4.  EPP <transfer> Commands

This part is not clear, and has no example:
"However, when
   either RDN or BDN is sent for transfer, response SHOULD contain
both
   RDN and BDN information."

How do you achieve that? There is no place in the core EPP transfer
reply
to have multiple domains…
[Jiankang Yao] 
will consider to add an example. 

7.2.5.  EPP <update> Commands

Same problems as above, and even more since update responses have no
data by default.

[Jiankang Yao] 
will consider to update it. 
 

I believe that you have a problem with the schema, a part seems to be
missing:

      <!--
      <transfer> response     elements.
      All     elements must be present at     time of poll query
      -->



Kong, et al.              Expires April 4, 2015                [Page
15]


Internet-Draft          EPP bundled names Mapping           October
2014


              <element name="rdn" type="b-dn:rdnType" />
              <element name="pdn" type="b-dn:rdnType"
                          minOccurs="0"   maxOccurs="unbounded" />

        </sequence>
      </complexType>

The starting <complexType> and <sequence> are missing.

Also you have node name "pdn" which is not explained in the draft.
[Jiankang Yao] 
pdn should not be here. typos
 
And the node "bdn" is missing also.
[Jiankang Yao] 
will  update it. 


thanks again for your detailed comments and nice implementations.

Jiankang Yao