Last Call Review of draft-leiba-netmod-regpolicy-update-01

Request Review of draft-leiba-netmod-regpolicy-update
Requested rev. no specific revision (document currently at 02)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2015-12-21
Requested 2015-11-23
Draft last updated 2015-12-14
Completed reviews Genart Last Call review of -01 by Dan Romascanu (diff)
Genart Telechat review of -02 by Dan Romascanu
Opsdir Last Call review of -01 by Nevil Brownlee (diff)
Assignment Reviewer Dan Romascanu
State Completed
Review review-leiba-netmod-regpolicy-update-01-genart-lc-romascanu-2015-12-14
Reviewed rev. 01 (document currently at 02)
Review result Almost Ready
Review completed: 2015-12-14


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


Document: draft-leiba-netmod-regpolicy-update-01

Reviewer:  Dan Romascanu

Review Date: 12/14/15

IETF LC End Date: 12/21/15

IESG Telechat date: 


Summary: Almost Ready 


A short, clear and useful document. There is however one issue that needs to be clarified and may need edits before the document is approved.  


Major issues:


The goal of the document is to relax the registration policy of the NETCONF Capability URNs to allow for such allocations to be done via ‘certain Experimental RFCs also, provided those specifications are carefully reviewed.’ The proposed
 action is to change the registration policy to “IETF Review” ‘which also allows registrations from certain well reviewed Experimental RFCs.”


The problem is that the “IETF Review” policy is not restricted to Experimental RFCs which seems to be the motivation of the document. Informational RFCs can also be subject to IETF Review for example. The IANA Considerations section
 does either instruct IANA to consider only Standards Track and Experimental RFCs. I believe that this needs to be clarified in Section 2, and the registry be marked “IETF Review – see [RFC XXXX]” so that people asking for allocation be directed to the clarification
 of the policy. 


Minor issues:


Nits/editorial comments: