Extensible Provisioning Protocol (EPP) Domain Name Mapping Extension for Strict Bundling Registration
draft-yao-regext-bundling-registration-06

(Via drafts-eval@iana.org): IESG/Authors/ISE:

The IANA Functions Operator has completed its review of draft-yao-regext-bundling-registration-05. If any part of this review is inaccurate, please let us know.

We understand that when this document is sent to us for processing, we will perform three registry actions.

First, epp:b-dn will be added to the IETF XML ns registry at https://www.iana.org/assignments/xml-registry.

Second, epp:b-dn will be added to the IETF XML schema registry at https://www.iana.org/assignments/xml-registry.

Third, the following entry will be added to the Extensions for the Extensible Provisioning Protocol (EPP) registry at https://www.iana.org/assignments/epp-extensions:

Name of Extension: Domain Name Mapping Extension for Strict Bundling Registration
Document Status: Informational
Reference: this document
Registrant: See "Author's Address" section of this document
TLDs: Any
IPR Disclosure: https://datatracker.ietf.org/ipr/2479
Status: Active
Notes: None

Thank you,

Amanda Baber
Lead IANA Services Specialist

EPP Extensions expert:

1. Sections 9.1.1 and 9.1.2 describe an "IDN namespace" and an "IDN XML Schema", but I *think* these should refer to a "BDN namespace" and a "BDN XML Schema" to match the values in the URIs that are being registered. If that's the case, the text should be updated.

2. Section 9.2 includes a URL for the generic Datatracker IPR page. I believe it should point to this specific IPR declaration:

https://datatracker.ietf.org/ipr/2479/

With these changes it would be OK.

====

XML ns/schema expert:

The registrations are mostly OK. They need the schemaLocation attributes stripped though.

The XML namespace prefix "b-dn" is used for the namespace
"urn:ietf:params:xml:ns:epp:b-dn", but implementations must not rely
on it and instead employ a proper namespace-aware XML parser and
serializer to interpret and output the XML documents.

This is mostly OK, but it creates a bad impression. It implies that a certain prefix might be privileged, which is not possible. This could instead say that ``This document uses the prefix "b-dn" for the namespace "urn..." throughout. Implementations cannot assume that any particular prefix is used and MUST employ a namespace-aware XML parser...``. Either that or the paragraph could be removed entirely.

draft-yao-regext-bundling-registration has been brought to the ISE for
publication as an Informational RFC in the Independent Submissions
Stream.

Previously, this work advanced through the EPPEXT and then the
REGEXT working group as draft-ietf-regext-bundling-registration.
That document passed working group last call, AD review, and IETF
last call before being assessed by the IESG. The IESG ballot shows
one Discuss (about the intended status of the document, and
whether it should be presented as a proprietary solution).

More notably, it appears that the IESG determined that the WG and IETF
last calls amounted to "consensus by silence," and that the IETF had no
reason to care about advancing the document. Barry Leibe, the
responsible AD at the time, was convinced by the arguments and suggested
to the authors that they try the Independent Stream.

The document was reviewed for the ISE by Yoshiro Yoneya who has
experience of registry management through his work at Japan Registry
Services. His review is shown below, as is the ISE's review. all
comments have been addressed satisfactorily.

John Klensin also sent significant comments and suggested text to the
authors who made changes accordingly.

The question of whether this document is of broad enough interest to the
wider community (or just to the registries that implement it) is to
some extent answered in the Introduction by the text:

  This extension is especially useful for registries of practicing
  Chinese domain name registration.  This method is also useful for
  other language domain names that have similar issues with Chinese
  domain names.

The final document makes it clear that this is a proprietary
specification both in the Abstract...
 
  This is a non-standard proprietary extension.

...and in the Introduction...

  This document describes a non-standard proprietary extension.

Note that there is IPR disclosed against the original document at
https://datatracker.ietf.org/ipr/2479/ when the document was in
the EPPEXT working group.

A final point of note is that this document asks for IANA action that
is from registries that use the "Specification Required" allocation
policy. That means that review by a DE is required. The original
REGEXT document had already progressed through DE review and so we
expect that a further review is just a formality.

** Yoshiro Yoneya review **

Page 3: 1st paragraph

  In this paragraph, the term 'V-label' and 'V-tld' are introduced.
  V-label is said that 'shared the same TLD' but 'V-tld' is not.
  It should be explicitly explained that V-tld must be managed by the same entity.

Page 3: last paragraph

  Although original intention of bundling is for Chinese Domain Names,
  it will be useful adding notes that this method is applicable for other
  language domain names that have variants.

Page 4: 2. Terminology, 2nd paragraph

  "LABEL.Variants" and "Variants.LABEL" notation is differ from Page3,
  "LABEL.V-tld" and "V-label.TLD".  Notation of technical term have to be
  consistend in whole document.
  The last sentence, "..., those TLDs should be controlled by the same registry"
  will be more clear "..., those TLDs must be managed by the same entity".

Page 5: 3. Definitions

  I don't see clear distinction between "Terminology" section and
  "Definitions" section.  Those can be mereged into one section.

Page 5: 4. Overview, 3rd paragraph

  Before the last sentence, there should be explanation that there are
  "allocatable" bundled names and "blocked" bundled names.
  Both bundled names are in one package, but some objects such as name
  server association and domain status are not synchronized (registrants
  can't modify any object of blocked bundled names).
  I believe this is very important concept of bundled names, but it is not
  addressed in this document.
  This document seems assuming any bundled names are all allocatable bundled names.
  Informative reference to LGR (RFC 7940) and ICANN Root/SLD LGR works
  will be very helpful.

Page 6: 2nd paragraph

  The 3rd point, "o When performing a domain Create, either of the bundle
  names will be accepted.  If the domain name is available, both BDN and
  RDN will be registered." is contradictional.
  The label (domain name) used for domain create it is always RDN.
  Apparantly from its definition, BDN is delivarable of RDN.

Page 8: Example  response:

  As its nature of variants, BDNs for a RDN could be tens of thousands or more.
  This fact means that the response of  for BDNs will be huge size.
  Therefore, there must be some mechanisms to eliminate huge response,
  such as indicating numbers of BDNs and temporal download URI for all of BDNs.
  Otherwise, this could be DoS mechanism for both registries and registrars.

Page 9: Example  response for an authorized client:

  As mentioned above, BDNs have "allocatable" or "blocked" attribute also.
  Those must be included in the response.
  Response size issue commented at  command is issue here also.

Page 11: 7.2.1.  EPP  Command

  I can't understand meaning for  extension.
  Is it for specifying uLabel?  If so, why A-Label in  is insufficient?
  Clarification of  extention meaning is very much appreciated.

Page 12: Example  response:

  Please refer comments for  command above (for Page 8).

Page 13: 7.2.2.  EPP  Command

  Please refer comments for  command above (for Page 8).

Page 14: 7.2.3.  EPP  Command

  Please refer comments for  command above (for Page 8).

Page 16: Example  response:

  Please refer comments for  command above (for Page 8).

Page 17: Example  response:

  Please refer comments for  command above (for Page 8).

Page 21: 1st paragraph

  I assume this paragraph is going to say "zone file for RDN and BDNs
  can be different even though served by the same name server."
  If this document mandates domain objects of RDN/BDNs (except for
  "blocked" BDNs) are bundled and being the same (synchronized),
  DS/DNSKEY records have to be the same as well.
  And if it is correct, this paragraph should say "Because RDN/BDNs share
  the same DS/DNSKEY information, signing keys for those zones must be
  the same, therefore, the bundled domain names share fate if there is a
  key compromise."

** ISE review **

==Question==

Is there an issue to consider about interop between implementations that
do and do not support the extensions in this document.  This would
happen either if a client that supports this document sends a request to
a server that does not support this document (I think that is safe from
my understanding of this draft), or if a client that does not support
this document receives a response from a server that does support it (I
think this is more of a risk, but I suspect that RFC 5731 may cover
this.

It could be nice to add a few lines of text just to reassure people that
there are no issues.

==Rewrite==

The IANA section could usefully indicate the name of the registry so
IANA can easily determine what action to take. Also, I think it will
make things easier to follow it you break section 9 into subsections.
So...

OLD
9.  IANA Considerations

  This document uses URNs to describe XML namespaces and XML schemas
  conforming to a registry mechanism described in [RFC3688].  IANA is
  requested to assignment the following two URIs.

  Registration request for the IDN namespace:

  o  URI: urn:ietf:params:xml:ns:epp:b-dn

  o  Registrant Contact: See the "Author's Address" section of this
      document.

  o  XML: None.  Namespace URI does not represent an XML specification.

  Registration request for the IDN XML schema:

  o  URI: urn:ietf:params:xml:schema:epp:b-dn

  o  Registrant Contact: See the "Author's Address" section of this
      document.

  o  XML: See the "Formal Syntax" section of this document.

  The EPP extension described in this document should be registered by
  IANA in the "Extensions for the Extensible Provisioning Protocol
  (EPP)" registry described in [RFC7451].  The details of the
  registration are as follows:

  o  Name of Extension: "Domain Name Mapping Extension for Strict
      Bundling Registration"

  o  Document status: Informational

  o  Reference: This document

  o  Registrant Name and Email Address: See the "Author's Address"
      section of this document.

  o  Top-Level Domains (TLDs): Any

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

  o  Status: Active

  o  Notes: None
NEW
9.  IANA Considerations

9.1.  XML Namespace and XML Schema

  This document uses URNs to describe XML namespaces and XML schemas
  conforming to a registry mechanism described in [RFC3688].

9.1.1.  IDN Namespace

  IANA is requested to make an assignment from the IETF XML Registry
  "ns" registry as follows for the IDN namespace with this document
  as the reference:

  o  URI: urn:ietf:params:xml:ns:epp:b-dn

  o  Registrant Contact: See the "Author's Address" section of this
      document.

  o  XML: None.  Namespace URI does not represent an XML specification.

9.1.2.  IDN XML Schema

  IANA is requested to make an assignment from the IETF XML Registry
  "schema" registry as follows for the IDN XML schema with this
  document as the reference:

  o  URI: urn:ietf:params:xml:schema:epp:b-dn

  o  Registrant Contact: See the "Author's Address" section of this
      document.

  o  XML: See the "Formal Syntax" section of this document.

9.2.  EPP Extension

  The EPP extension described in this document should be registered by
  IANA in the "Extensions for the Extensible Provisioning Protocol
  (EPP)" registry described in [RFC7451].  The details of the
  registration are as follows:

  o  Name of Extension: "Domain Name Mapping Extension for Strict
      Bundling Registration"

  o  Document status: Informational

  o  Reference: This document

  o  Registrant Name and Email Address: See the "Author's Address"
      section of this document.

  o  Top-Level Domains (TLDs): Any

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

  o  Status: Active

  o  Notes: None
END

==Nits==

1.
s/In RFC4290/In RFC4290 [RFC4290]/
s/according the domain/according to the domain/
s/the same TLD/the same Top Level Domain (TLD)/
s/For an example, Public/For example, the Public/
s/label(LABEL)/label (LABEL)/
s/names to share many same/names to share many of the same/
s/transferring of any/transferring any/
s/bundling names registration/bundling name registration/
s/variant IDNs should/variant Internationalized Domain Name (IDNs) should/

2.
s/according the domain/according to the domain/
OLD
  The Registered Domain Name(RDN) and Bundled Domain Name(BDN) are used
  in this document.
NEW
  The terms Registered Domain Name (RDN) and Bundled Domain Name (BDN)
  are used in this document.
END
OLD
  In the current practice, BDN's number will
  usually be kept to one according to the registration policy set by
  the registry.
NEW
  In current practice, the number of BDNs is
  usually be kept to one according to the registration policy set by
  the registry.
END

3.
OLD
  that property of all other domain objects in the bundle
  package will be updated at the same time.
NEW
  that property will be updated at the same time for all other domain
  objects in the bundle package.
END

4.
s/some parameter or attributes/some parameters or attributes/
Second bullet list. Can you format the bullets with:
  - all text indented and aligned
  - a blank line between bullets

4.
In the second bullet list, you have EPP commands in different cases
for example, domain transfer and domain Create. For clarity, I think
these might usefully always be capitalised as Domain Transfer and Domain
Create. Note, however, that 5731 uses "EPP " or simply
"". You probably want to mirror that way of doing things since
it is consistent with later on in the document.

6.1.2
s/changed,see/changed, see/

6.2.1
s/When an  command/When a  command/
s/if an  command/if a  command/

8.
s/use of UTF-8 is recommend./use of UTF-8 is recommended./
s/the elements, element/the elements, and element/

10.
s/more than 15 years/more than 15 years experience/

draft-yao-regext-bundling-registration has been brought to the ISE for
publication as an Informational RFC in the Independent Submissions
Stream.

Previously, this work advanced through the REGEXT working group as
draft-ietf-regext-bundling-registration. That document passed working
group last call, AD review, and IETF last call before being assessed by
the IESG. The IESG ballot shows one Discuss (about the intended status
of the document, and whether it should be presented as a proprietary
solution).

More notably, it appears that the IESG determined that the WG and IETF
last calls amounted to "consensus by silence," and that the IETF had no
reason to care about advancing the document. Barry Leibe, the
responsible AD at the time, was convinced by the arguments and suggested
to the authors that they try the Independent Stream.

The document was reviewed for the ISE by Yoshiro Yoneya who has
experience of registry management through his work at Japan Registry
Services. His review is shown below, as is the ISE's review. all
comments have been addressed satisfactorily.

John Klensin also sent significant comments and suggested text to the
authors who made changes accordingly.

The question of whether this document is of broad enough interest to the
wider community (or just to the registries that implement it) is to
some extent answered in the Introduction by the text:

  This extension is especially useful for registries of practicing
  Chinese domain name registration.  This method is also useful for
  other language domain names that have similar issues with Chinese
  domain names.

The final document makes it clear that this is a proprietary
specification both in the Abstract...
 
  This is a non-standard proprietary extension.

...and in the Introduction...

  This document describes a non-standard proprietary extension.

A final point of note is that this document asks for IANA action that
is from registries that use the "Specification Required" allocation
policy. That means that review by a DE is required. The original
REGEXT document had already progressed through DE review and so we
expect that a further review is just a formality.

** Yoshiro Yoneya review **

Page 3: 1st paragraph

  In this paragraph, the term 'V-label' and 'V-tld' are introduced.
  V-label is said that 'shared the same TLD' but 'V-tld' is not.
  It should be explicitly explained that V-tld must be managed by the same entity.

Page 3: last paragraph

  Although original intention of bundling is for Chinese Domain Names,
  it will be useful adding notes that this method is applicable for other
  language domain names that have variants.

Page 4: 2. Terminology, 2nd paragraph

  "LABEL.Variants" and "Variants.LABEL" notation is differ from Page3,
  "LABEL.V-tld" and "V-label.TLD".  Notation of technical term have to be
  consistend in whole document.
  The last sentence, "..., those TLDs should be controlled by the same registry"
  will be more clear "..., those TLDs must be managed by the same entity".

Page 5: 3. Definitions

  I don't see clear distinction between "Terminology" section and
  "Definitions" section.  Those can be mereged into one section.

Page 5: 4. Overview, 3rd paragraph

  Before the last sentence, there should be explanation that there are
  "allocatable" bundled names and "blocked" bundled names.
  Both bundled names are in one package, but some objects such as name
  server association and domain status are not synchronized (registrants
  can't modify any object of blocked bundled names).
  I believe this is very important concept of bundled names, but it is not
  addressed in this document.
  This document seems assuming any bundled names are all allocatable bundled names.
  Informative reference to LGR (RFC 7940) and ICANN Root/SLD LGR works
  will be very helpful.

Page 6: 2nd paragraph

  The 3rd point, "o When performing a domain Create, either of the bundle
  names will be accepted.  If the domain name is available, both BDN and
  RDN will be registered." is contradictional.
  The label (domain name) used for domain create it is always RDN.
  Apparantly from its definition, BDN is delivarable of RDN.

Page 8: Example  response:

  As its nature of variants, BDNs for a RDN could be tens of thousands or more.
  This fact means that the response of  for BDNs will be huge size.
  Therefore, there must be some mechanisms to eliminate huge response,
  such as indicating numbers of BDNs and temporal download URI for all of BDNs.
  Otherwise, this could be DoS mechanism for both registries and registrars.

Page 9: Example  response for an authorized client:

  As mentioned above, BDNs have "allocatable" or "blocked" attribute also.
  Those must be included in the response.
  Response size issue commented at  command is issue here also.

Page 11: 7.2.1.  EPP  Command

  I can't understand meaning for  extension.
  Is it for specifying uLabel?  If so, why A-Label in  is insufficient?
  Clarification of  extention meaning is very much appreciated.

Page 12: Example  response:

  Please refer comments for  command above (for Page 8).

Page 13: 7.2.2.  EPP  Command

  Please refer comments for  command above (for Page 8).

Page 14: 7.2.3.  EPP  Command

  Please refer comments for  command above (for Page 8).

Page 16: Example  response:

  Please refer comments for  command above (for Page 8).

Page 17: Example  response:

  Please refer comments for  command above (for Page 8).

Page 21: 1st paragraph

  I assume this paragraph is going to say "zone file for RDN and BDNs
  can be different even though served by the same name server."
  If this document mandates domain objects of RDN/BDNs (except for
  "blocked" BDNs) are bundled and being the same (synchronized),
  DS/DNSKEY records have to be the same as well.
  And if it is correct, this paragraph should say "Because RDN/BDNs share
  the same DS/DNSKEY information, signing keys for those zones must be
  the same, therefore, the bundled domain names share fate if there is a
  key compromise."

** ISE review **

==Question==

Is there an issue to consider about interop between implementations that
do and do not support the extensions in this document.  This would
happen either if a client that supports this document sends a request to
a server that does not support this document (I think that is safe from
my understanding of this draft), or if a client that does not support
this document receives a response from a server that does support it (I
think this is more of a risk, but I suspect that RFC 5731 may cover
this.

It could be nice to add a few lines of text just to reassure people that
there are no issues.

==Rewrite==

The IANA section could usefully indicate the name of the registry so
IANA can easily determine what action to take. Also, I think it will
make things easier to follow it you break section 9 into subsections.
So...

OLD
9.  IANA Considerations

  This document uses URNs to describe XML namespaces and XML schemas
  conforming to a registry mechanism described in [RFC3688].  IANA is
  requested to assignment the following two URIs.

  Registration request for the IDN namespace:

  o  URI: urn:ietf:params:xml:ns:epp:b-dn

  o  Registrant Contact: See the "Author's Address" section of this
      document.

  o  XML: None.  Namespace URI does not represent an XML specification.

  Registration request for the IDN XML schema:

  o  URI: urn:ietf:params:xml:schema:epp:b-dn

  o  Registrant Contact: See the "Author's Address" section of this
      document.

  o  XML: See the "Formal Syntax" section of this document.

  The EPP extension described in this document should be registered by
  IANA in the "Extensions for the Extensible Provisioning Protocol
  (EPP)" registry described in [RFC7451].  The details of the
  registration are as follows:

  o  Name of Extension: "Domain Name Mapping Extension for Strict
      Bundling Registration"

  o  Document status: Informational

  o  Reference: This document

  o  Registrant Name and Email Address: See the "Author's Address"
      section of this document.

  o  Top-Level Domains (TLDs): Any

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

  o  Status: Active

  o  Notes: None
NEW
9.  IANA Considerations

9.1.  XML Namespace and XML Schema

  This document uses URNs to describe XML namespaces and XML schemas
  conforming to a registry mechanism described in [RFC3688].

9.1.1.  IDN Namespace

  IANA is requested to make an assignment from the IETF XML Registry
  "ns" registry as follows for the IDN namespace with this document
  as the reference:

  o  URI: urn:ietf:params:xml:ns:epp:b-dn

  o  Registrant Contact: See the "Author's Address" section of this
      document.

  o  XML: None.  Namespace URI does not represent an XML specification.

9.1.2.  IDN XML Schema

  IANA is requested to make an assignment from the IETF XML Registry
  "schema" registry as follows for the IDN XML schema with this
  document as the reference:

  o  URI: urn:ietf:params:xml:schema:epp:b-dn

  o  Registrant Contact: See the "Author's Address" section of this
      document.

  o  XML: See the "Formal Syntax" section of this document.

9.2.  EPP Extension

  The EPP extension described in this document should be registered by
  IANA in the "Extensions for the Extensible Provisioning Protocol
  (EPP)" registry described in [RFC7451].  The details of the
  registration are as follows:

  o  Name of Extension: "Domain Name Mapping Extension for Strict
      Bundling Registration"

  o  Document status: Informational

  o  Reference: This document

  o  Registrant Name and Email Address: See the "Author's Address"
      section of this document.

  o  Top-Level Domains (TLDs): Any

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

  o  Status: Active

  o  Notes: None
END

==Nits==

1.
s/In RFC4290/In RFC4290 [RFC4290]/
s/according the domain/according to the domain/
s/the same TLD/the same Top Level Domain (TLD)/
s/For an example, Public/For example, the Public/
s/label(LABEL)/label (LABEL)/
s/names to share many same/names to share many of the same/
s/transferring of any/transferring any/
s/bundling names registration/bundling name registration/
s/variant IDNs should/variant Internationalized Domain Name (IDNs) should/

2.
s/according the domain/according to the domain/
OLD
  The Registered Domain Name(RDN) and Bundled Domain Name(BDN) are used
  in this document.
NEW
  The terms Registered Domain Name (RDN) and Bundled Domain Name (BDN)
  are used in this document.
END
OLD
  In the current practice, BDN's number will
  usually be kept to one according to the registration policy set by
  the registry.
NEW
  In current practice, the number of BDNs is
  usually be kept to one according to the registration policy set by
  the registry.
END

3.
OLD
  that property of all other domain objects in the bundle
  package will be updated at the same time.
NEW
  that property will be updated at the same time for all other domain
  objects in the bundle package.
END

4.
s/some parameter or attributes/some parameters or attributes/
Second bullet list. Can you format the bullets with:
  - all text indented and aligned
  - a blank line between bullets

4.
In the second bullet list, you have EPP commands in different cases
for example, domain transfer and domain Create. For clarity, I think
these might usefully always be capitalised as Domain Transfer and Domain
Create. Note, however, that 5731 uses "EPP " or simply
"". You probably want to mirror that way of doing things since
it is consistent with later on in the document.

6.1.2
s/changed,see/changed, see/

6.2.1
s/When an  command/When a  command/
s/if an  command/if a  command/

8.
s/use of UTF-8 is recommend./use of UTF-8 is recommended./
s/the elements, element/the elements, and element/

10.
s/more than 15 years/more than 15 years experience/

Request for posting confirmation emailed  to submitter and authors: Jiagui Xie , Linlin Zhou , Jiankang Yao , Ning Kong , Hongtao Li , Wil Tan