Skip to main content

Last Call Review of draft-leiba-netmod-regpolicy-update-01
review-leiba-netmod-regpolicy-update-01-genart-lc-romascanu-2015-12-14-00

Request Review of draft-leiba-netmod-regpolicy-update
Requested revision 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
Authors Barry Leiba
I-D 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
Request Last Call review on draft-leiba-netmod-regpolicy-update by General Area Review Team (Gen-ART) Assigned
Reviewed revision 01 (document currently at 02)
Result Almost ready
Completed 2015-12-14
review-leiba-netmod-regpolicy-update-01-genart-lc-romascanu-2015-12-14-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



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



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: