Subject: [Gen-art] Gen-ART Review of draft-leiba-netmod-regpolicy-update-01

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 14 Dec 2015 13:37:57 +0000

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<https://urldefense.proofpoint.com/v2/url?u=http-3A__wiki.tools.ietf.org_area_gen_trac_wiki_GenArtfaq&d=BQMFAw&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=NMPxI88b49Rd87R2XmkgqLhVC4Bz2IhydB-0MwJ2T0s&s=LW6pxGWbYoxVERnO34-bGIf3JGqbGPADKYJ0QzhJ_Ms&e=>

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:

---

From: Barry Leiba <[email-masked]>
Date: Mon, 14 Dec 2015 09:25:55 -0500

> 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.

I believe that no clarification is needed.  There's no reason at all
to put restrictions on registrations beyond what IETF consensus is at
the time the registration is requested.  Should IETF consensus be to
accept a registration from an Informational document, that's fine.
Perhaps it's not likely, but that'd be up to the consensus of the
IETF, which is the point here.

The non-normative text you cite describes what prompted us to do this.
The normative text is the description of IETF Review in BCP 26.

Barry

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 14 Dec 2015 14:31:14 +0000

Hi Barry,

Thanks for the quick reply and for addressing my comment. 

> Should IETF consensus be to accept a registration
> from an Informational document, that's fine.
> Perhaps it's not likely, but that'd be up to the consensus of the IETF, which is
> the point here.

I am fine with this approach but this is not what the text of the 'motivational' part of the Internet-Draft says. Currently there is an a-synchronism between the text that explains what the I-D tries to do and the action it recommends. 

Regards,

Dan

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Barry Leiba
> Sent: Monday, December 14, 2015 4:26 PM
> To: Romascanu, Dan (Dan)
> Cc: General Area Review Team; draft-leiba-netmod-regpolicy-
> [email-masked]
> Subject: Re: Gen-ART Review of draft-leiba-netmod-regpolicy-update-01
> 
> > 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.
> 
> I believe that no clarification is needed.  There's no reason at all to put
> restrictions on registrations beyond what IETF consensus is at the time the
> registration is requested.  Should IETF consensus be to accept a registration
> from an Informational document, that's fine.
> Perhaps it's not likely, but that'd be up to the consensus of the IETF, which is
> the point here.
>

---

From: Barry Leiba <[email-masked]>
Date: Mon, 14 Dec 2015 11:26:15 -0500

> I am fine with this approach but this is not what the text of the 'motivational' part of the Internet-Draft says. Currently there is an a-synchronism between the text that explains what the I-D tri…

OK, well, you know I'm always in favour of more clarity.  So how does
this sound?:

OLD
   This document changes that
   registration policy to "IETF Review", which also allows registrations
   from certain well reviewed Experimental RFCs.

NEW
   This document changes that
   registration policy to "IETF Review", which also allows registrations
   from certain well reviewed Experimental RFCs, or, for example,
   corrections to registry errors from Informational RFCs, with IETF
   review and consensus.

END

Barry

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 14 Dec 2015 16:27:55 +0000

This looks good to me. 

Thanks and Regards,

Dan

> Sent: Monday, December 14, 2015 6:26 PM
> To: Romascanu, Dan (Dan)
> > I am fine with this approach but this is not what the text of the
> 'motivational' part of the Internet-Draft says. Currently there is an a-
> synchronism between the text that explains what the I-D tries to do and the
> action it recommends.
> 
> OK, well, you know I'm always in favour of more clarity.  So how does this
> sound?:
> 
> OLD