Skip to main content

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

Revision differences

Document history

Date Rev. By Action
2013-09-04
07 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2013-08-29
07 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2013-08-12
07 (System) RFC Editor state changed to RFC-EDITOR from REF
2013-08-09
07 (System) RFC Editor state changed to REF from EDIT
2013-07-16
07 (System) RFC Editor state changed to EDIT from MISSREF
2013-04-24
07 Benoît Claise Document shepherd changed to Juergen Quittek
2013-04-09
07 Benoît Claise Shepherding AD changed to Joel Jaeggli
2012-12-03
07 Cindy Morgan State changed to RFC Ed Queue from Approved-announcement sent
2012-12-03
07 (System) IANA Action state changed to No IC
2012-12-03
07 Amy Vezza State changed to Approved-announcement sent from Approved-announcement to be sent
2012-12-03
07 Amy Vezza IESG has approved the document
2012-12-03
07 Amy Vezza Closed "Approve" ballot
2012-12-03
07 Amy Vezza Ballot approval text was generated
2012-12-03
07 Amy Vezza Ballot writeup was changed
2012-11-25
07 Ron Bonica State changed to Approved-announcement to be sent from IESG Evaluation::AD Followup
2012-11-24
07 Adrian Farrel
[Ballot comment]
Thanks for addressing my Discuss and Comments.
IANA's hold that I had can be released as all IANA actions have been moved to …
[Ballot comment]
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.
2012-11-24
07 Adrian Farrel [Ballot Position Update] Position for Adrian Farrel has been changed to No Objection from Discuss
2012-10-03
07 (System) Sub state has been changed to AD Followup from Revised ID Needed
2012-10-03
07 Brian Trammell New version available: draft-ietf-ipfix-ie-doctors-07.txt
2012-10-02
06 Roni Even Request for Telechat review by GENART Completed: Ready. Reviewer: Roni Even.
2012-09-27
06 Cindy Morgan State changed to IESG Evaluation::Revised ID Needed from IESG Evaluation
2012-09-27
06 Adrian Farrel
[Ballot discuss]
Updated Discuss further after email exchange with Brian and discussions with Benoit.

Please note that I am also holding my Discuss for IANA …
[Ballot discuss]
Updated Discuss further after email exchange with Brian and discussions with Benoit.

Please note that I am also holding my Discuss for IANA to ensure they are fully happy with their actions for this I-D.

---

This document appears to update RFC 5102. That RFC defined
the registry and sets up the guidelines for expert review of
allocation requests.This document is changing those
guidelines.

Not quite sure how that will fit in when you come to publish
I-D.ietf-ipfix-information-model-rfc5102bis, and I know that this I-D
has a normative reference to that I-D so they will pop out together.

A way to fix this would be to yank all of the IANA stuff and put it
in 5102bis. Then this document simply instruct the IE-doctors to
ensure the IANA allocation requests match the rules.

---

Section 4

  o  The Information Element MUST be unique within the registry.  Its
      description MUST represent a substantially different meaning from
      that of any existing Information Element.  A proposed Information
      Element which is a substantial duplicate of an existing
      Information Element is to be represented using the existing
      Information Element.

Surely this is too subjective. What does "substantially different"
actually mean? I tried to rewrite this for you in terms of data type,
units, and range, but I think that is probably only a part of what you
are talking about. For re-use of an existing Information Element you
presumably need those three parameters to be the same, *and* some other
quality has to be the same.

Depending on the description being similar seems really doubtful. Can
you clarify this?

---

Section 4

  o  The Information Element SHOULD be generally applicable to the
      application at hand, which SHOULD be of general interest to the
      community.

I find this a bit worrying. What are you saying about proposals from
outside the IETF? How is the "general interest to the community" to be
measured? Are the designated experts called upon to call consensus?

---

Section 4.3 defines rules for IANA Allocation of code points. Including
notes on the ranges. Is it your intention that the registry is updated
to point to this document? If so, you should make that statement in the
IANA considerations section.

On the other hand, this seems to be a restatement of what is already in
the registry, so I wonder whether the section can be left out.

---

Doesn't Section 11 give rise to some additional rules that are not
captured in the body of the document and (importantly) not in the
checklists of Section 7?

---

Section 12

Do you need to tell IANA how to populate the Revision and Date fields in
the IE registry for IEs that have already been defined?
2012-09-27
06 Adrian Farrel
[Ballot comment]
Comment updated to remove my rant!

---

The use of 2119 language seems entirely inappropriate to me. There is
nothing to be implemented …
[Ballot comment]
Comment updated to remove my rant!

---

The use of 2119 language seems entirely inappropriate to me. There is
nothing to be implemented and no bits on the wire. The designated
experts are humans not machines - speak to them in English!

---

Section 4.1

  o  Names of Information Elements SHOULD be descriptive.

Why on earth do you want to allow non-descriptive names?

---

Section 4.2

  Information Elements of type string or octetArray which have length
  constraints (fixed length, minimum and/or maximum length) MUST note
  these constraints in their description.

  The type of an Information Element MUST match the type of the data it
  represents.  More specifically, information that could be represented
  as a string, but which better matches one of the other data types
  (e.g. an integral type for a number or enumerated type, an address
  type for an address) MUST be represented by the best-matching type,
  even if the data was represented using a different type in the
  source.  In other words, an IPFIX application that exports Options
  Template Records mapping IP addresses to additional information about
  each host from an external database MUST use Information Elements of
  an address type to represent the addresses, even if the source
  database represented these as strings.

Do you need to say that strings and octetArrays must not be used to
encode data that would be more properly encoded in other data types
perhaps using multiple information elements with a forward pointer to
Section 4.5?

---

Section 4.3

  In general, when adding newly registered Information Elements to the
  IANA IE registry, IANA SHOULD assign the lowest available Information
  Element identifier (the value column in [iana-ipfix-assignments]) in
  the range 128-32767.

What does "in general" mean and how is IANA to interpret it?

---

Section 4.9

  However, for reasons of history,
  there are several Information Elements within the IANA IE registry
  which do not follow best practices in Information Element design.
  These Information Elements are not necessarily so flawed so as to
  require deprecation, but they should be explicitly ignored when
  looking for guidance as to whether a new Information Element should
  be added.

Now, I know the experts are experts, and it is completely obvious to
them which IEs don't follow best practices, but the poor fool building
a new spec is being asked for a rock. Can you not list the IEs that
should be ignored?

---

Section 6

  Due to the limited number space of Information Elements in the IANA
  IE registry, avoiding redundancy and clutter in the registry is
  important in defining new applications.

Nah!
I agree that avoiding redundancy and clutter are a good idea, but you
cannot say that the IE has such limited space that this is the reason.
Look, you have assigned fewer than 375 out of 32767 identifiers. If it
fills up in the next 20 years I will buy you a bottle.
2012-09-27
06 Adrian Farrel Ballot comment and discuss text updated for Adrian Farrel
2012-09-27
06 Gonzalo Camarillo [Ballot Position Update] New position, No Objection, has been recorded for Gonzalo Camarillo
2012-09-27
06 Adrian Farrel
[Ballot discuss]
Updated first point of the Discuss after conversation with Ron Bonica.

I found rather a number of issues. I have tried to split …
[Ballot discuss]
Updated first point of the Discuss after conversation with Ron Bonica.

I found rather a number of issues. I have tried to split them between
my Discuss and Comment according to their magnitude. Inevitably I will
have got this wrong, so please debate them with me.

---

This document appears to update RFC 5102. That RFC defined
the registry and sets up the guidelines for expert review of
allocation requests.This document is changing those
guidelines.

Not quite sure how that will fit in when you come to publish
I-D.ietf-ipfix-information-model-rfc5102bis, and I know that this I-D
has a normative reference to that I-D so they will pop out together.

A way to fix this would be to yank all of the IANA stuff and put it
in 5102bis. Then this document simply instruct the IE-doctors to
ensure the IANA allocation requests match the rules.

---

Section 4

  o  The Information Element MUST be unique within the registry.  Its
      description MUST represent a substantially different meaning from
      that of any existing Information Element.  A proposed Information
      Element which is a substantial duplicate of an existing
      Information Element is to be represented using the existing
      Information Element.

Surely this is too subjective. What does "substantially different"
actually mean? I tried to rewrite this for you in terms of data type,
units, and range, but I think that is probably only a part of what you
are talking about. For re-use of an existing Information Element you
presumably need those three parameters to be the same, *and* some other
quality has to be the same.

Depending on the description being similar seems really doubtful. Can
you clarify this?

---

Section 4

  o  The Information Element SHOULD contain minimal internal structure;

Do you mean "minimal". I suppose you use this in the meaning "the least
possible".

Given the existence of parallel export and Structured Data, is there any
reason not to interpret this statement as: you must only use a single
Abstract Data Type.

Of course, you may be attempting to also control the definition of new
Abstract Data Types, but if so, you probably ought to call that out.

---

Section 4

  o  The Information Element SHOULD be generally applicable to the
      application at hand, which SHOULD be of general interest to the
      community.

I find this a bit worrying. What are you saying about proposals from
outside the IETF? How is the "general interest to the community" to be
measured? Are the designated experts called upon to call consensus?

---

Section 4.3 defines rules for IANA Allocation of code points. Including
notes on the ranges. Is it your intention that the registry is updated
to point to this document? If so, you should make that statement in the
IANA considerations section.

On the other hand, this seems to be a restatement of what is already in
the registry, so I wonder whether the section can be left out.

---

Doesn't Section 11 give rise to some additional rules that are not
captured in the body of the document and (importantly) not in the
checklists of Section 7?

---

Section 12

Do you need to tell IANA how to populate the Revision and Date fields in
the IE registry for IEs that have already been defined?
2012-09-27
06 Adrian Farrel Ballot discuss text updated for Adrian Farrel
2012-09-27
06 Ralph Droms [Ballot Position Update] New position, No Objection, has been recorded for Ralph Droms
2012-09-26
06 Wesley Eddy [Ballot Position Update] New position, No Objection, has been recorded for Wesley Eddy
2012-09-26
06 Pete Resnick
[Ballot comment]
The abstract tries to jam everything into a single convoluted sentence, and I think it ends up being completely unclear. I make a …
[Ballot comment]
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.
2012-09-26
06 Pete Resnick [Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick
2012-09-26
06 Adrian Farrel
[Ballot discuss]
I found rather a number of issues. I have tried to split them between
my Discuss and Comment according to their magnitude. Inevitably …
[Ballot discuss]
I found rather a number of issues. I have tried to split them between
my Discuss and Comment according to their magnitude. Inevitably I will
have got this wrong, so please debate them with me.

---

This document clearly updates RFC 5102. That RFC defined the registry
and set up the guidelines for expert review of allocation requests.
This document is changing those guidelines.

Not quite sure how that will fit in when you come to publish
I-D.ietf-ipfix-information-model-rfc5102bis, and I know that this I-D
has a normative reference to that I-D so they will pop out together.

---

Section 4

  o  The Information Element MUST be unique within the registry.  Its
      description MUST represent a substantially different meaning from
      that of any existing Information Element.  A proposed Information
      Element which is a substantial duplicate of an existing
      Information Element is to be represented using the existing
      Information Element.

Surely this is too subjective. What does "substantially different"
actually mean? I tried to rewrite this for you in terms of data type,
units, and range, but I think that is probably only a part of what you
are talking about. For re-use of an existing Information Element you
presumably need those three parameters to be the same, *and* some other
quality has to be the same.

Depending on the description being similar seems really doubtful. Can
you clarify this?

---

Section 4

  o  The Information Element SHOULD contain minimal internal structure;

Do you mean "minimal". I suppose you use this in the meaning "the least
possible".

Given the existence of parallel export and Structured Data, is there any
reason not to interpret this statement as: you must only use a single
Abstract Data Type.

Of course, you may be attempting to also control the definition of new
Abstract Data Types, but if so, you probably ought to call that out.

---

Section 4

  o  The Information Element SHOULD be generally applicable to the
      application at hand, which SHOULD be of general interest to the
      community.

I find this a bit worrying. What are you saying about proposals from
outside the IETF? How is the "general interest to the community" to be
measured? Are the designated experts called upon to call consensus?

---

Section 4.3 defines rules for IANA Allocation of code points. Including
notes on the ranges. Is it your intention that the registry is updated
to point to this document? If so, you should make that statement in the
IANA considerations section.

On the other hand, this seems to be a restatement of what is already in
the registry, so I wonder whether the section can be left out.

---

Doesn't Section 11 give rise to some additional rules that are not
captured in the body of the document and (importantly) not in the
checklists of Section 7?

---

Section 12

Do you need to tell IANA how to populate the Revision and Date fields in
the IE registry for IEs that have already been defined?
2012-09-26
06 Adrian Farrel
[Ballot comment]
Just to let the shepherding AD know that it isn't very nice to find:

  Capitalized terms used in this document that are …
[Ballot comment]
Just to let the shepherding AD know that it isn't very nice to find:

  Capitalized terms used in this document that are defined in the
  Terminology section of [I-D.ietf-ipfix-protocol-rfc5101bis] are to be
  interpreted as defined there.

when the referenced I-D is not yet stable enough to receive a
publication request. Nothing the authors can do except realise that any
change to the referenced document may break this document.

---

The use of 2119 language seems entirely inappropriate to me. There is
nothing to be implemented and no bits on the wire. The designated
experts are humans not machines - speak to them in English!

---

Section 3, while providing a useful refresher on IPFIX seems to be out
of scope for the document. It could be entirely removed without harming
the document.

---

Section 4.1

  o  Names of Information Elements SHOULD be descriptive.

Why on earth do you want to allow non-descriptive names?

---

Section 4.2

  Information Elements of type string or octetArray which have length
  constraints (fixed length, minimum and/or maximum length) MUST note
  these constraints in their description.

  The type of an Information Element MUST match the type of the data it
  represents.  More specifically, information that could be represented
  as a string, but which better matches one of the other data types
  (e.g. an integral type for a number or enumerated type, an address
  type for an address) MUST be represented by the best-matching type,
  even if the data was represented using a different type in the
  source.  In other words, an IPFIX application that exports Options
  Template Records mapping IP addresses to additional information about
  each host from an external database MUST use Information Elements of
  an address type to represent the addresses, even if the source
  database represented these as strings.

Do you need to say that strings and octetArrays must not be used to
encode data that would be more properly encoded in other data types
perhaps using multiple information elements with a forward pointer to
Section 4.5?

---

Section 4.3

  In general, when adding newly registered Information Elements to the
  IANA IE registry, IANA SHOULD assign the lowest available Information
  Element identifier (the value column in [iana-ipfix-assignments]) in
  the range 128-32767.

What does "in general" mean and how is IANA to interpret it?

---

Section 4.9

  However, for reasons of history,
  there are several Information Elements within the IANA IE registry
  which do not follow best practices in Information Element design.
  These Information Elements are not necessarily so flawed so as to
  require deprecation, but they should be explicitly ignored when
  looking for guidance as to whether a new Information Element should
  be added.

Now, I know the experts are experts, and it is completely obvious to
them which IEs don't follow best practices, but the poor fool building
a new spec is being asked for a rock. Can you not list the IEs that
should be ignored?

---

Section 6

  Due to the limited number space of Information Elements in the IANA
  IE registry, avoiding redundancy and clutter in the registry is
  important in defining new applications.

Nah!
I agree that avoiding redundancy and clutter are a good idea, but you
cannot say that the IE has such limited space that this is the reason.
Look, you have assigned fewer than 375 out of 32767 identifiers. If it
fills up in the next 20 years I will buy you a bottle.
2012-09-26
06 Adrian Farrel [Ballot Position Update] New position, Discuss, has been recorded for Adrian Farrel
2012-09-26
06 Barry Leiba
[Ballot comment]
The beginning of the document, through the beginning of Section 3 (end of page 5), very strongly smells like an Applicability Statement, which …
[Ballot comment]
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.
2012-09-26
06 Barry Leiba [Ballot Position Update] Position for Barry Leiba has been changed to No Objection from Discuss
2012-09-26
06 Sean Turner [Ballot Position Update] New position, No Objection, has been recorded for Sean Turner
2012-09-26
06 Stewart Bryant [Ballot comment]
Thank you for addressing my concerns.
2012-09-26
06 Stewart Bryant [Ballot Position Update] Position for Stewart Bryant has been changed to Yes from Discuss
2012-09-26
06 Stephen Farrell [Ballot Position Update] Position for Stephen Farrell has been changed to No Objection from Discuss
2012-09-26
06 Brian Trammell New version available: draft-ietf-ipfix-ie-doctors-06.txt
2012-09-26
05 Brian Haberman [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman
2012-09-26
05 Stephen Farrell
[Ballot discuss]

(1) 4.3: Why does a CISCO-specific informational RFC end up
generating a MUST NOT in a BCP with a set of experts for …
[Ballot discuss]

(1) 4.3: Why does a CISCO-specific informational RFC end up
generating a MUST NOT in a BCP with a set of experts for the
vendor-specific protocol whose views are "exempt" from review
by the reviewers for the IETF standards track protocol? I
don't understand why that's appropriate. I would suggest just
deleting the last paragraph of 4.3 entirely. Same for the
last para of 5.2 and the 3rd last in 5.3 and in section 7,
checklist 1, point 8, and section 7, checklist 2, item 10.
In an offlist conversation with Ron we figured the changes
below might suffice - they look good to me but I need to
just check they hits all the bits and make sure they're
clear enough for an editor.

OLD<
  Information Element identifiers in the range 1-127 MUST NOT be
  assigned unless the Information Element is compatible with the
  NetFlow V9 protocol as described in [RFC3954].  Such Information
  Elements may ONLY be requested by a NetFlow v9 expert, to be
  designated by the IESG to consult with IANA on NetFlow v9
  compatibility with IPFIX.  These information elements are exempt from
  IE-DOCTORS review; it is the responsibility of the NetFlow v9 expert
  to ensure that the requested IEs substantially conform to the
  guidelines in this document, with consideration given for already-
  implemented and already-deployed features.

  Information Element identifiers in the range 1-127 MUST NOT be
  assigned. These are used by Netflow V9 [RFC3954], a pre-standard
  version of IPFIX

  Information Elements with identifiers in the range 1-127 are
  compatible with the NetFlow V9 protocol as described in [RFC3954]; to
  maintain this compatibility, all deprecations of such Information
  Elements are subject to additional review by the appointed NetFlow V9
  expert.
OLD>

NEW>

Information Elements with identifiers in the range 1-127 are
  compatible with the NetFlow V9 protocol as described in [RFC3954]; to
  maintain this compatibility, all deprecations of such Information
  Elements are subject to additional review by the appointed NetFlow V9
  expert.

<NEW

(2) 5.2 & 5.3: I hope you've convinced yourself that this set
of rules don't allow the IE-doctors to overrule IETF
consensus, even in an interoperable manner. That's not clear
to me. I think you ought say that explicitly, i.e.  "These
rules do not allow IE-doctors to override or change IETF
consensus" or however you'd rather say that.
2012-09-26
05 Stephen Farrell
[Ballot comment]

- general: are you missing a meta-guideline for experts?
E.g.: "don't add things gratuituously but try get folks to
re-use what's there"

- …
[Ballot comment]

- general: are you missing a meta-guideline for experts?
E.g.: "don't add things gratuituously but try get folks to
re-use what's there"

- 1.2: the "EDITOR's NOTE" should be gone by now I would have
thought. Did that review happen?

- section 4: "MUST be sufficiently unique" is odd 2119
language but since I can understand it fine, that's ok IMO.
Others might not agree. Same goes for a bunch of other uses
of 2119 language in this draft.

- 4.1: Why do you care about camelCase? Seems like a bad MUST
to me, a SHOULD at most, esp. since you do say there can be
exceptions. And is "6" a "letter" or not in this context? How
about Eszett:-)

- 4.9: I love the section title!

- 4.9: The "EDITOR'S NOTE" should be gone already.

- 7: depending on your reaction to the comments above, you
might need to make some change in this section.

- section 10 seems like a protocol spec. Why is it here and
not in a separate document? I think it really ought be.
2012-09-26
05 Stephen Farrell Ballot comment and discuss text updated for Stephen Farrell
2012-09-25
05 Stephen Farrell
[Ballot discuss]


- 4.3: Why does a CISCO-specific informational RFC end up
generating a MUST NOT in a BCP with a set of experts for …
[Ballot discuss]


- 4.3: Why does a CISCO-specific informational RFC end up
generating a MUST NOT in a BCP with a set of experts for the
vendor-specific protocol whose views are "exempt" from review
by the reviewers for the IETF standards track protocol? I
don't understand why that's appropriate. I would suggest just
deleting the last paragraph of 4.3 entirely. Same for the
last para of 5.2 and the 3rd last in 5.3 and in section 7,
checklist 1, point 8, and section 7, checklist 2, item 10.

- 5.2 & 5.3: I hope you've convinced yourself that this set
of rules don't allow the IE-doctors to overrule IETF
consensus, even in an interoperable manner. That's not clear
to me. I think you ought say that explicitly, i.e.  "These
rules do not allow IE-doctors to override or change IETF
consensus" or however you'd rather say that.
2012-09-25
05 Stephen Farrell
[Ballot comment]


- general: are you missing a meta-guideline for experts?
E.g.: "don't add things gratuituously but try get folks to
re-use what's there"

- …
[Ballot comment]


- general: are you missing a meta-guideline for experts?
E.g.: "don't add things gratuituously but try get folks to
re-use what's there"

- 1.2: the "EDITOR's NOTE" should be gone by now I would have
thought. Did that review happen?

- section 4: "MUST be sufficiently unique" is odd 2119
language but since I can understand it fine, that's ok IMO.
Others might not agree. Same goes for a bunch of other uses
of 2119 language in this draft.

- 4.1: Why do you care about camelCase? Seems like a bad MUST
to me, a SHOULD at most, esp. since you do say there can be
exceptions. And is "6" a "letter" or not in this context? How
about Eszett:-)

- 4.9: I love the section title!

- 4.9: The "EDITOR'S NOTE" should be gone already.

- 7: depending on your reaction to the comments above, you
might need to make some change in this section.

- section 10 seems like a protocol spec. Why is it here and
not in a separate document? I think it really ought be.
2012-09-25
05 Stephen Farrell [Ballot Position Update] New position, Discuss, has been recorded for Stephen Farrell
2012-09-25
05 Robert Sparks [Ballot Position Update] New position, No Objection, has been recorded for Robert Sparks
2012-09-25
05 Stewart Bryant
[Ballot discuss]
I am a little concerned about the advice in Section 4 bullet 2 as being interpreted closer to a MUST than a MAY. …
[Ballot discuss]
I am a little concerned about the advice in Section 4 bullet 2 as being interpreted closer to a MUST than a MAY.

Surely the important think is that the Reviewer consider this in the context of the application and then does the right thing for the application and its context.

I think that it would be useful if advice to that effect was more prominent in the document that is currently the case. As I read the advice it is very much written from the traditional use/flow reporting perspective, rather than from the point of view of a general use push protocol, and this conservative approach I think limits the potential of the IPFIX protocol.
2012-09-25
05 Stewart Bryant [Ballot Position Update] New position, Discuss, has been recorded for Stewart Bryant
2012-09-25
05 Martin Stiemerling [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling
2012-09-24
05 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded for Russ Housley
2012-09-23
05 Barry Leiba
[Ballot discuss]
I have to finish reviewing this document, but I wanted to get this in as early as possible, so it can be responded …
[Ballot discuss]
I have to finish reviewing this document, but I wanted to get this in as early as possible, so it can be responded to.

This document, at least through the beginning of Section 3, very strongly smells like an Applicability Statement, which should be on Standards Track.  RFC 5472 (which is actually *titled* "Applicability Statement") was published as Informational, and should also have been Standards Track as the Applicability Statement that it is, but that's history now.  We can, though, do this one right.  I believe that the information given here (and in 5472) is information that should be considered to define standards for network operation & management, and that should be progressed along the Standards Track as it gets deployment and use, and matures.

The shepherd writeup doesn't help: it just says that this is a BCP, which I can see from the header, and says nothing about *why* BCP is appropriate, and nothing about the working group's discussion on the matter.
2012-09-23
05 Barry Leiba [Ballot Position Update] New position, Discuss, has been recorded for Barry Leiba
2012-09-20
05 Jean Mahoney Request for Telechat review by GENART is assigned to Roni Even
2012-09-20
05 Jean Mahoney Request for Telechat review by GENART is assigned to Roni Even
2012-09-20
05 Ron Bonica Placed on agenda for telechat - 2012-09-27
2012-09-20
05 Ron Bonica State changed to IESG Evaluation from Waiting for AD Go-Ahead
2012-09-19
05 Benoît Claise New version available: draft-ietf-ipfix-ie-doctors-05.txt
2012-08-31
04 Brian Trammell New version available: draft-ietf-ipfix-ie-doctors-04.txt
2012-07-23
03 Benoît Claise [Ballot Position Update] Position for Benoit Claise has been changed to Recuse from Abstain
2012-07-17
03 (System) State changed to Waiting for AD Go-Ahead from In Last Call
2012-07-16
03 Pearl Liang
IANA has reviewed draft-ietf-ipfix-ie-doctors-03 and has the following comments:

IANA understands that, upon approval of this document, there are three IANA
actions which must be …
IANA has reviewed draft-ietf-ipfix-ie-doctors-03 and has the following comments:

IANA understands that, upon approval of this document, there are three IANA
actions which must be completed.

First, IANA has worked with the authors to understand and implement the updated
expert review process for the IPFIX Information Element registry and its related
subregistries. Upon approval of this document, IANA will work with the IESG and
the authors to implement the process outlined in section 5.1, 5.2 and 5.3 of the
current draft.

Second, the IPFIX Information Elements registry located at:

http://www.iana.org/assignments/ipfix/ipfix.xml

will be modified to add three columns. Those new columns are specified in
section 12 of the current draft and are:

Revision: a serial revision number for each Information Element, beginning at
0 for all presently existing and newly created Information Elements.

Date: the date at which the Information Element was created or last modified.

Enterprise-specific reference: for Information Elements which where deployed
as enterprise-specific Information Elements for experimentation and testing, and
subsequently registered in the IANA registry, specifies the private enterprise
number (PEN)/IE number pair(s) of the equivalent experimental Information
Element(s).

Third, IANA understands that this document updates the procedure for IPFIX
Information Element assignment and thus in the IANA Matrix at:

http://www.iana.org/protocols/

and in the IPFIX Information Element registry located at:

http://www.iana.org/assignments/ipfix/ipfix.xml

the references to RFC 5102 will be updated to [RFC-to-be].

IANA understands these three actions are the only ones that need to be completed
upon approval of this document.

Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC.
This message is only to confirm what actions will be performed.
2012-07-15
03 Roni Even Request for Last Call review by GENART Completed. Reviewer: Roni Even.
2012-07-13
03 Samuel Weiler Request for Last Call review by SECDIR Completed. Reviewer: Yoav Nir.
2012-07-11
03 Benoît Claise [Ballot Position Update] New position, Abstain, has been recorded for Benoit Claise
2012-07-11
03 Ron Bonica Ballot has been issued
2012-07-11
03 Ron Bonica [Ballot Position Update] New position, Yes, has been recorded for Ronald Bonica
2012-07-11
03 Ron Bonica Created "Approve" ballot
2012-07-05
03 Samuel Weiler Request for Last Call review by SECDIR is assigned to Yoav Nir
2012-07-05
03 Samuel Weiler Request for Last Call review by SECDIR is assigned to Yoav Nir
2012-07-05
03 Jean Mahoney Request for Last Call review by GENART is assigned to Roni Even
2012-07-05
03 Jean Mahoney Request for Last Call review by GENART is assigned to Roni Even
2012-07-03
03 Amy Vezza
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Guidelines for Authors and Reviewers of …
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Guidelines for Authors and Reviewers of IPFIX Information Elements) to Best Current Practice


The IESG has received a request from the IP Flow Information Export WG
(ipfix) to consider the following document:
- 'Guidelines for Authors and Reviewers of IPFIX Information Elements'
  as Best Current Practice

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2012-07-17. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document provides guidelines for the definition of IPFIX
  Information Elements for addition to the IANA IPFIX Information
  Element registry, in order to extend the applicability of the IPFIX
  protocol to new operations and management areas.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-ipfix-ie-doctors/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-ipfix-ie-doctors/ballot/


No IPR declarations have been submitted directly on this I-D.


2012-07-03
03 Amy Vezza State changed to In Last Call from Last Call Requested
2012-07-03
03 Ron Bonica Last call was requested
2012-07-03
03 Ron Bonica Last call announcement was generated
2012-07-03
03 Ron Bonica Ballot approval text was generated
2012-07-03
03 Ron Bonica State changed to Last Call Requested from AD Evaluation
2012-07-03
03 Ron Bonica State changed to AD Evaluation from Publication Requested
2012-07-03
03 Ron Bonica Ballot writeup was changed
2012-07-03
03 Ron Bonica Ballot writeup was generated
2012-06-25
03 Cindy Morgan
(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? Why
is this the proper type of RFC? …
(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? Why
is this the proper type of RFC? Is this type of RFC indicated in the
title page header?

The requested type is BCP as stated in the title page header.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

This document provides guidelines for the definition of IPFIX
Information Elements for addition to the IANA IPFIX Information
Element registry, in order to extend the applicability of the IPFIX
protocol to new operations and management areas.


Working Group Summary

This draft has been discussed already at WG sessions and on the
mailing list for along time before adopting it as WG work item.
There was strong consensus on the need for such a document and
on the general content. Details has been discussed extensively.
WGLC was conducted in February 2012. Raise issues in the LC
Phase were discussed and fixed.

Document Quality

This BCP for IPFIX IE doctors summarizes experiences gained in
several years of dealing with new proposals for IEs.

Personnel

By default, Benoit Claise would be the responsible area director.
But since Benoit Claise is co-author of the draft, the responsible
area director is Ron Bonica.
Document shepherd is Juergen Quittek.


(3) Briefly describe the review of this document that was performed by
the Document Shepherd. If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

The document shepherd has reviewed the draft and is fully convinced
that it is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

No.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

There are no such issues.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yes.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
Disclosures.

No.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

The WG as a whole understand and agree with it.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
Thorough.

The document uses 'NOT RECOMMENDED' as an RFC 2119 keyword,
but does not include the phrase in its RFC 2119 key words list.
This can be fixed after IETF last call.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

No further formal review required.

(13) Have all references within this document been identified as
either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

Yes. There are two:
- draft-ietf-ipfix-protocol-rfc5101bis-01
- draft-ietf-ipfix-information-model-rfc5102bis-01
Both are on the IPFIX WG charter and currently progressing in the WG.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in the
Last Call procedure.

No.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

No.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

The draft defines a process for IANA and extends an IANA registry.
Both issues are well documented in the IANA considerations section.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

There are no new registries that require expert review requested by
this draft.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.


None to be done.
2012-06-25
03 Cindy Morgan Note added 'Juergen Quittek (Quittek@neclab.eu) is the document shepherd.'
2012-06-25
03 Cindy Morgan Intended Status changed to Best Current Practice
2012-06-25
03 Cindy Morgan IESG process started in state Publication Requested
2012-06-25
03 (System) Earlier history may be found in the Comment Log for draft-trammell-ipfix-ie-doctors
2012-06-11
03 Brian Trammell New version available: draft-ietf-ipfix-ie-doctors-03.txt
2012-03-07
02 Brian Trammell New version available: draft-ietf-ipfix-ie-doctors-02.txt
2012-02-10
01 (System) New version available: draft-ietf-ipfix-ie-doctors-01.txt
2011-11-21
00 (System) New version available: draft-ietf-ipfix-ie-doctors-00.txt