Last Call Review of draft-ietf-regext-bundling-registration-09
review-ietf-regext-bundling-registration-09-genart-lc-halpern-2019-03-07-00
Request | Review of | draft-ietf-regext-bundling-registration |
---|---|---|
Requested revision | No specific revision (document currently at 11) | |
Type | Last Call Review | |
Team | General Area Review Team (Gen-ART) (genart) | |
Deadline | 2019-03-15 | |
Requested | 2019-03-01 | |
Authors | Ning Kong , Jiankang Yao , Linlin Zhou , Wil Tan , Jiagui Xie | |
I-D last updated | 2019-03-07 | |
Completed reviews |
Secdir Last Call review of -09
by Russ Housley
(diff)
Genart Last Call review of -09 by Joel M. Halpern (diff) Secdir Telechat review of -11 by Russ Housley Genart Telechat review of -11 by Joel M. Halpern |
|
Assignment | Reviewer | Joel M. Halpern |
State | Completed | |
Request | Last Call review on draft-ietf-regext-bundling-registration by General Area Review Team (Gen-ART) Assigned | |
Reviewed revision | 09 (document currently at 11) | |
Result | Almost ready | |
Completed | 2019-03-07 |
review-ietf-regext-bundling-registration-09-genart-lc-halpern-2019-03-07-00
I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-regext-bundling-registration-09 Reviewer: Joel Halpern Review Date: 2019-03-07 IETF LC End Date: 2019-03-15 IESG Telechat date: Not scheduled for a telechat Summary: This document is almost ready for publication as some form of RFC Major issues: This document defines protocol extensions and mandatory procedures to go with them. As such, it seems it is either Experimental or Proposed Standard, but not Informational. Minor issues: Section 5 consists of a list of behavioral requirements that appear normative, but do not use RFC 2119 language. If these are indeed normative behavioral requirements, the document should use RFC 2119 language to be clear. (And therefore, should also include the text explaining and citing RFC 2119.) The description in 7.2.1 of the EPP <create> command seems lacking. After saying that it needs an extension element, it says: The <extension> element SHOULD contain a child <b-dn:create> element that identifies the bundle namespace and the location of the bundle name schema. It is unclear when it is reasonable to omit this <b-dn:create> element. (We normally include with "SHOULD" explanations of this sort.) It is unspecified what format of the information in the <b-dn:create> element has. I suspect that it is assumed to be the same as some other piece of EPP information, but it does not say so. The only child element for <b-dn:create> given in the schema is the <b-dn:rdn> which is neither a namespace identifier nor a location of the bundle name schema. Again in 7.2.2 on the EPP <delete> command, when discussing the addition to the response, it is a SHOULD with no explanation of when it is okay to omit it. The same applies to the 7.2.3 EPP <renew> command, the 7.2.4 EPP <transfer> command, and the 7.2.5 EPP <update> command. Nits/editorial comments: