Skip to main content

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: