Last Call Review of draft-cotton-rfc4020bis-01

Request Review of draft-cotton-rfc4020bis
Requested rev. no specific revision (document currently at 02)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2013-09-24
Requested 2013-08-29
Authors Michelle Cotton
Draft last updated 2013-09-12
Completed reviews Genart Last Call review of -01 by Robert Sparks (diff)
Genart Telechat review of -02 by Robert Sparks
Secdir Last Call review of -01 by Tero Kivinen (diff)
Assignment Reviewer Robert Sparks
State Completed
Review review-cotton-rfc4020bis-01-genart-lc-sparks-2013-09-12
Reviewed rev. 01 (document currently at 02)
Review result On the Right Track
Review completed: 2013-09-12


    I am the assigned Gen-ART reviewer for this draft. For background on

    Gen-ART, please see the FAQ at 



    Please resolve these comments along with any other Last Call comments


    you may receive. 

    Document: draft-cotton-rfc4020bis-01

    Reviewer: Robert Sparks 

    Review Date: 2013-09-11

    IETF LC End Date: 2013-09-24

    IESG Telechat date: not scheduled

    This draft is on the right track but has open issues, described in
    the review.

    (That summary was taken from the options in RFC6385. I would prefer
    to say

    "There is one minor issue that is bigger than a nit, but it should
    be easy to straighten out")

    Issue : Section 2 is very confusing. It starts out listing 4 things
    that look like they all have to be met. But then the last sentence
    confuses things. Is just reinforcing that both a and b have to be
    met (if so, then wouldn't things also stop if c and d weren't met?
    (see 3.1 step2)). 

    I suggest replacing "If conditions (a) or (b)" with "If any of the
    above conditions"

    Nit 1: Section 3.1 reads harshly at the transition from step 4 to
    step 5.  It leaves it implicit that the AD has to approve.

    Step 3 has  "if steps 2 and 3 are satisfied". 4020 said "with the
    approval of the Area Director(s)". Adding that text  to step 5 would
    address the nit.

    Nit 2: The introduction contains a bit of text that it carried
    forward, slightly modified, from 4020 for which I suggest further


    "the IETF community wishes to retain tight control of the protocol"


    "the IETF community has consensus to retain tight control of the
    registry content"

    That way this document is reflecting the actual process point that
    would lead to a tighter registration policy without trying to
    speculate what motivated that consensus.

    Nit 3: Several reviewers have pointed to a lack of clarity in
    section 2 a.

    I suggest taking the change John Klensin proposed (with tweaks as

	The code points must normally be from a space designated
	as "RFC Required", "IETF Review", or "Standards Action".
	In addition, code points from a "Specification
	Required" space are allowed if the specification will be
	published as an RFC.