• Revised I-D Needed - Issue raised by WG
  • Awaiting Expert Review/Resolution of Issues Raised
  • Awaiting External Review/Resolution of Issues Raised
  • Awaiting Merge with Other Document
  • Author or Editor Needed
  • Waiting for Referenced Document
  • Waiting for Referencing Document
  • Revised I-D Needed - Issue raised by WGLC
  • Revised I-D Needed - Issue raised by AD
  • Revised I-D Needed - Issue raised by IESG
  • Doc Shepherd Follow-up Underway
  • Other - see Comment Log

IETF :: ipfix

Current state: WG Document

Viewing the last 20 entries. Show full log.

2013-04-24 07:59 Benoit Claise

Document shepherd changed to Juergen Quittek

2013-04-09 01:34 Benoit Claise

Shepherding AD changed to Joel Jaeggli

2012-12-03 14:36 Cindy Morgan

State changed to RFC Ed Queue from Approved-announcement sent

2012-12-03 10:54 (System)

IANA Action state changed to No IC

2012-12-03 08:25 Amy Vezza

State changed to Approved-announcement sent from Approved-announcement to be sent

2012-12-03 08:25 Amy Vezza

IESG has approved the document

2012-12-03 08:25 Amy Vezza

Closed "Approve" ballot

2012-12-03 08:24 Amy Vezza

Ballot approval text was generated

2012-12-03 08:24 Amy Vezza

Ballot writeup was changed

2012-11-25 04:59 Ron Bonica

State changed to Approved-announcement to be sent from IESG Evaluation::AD Followup

2012-11-24 12:35 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 another document.

2012-11-24 12:35 Adrian Farrel

[Ballot Position Update] Position for Adrian Farrel has been changed to No Objection from Discuss

2012-10-03 07:47 (System)

Sub state has been changed to AD Followup from Revised ID Needed

2012-10-03 07:47 Brian Trammell

New revision available

2012-09-27 09:58 Cindy Morgan

State changed to IESG Evaluation::Revised ID Needed from IESG Evaluation

2012-09-27 09:57 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 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 09:57 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 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 09:57 Adrian Farrel

Ballot comment and discuss text updated for Adrian Farrel

2012-09-27 07:44 Gonzalo Camarillo

[Ballot Position Update] New position, No Objection, has been recorded for Gonzalo Camarillo

2012-09-27 07:21 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 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?

Viewing the last 20 entries. Show full log.