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

Discuss

(Mirja Kühlewind)

Yes

(Barry Leiba)

No Objection

Éric Vyncke
(Deborah Brungard)

No Record

Deb Cooley
Erik Kline
Francesca Palombini
Gunter Van de Velde
Jim Guichard
John Scudder
Mahesh Jethanandani
Murray Kucherawy
Orie Steele
Paul Wouters
Roman Danyliw
Warren Kumari
Zaheduzzaman Sarker

Summary: Needs a YES.

Éric Vyncke
No Objection
Comment (2019-10-15) Sent 
Thank you for the work put into this document. The document is easy to read. I have a couple of comments and nits. Feel free to ignore all of them as their sole goal is to improve your document.

Regards,

-éric

== COMMENTS ==

-- Section 5 --
	"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."

   Should it rather be "If BDN and RDN are available, then both..." ?
   
-- Section 11 --
The 2 sentences about the experience gained in 15 years should be put in a different paragraph and even perhaps moved in the implementation status.

Unsure also whether the DS/DNSKEY part should be part of the security considerations.

== NITS ==

Generic, I find it weird to have all dates in the examples dated in 1999 or 2001 or 2012 ;-)
Deb Cooley
No Record
Erik Kline
No Record
Francesca Palombini
No Record
Gunter Van de Velde
No Record
Jim Guichard
No Record
John Scudder
No Record
Mahesh Jethanandani
No Record
Murray Kucherawy
No Record
Orie Steele
No Record
Paul Wouters
No Record
Roman Danyliw
No Record
Warren Kumari
No Record
Zaheduzzaman Sarker
No Record
Mirja Kühlewind Former IESG member
Discuss
Discuss [Treat as non-blocking comment] (2019-10-15) Sent 
I’m not certain about the intended status of this document. I understand that this was discussed in the group but this document does specify a protocol extension and as such Proposed Standard or Experimental would be the two usual choices. The shepherd write-up mentions that this extension only has a limited scope, however, not sure what that is supposed to mean and it also doesn’t seems a good reason for informational (but experimental maybe). There are informational RFCs that document protocols of existing deployments for informational purposed only, meaning that there is a good reason to have a description of an existing protocol in a stable reference while the process of publishing the RFC would not change any technical means of that protocol but only document what’s out there. Usually these kind of RFC have a title like “Campany’s X protocol for something”. However, this seems not to be the case here or at least it's not clear from the content of the document.
Barry Leiba Former IESG member
Yes
Yes (2019-10-09) Not sent 
From the Designated Expert review:

OLD:
<import namespace="urn:iana:xml:ns:eppcom-1.0"
schemaLocation="eppcom-1.0.xsd"/>
NEW:
<import namespace="urn:iana:xml:ns:eppcom-1.0"/>
Deborah Brungard Former IESG member
No Objection
No Objection () Not sent