Guidelines for Authors and Reviewers of IP Flow Information Export (IPFIX) Information Elements
RFC 7013

Note: This ballot was opened for revision 03 and is now closed.

(Ron Bonica) Yes

(Stewart Bryant) (was Discuss) Yes

Comment (2012-09-26 for -06)
No email
send info
Thank you for addressing my concerns.

(Gonzalo Camarillo) No Objection

(Ralph Droms) No Objection

(Wesley Eddy) No Objection

(Adrian Farrel) (was Discuss) No Objection

Comment (2012-11-24)
No email
send info
Thanks for addressing my Discuss and Comments. 
IANA's hold that I had can be released as all IANA actions have been moved to another document.

(Stephen Farrell) (was Discuss) No Objection

(Brian Haberman) No Objection

(Russ Housley) No Objection

Barry Leiba (was Discuss) No Objection

Comment (2012-09-26 for -06)
No email
send info
The beginning of the document, through the beginning of Section 3 (end of page 5), very strongly smells like an Applicability Statement, which should be on Standards Track.  Completion of review and further discussion supports BCP, but it will help to clarify the text up to page 5.  Pete has promised specific comments for that, so I'll leave them to him, but I'm happy to help with it as well.

(Pete Resnick) No Objection

Comment (2012-09-26 for -06)
No email
send info
The abstract tries to jam everything into a single convoluted sentence, and I think it ends up being completely unclear. I make a suggestion here, but I'm not sure I've captured what needs to be captured. The WG needs to check this:

   This document provides guidelines for how to write definitions of new
   Information Elements for the IP Flow Information Export (IPFIX)
   protocol. It provides instructions on using the proper conventions
   for Information Elements to be registered in the IANA IPFIX
   Information Element registry, and provides guidelines for expert
   reviewers to evaluate new registrations.

I'll leave it to the authors to rewrite section 1 along the same lines. In section 1.1, I think you specifically need to mention people who write new IEs and *not* talk about "extending the applicability of IPFIX", as that confused the issue. I also find the use of the word "application" a bit odd here, and I've substituted "use case", but if "application" is understood in this community, that is fine. So, maybe something like:

   This document is meant for two separate audiences. For those wishing
   to write new Information Element specifications, it provides
   guidelines for how to decide which Information Elements are necessary
   for a given existing or new use case, instructions for writing the
   Information Element specification to be registered, and information
   on the kinds of documentation that will be required for the use case
   (up to and including publication of a new RFC). For the IPFIX
   experts...

2. Regarding 2119: I agree with Adrian that the use of 2119 language in this document is wrong, and verges on downright silly. This document is not talking about protocol requirements, or even documentation requirements that need to be followed for interoperability purposes. So for instance, section 4.1 says, "Information Element Names should be defined in accordance with section 2.3 of [I-D.ietf-ipfix-information-model-rfc5102bis]" and then goes on to give some conventions as MUSTs and SHOULDs. But if we look at ietf-ipfix-information-model-rfc5102bis, we find:

   The following naming conventions were used for naming Information
   Elements in this document.  It is recommended that extensions of the
   model use the same conventions.

So even the MUSTs are not requirements, but recommended naming conventions for extensions. I really think you should get rid of all of the 2119 language.

That said, you'll note that this is in a COMMENT. I think for the most part, while useless and silly (it sounds like you are trying to be protocol police), using 2119 in this document is generally not harmful. I am most worried about the use of 2119 to control IANA actions (e.g., 4.3), but even there, disaster is unlikely. So I do beg with you to revisit your decision to use 2119 in this document; I think it adds nothing and detracts from the understanding of 2119 in other documents. But I will not insist on DISCUSSing this with the IESG.

(Robert Sparks) No Objection

(Martin Stiemerling) No Objection

(Sean Turner) No Objection

(Benoît Claise) (was Abstain) Recuse