Skip to main content

Guidelines for Authors and Reviewers of IP Flow Information Export (IPFIX) Information Elements
draft-ietf-ipfix-ie-doctors-07

Yes

(Ron Bonica)

No Objection

(Brian Haberman)
(Gonzalo Camarillo)
(Martin Stiemerling)
(Ralph Droms)
(Robert Sparks)
(Russ Housley)
(Sean Turner)
(Stephen Farrell)
(Wesley Eddy)

Recuse

(Benoît Claise)

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

Ron Bonica Former IESG member
Yes
Yes (for -03) Unknown

                            
Stewart Bryant Former IESG member
(was Discuss) Yes
Yes (2012-09-26 for -06) Unknown
Thank you for addressing my concerns.
Adrian Farrel Former IESG member
(was Discuss) No Objection
No Objection (2012-11-24) Unknown
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.
Barry Leiba Former IESG member
(was Discuss) No Objection
No Objection (2012-09-26 for -06) Unknown
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.
Brian Haberman Former IESG member
No Objection
No Objection (for -05) Unknown

                            
Gonzalo Camarillo Former IESG member
No Objection
No Objection (for -06) Unknown

                            
Martin Stiemerling Former IESG member
No Objection
No Objection (for -05) Unknown

                            
Pete Resnick Former IESG member
No Objection
No Objection (2012-09-26 for -06) Unknown
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.
Ralph Droms Former IESG member
No Objection
No Objection (for -06) Unknown

                            
Robert Sparks Former IESG member
No Objection
No Objection (for -05) Unknown

                            
Russ Housley Former IESG member
No Objection
No Objection (for -05) Unknown

                            
Sean Turner Former IESG member
No Objection
No Objection (for -06) Unknown

                            
Stephen Farrell Former IESG member
(was Discuss) No Objection
No Objection (2012-09-26 for -06) Unknown

                            
Wesley Eddy Former IESG member
No Objection
No Objection (for -06) Unknown

                            
Benoît Claise Former IESG member
(was Abstain) Recuse
Recuse (for -03) Unknown