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


    Gen-ART, please see the FAQ at 







<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>

.
    





    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





    Summary:
    
    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
    modification:


    replace


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


    with


    "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
    below)







	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.