Information Model for IP Flow Information Export (IPFIX)
draft-ietf-ipfix-information-model-rfc5102bis-10

[Ballot discuss]
This Discuss issue should be easy to resolve.

This document does not appear to include any instructions about
updating the "Requester" column of
www.iana.org/assignments/ipfix/ipfix.xml to correct references to the
obsoleted RFC 5102.

Has there been a review of relevant documents and other sources of
information to identify and correct similar references to RFC 5102?  I
can't think of any myself.

[Ballot comment]
To follow up on Barry's point:

3.1.14.  string

  The type "string" represents a finite-length string of valid
  characters from the Unicode character encoding set
  [ISO.10646-1.1993].  Unicode allows for ASCII [ISO.646.1991] and many
  other international character sets to be used.

I understand that this was from 5102, but it is pretty poorly written. Since it is a carry over, I certainly won't insist on changing it, but might I suggest:

  The type "string" represents a finite-length string of valid
  characters from the Unicode coded character set
  [ISO.10646-1.1993].  Unicode incorporates ASCII [ISO.646.1991] and the
  characters of many other international character sets.

I agree with Barry that there are better references.

IANA has reviewed draft-ietf-ipfix-information-model-rfc5102bis-09 and has the following comments:

IANA has questions about the IANA actions.

IANA understands that, Upon approval of this document, there are eight
actions which IANA must complete.

First, in the IPFIX Information Element Registry in the IP Flow Information Export (IPFIX) Entities located at:

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

new columns will be added for revision and date as requested in section 7.1 (and specified in section 2.1) of the current document. For all existing elements in the registry, the version will be set to 0 and the date will be set to the publication date of [ RFC-to-be ].

Please make the NOTEs for the new columns in section 7.1 action items,
rather than "NOTE".

Second, also in the IPFIX Information Element Registry in the IP Flow Information Export (IPFIX) Entities located at:

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

the reference for the IPFIX Information Element Registry will be changed to [ RFC-to-be ].

Please make the NOTE to update the Reference in section 7.1 an action
item, rather than "NOTE".

Third, also in the IPFIX Information Element Registry in the IP Flow Information Export (IPFIX) Entities located at:

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

the Name of all existing Reserved Information Elements with identifier 127 or less will be set to "Assigned for NetFlow v9 compatibility", and the Reference to
[RFC3954].

Please make the NOTE about identifier 127 in section 7.1 an action item,
rather than "NOTE".

Fourth, in the IPFIX MPLS label type (Value 46) subregistry of the IP Flow Information Export (IPFIX) Entities located at:

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

the reference for the subregistry will be changed to refer to [ RFC-to-be ].

Please make the NOTE to update the Reference in section 7.2 an action
item, rather than "NOTE".

Fifth, in the IANA maintained registry of XML schema located at:

http://www.iana.org/assignments/xml-registry/schema.html

the reference for the IPFIX schema will be changed to [ RFC-to-be ].

Sixth, in the IANA maintained registry of XML namespaces located at:

http://www.iana.org/assignments/xml-registry/ns.html

the reference for the IPFIX-INFO namespace will be changed to [ RFC-to-be ].

Please make the NOTE in section 7.3 an action item, rather than a "NOTE".

Seventh, IANA notes the extensive instructions for maintenance of the IPFIX Information Element Registry in the IP Flow Information Export (IPFIX) Entities located at:

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

Rather than repeat those instructions, IANA wilL work with the authors to ensure that the required resources for maintenance are provided and that maintenance information for the IPFIX Information Element Registry is properly conveyed in the registry itself.

Eight, we understand that IANA needs to create an IE-doctors mailing list, no address specified, in order to forward requests to the registry experts.

QUESTION: The standard method of handling requests is send them to the expert(s) from IANA's ticketing system. When there is more than one expert considering a request, the first expert to answer will typically reply to all the reviewers IANA sent the request to as well as IANA's ticketing system. Can you confirm that you prefer to have these conversations over a dedicated mailing list?

Please note that the IANA Considerations section of this document includes a great deal of information and advice that is not meant for IANA. In the future, please consider restricting this section to brief, explicit instructions that tell us exactly what you want IANA to do, even if this requires mentioning registrations explained elsewhere in the document.

IANA understands that these actions are the only ones that are required
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.

[Ballot comment]
Thank you for the inclusion of Section 1.1 which was a great help in
reviewing this document.

It seems that the level of change from 5102 is relatively small so it
might be more appropriate to list the authors of 5102 as Contributors
to this document.

---

I am not really sure about the 2119 usage, but I have no energy to
debate it. However, you might try for some consistency :-)
For example,
                                               
  range - Some Information Elements may only be able to take on a
      restricted set of values that can be expressed as a range (e.g., 0
      through 511 inclusive).  If this is the case, the valid inclusive
      range should be specified; values for this Information Element
      outside the range are invalid and MUST NOT be exported.

Is that should or SHOULD?

---

Sections 3.1.17 and 3.1.18 refer to formats. Is that appropriate in an
information model?

---

Format of Sections 7, 8, and 9 looks broken.

---

In Section 9

  This document does not specify any Information Element carrying keying
  material.  If future extensions will do so, then appropriate
  precautions need to be taken for properly protecting such sensitive
  information.

I am not sure this is appropriate. This is an Information model, and so
defining elements for keys would not have security consequence. The use
of the information elements in a data model would have security
consequences, but that is a different issue.

[Ballot discuss]
The text in 7.3 about "tools that can automatically adapt to extensions" could be read by an implementer to imply that their implementation should be reading this registry without an administrator telling them to do so - staying "up to date" all the time. Do you want implementations automatically polling this registry on a regular interval or trying to subscribe to changes? (if so, the draft should discuss the expected load on IANA.) Or was it the intent just to point out that this makes updating IPFIX-aware tools easier when the administrator wants to update the tool?

[Ballot comment]
Calling this registry the canonical reference says the registry wins whenever there is a conflict with the RFCs for those elements that were placed (and will be maintained by) Standards action. If a mistake is made, certainly the registry will change to match the RFC, not vice-versa, so for those elements, the RFCs are actually canonical. Would it be better to say complete reference?

The changes to the definitions of timestamps were more than clarifications - you removed the ability to use different epochs. Shouldn't the document should talk about backwards compatibility? Trying to read stored data that used a different epoch would produce surprising results with an implementation following the definitions in this document. Explicitly noting that aspect of the change seems prudent even if there are no known uses of the capability that was available per the previous RFC.

The word "integral" was dropped from the definitions of some of the counters (but not from other types), and nothing was left to constrain the definition to representing whole numbers. Would a fractional count ever be OK?

[Ballot comment]
Update:
The authors have proposed a new paragraph that notes that encodings are specified in 5101(bis), and I'm happy with that.

The authors have also proposed a rewrite of the abstract, which I like.

I suggest that the ISO 10646 reference be replaced with a newer one, thus:

NEW
  [ISO.10646]
              International Organization for Standardization,
              "Information technology — Universal Coded Character
              Set (UCS)", ISO/IEC 10646:2012(E), June 2012.

A URL where that can be found is here:
http://standards.iso.org/ittf/PubliclyAvailableStandards/c056921_ISO_IEC_10646_2012.zip

Finally, I wonder why the document uses an ISO reference for ASCII, rather than ANSI X3.4, or even RFC 20.  The authors may check on this, but this is non-blocking.

Thanks for addressing my concerns so quickly!

[Ballot comment]
As an author of RFC5102 and a major contributor to the technical text that has been propagated into this version, I am unsure of the ethics of taking a position.

I will however make one note that I think that the shepherding AD should consider. The proposal here seem to be to change the IANA references from RFC5102 to RFC5102bis. That is fine with the information elements re-specified in this RFC2b, but that removes the traceability of in use information elements that were originally specified in RFC5102, but not carried  forward into the bis RFC.

[Ballot discuss]
I have no objection to this document, and we should be able to quickly clear up a couple of easy issues with Unicode and references:

-- Section 3.1.14 --
I realize that this is unchanged from 5102, and that it didn't seem to cause problems there, but it looks like "string" is underspecified: it says what *characters* are valid, but doesn't specify the encoding to use.  Is it meant to be UTF-8?  It doesn't say.  It could be UTF-16.  Or UCS-2, for that matter, given the age of your reference (see below).

I initially thought it was OK, because this is an abstract type, and maybe it's defined elsewhere.  But I picked an item defined in the registry as "string" (96, applicationName) and checked the reference for that (RFC 6759, a nice, recent one), and I see nothing there that specifies the encoding either.

What encoding is actually used, and where is that specified unambiguously?

-- References --

  The process for modifying [IPFIX-IANA] has been improved, and is
  now described in [IPFIX-IE-DOCTORS]

Given that a substantive part of RFC 5102 is now in the IE-DOCTORS doc, I can't understand why that's an informative reference here.  Why should it not be normative?

And do you really mean to cite the 1993 version of ISO 10646-1, rather than a more recent one (like maybe 2012)?  (And for that matter (this part is non-blocking), why use an ISO reference for ASCII, rather than ANSI X3.4, or even RFC 20?)

[Ballot comment]
The Abstract confuses me, and the Introduction only helps a little: it says that "this document provides an overview of the information model" for IPFIX.  Given that, one wonders about Standards Track, but then, on reading the document, it's clear that the primary purpose of this document is to specify things, not to "give an overview".  I think someone looking at abstracts to decide what to read might skip this, seeing that it's "only an overview."  I urge you to find another way to describe what this document is and does.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Information Model for IP Flow Information eXport (IPFIX)) to Proposed Standard


The IESG has received a request from the IP Flow Information Export WG
(ipfix) to consider the following document:
- 'Information Model for IP Flow Information eXport (IPFIX)'
  as Proposed
Standard

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 2013-01-23. 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 an overview of the information model for the IP
Flow Information eXport (IPFIX) protocol, as defined in the IANA IPFIX
Information Element Registry. It is used by the IPFIX Protocol for
encoding measured traffic information and information related to the
traffic Observation Point, the traffic Metering Process, and the
Exporting Process. Although developed for the IPFIX Protocol, the model
is defined in an open way that easily allows using it in other
protocols, interfaces, and applications. This document obsoletes RFC
5102.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-ipfix-information-model-rfc5102bis/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-ipfix-information-model-rfc5102bis/ballot/


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

(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?

  Proposed Standard. The header indicates: "Category: Standards Track".
  It is appropriate.  The RFC obsoletes standards track RFC 5202.
  It defines the standard for specifying and registering information
  Elements for the IPFIX protocol.

(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 an overview of the information model for the IP
  Flow Information eXport (IPFIX) protocol, as defined in the IANA IPFIX
  Information Element Registry. It is used by the IPFIX Protocol for
  encoding measured traffic information and information related to the
  traffic Observation Point, the traffic Metering Process, and the
  Exporting Process. Although developed for the IPFIX Protocol, the model
  is defined in an open way that easily allows using it in other
  protocols, interfaces, and applications. This document obsoletes RFC
  5102.

Working Group Summary:

  The documents has been significantly changed in content compared to
  RFC 5202.  The main reason for the change is the existence of an IANA
  registry for IPFIX information elements. This change was fully aggreed
  on in WG discussions.

Document Quality:

  This is an update of RFC 5102 based on a lot of practica experiences
  with specifying registering and implementing IPFIX information elements.
  Changes compared to RFC 5102 result from these experiences.

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

  Juergen Quittek is the document shepherd. He has reviewed it personally
  and believes that this version is ready for forwarding to the IESG
  for publication.

(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?

  The document had multiple individual reviews from key WG members
  during WG last call.  Several comments were made and have been
  addressed when updating the document after the reviews.The
  shepherd has no concern about the depth or breadth of the reviews.

(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 understands and agrees 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.

  There are no nits.  The only issue is that references to work in
  progress need to be updated.  These may create a MISSREF during
  RFC-Editor processing and will eventually be resolved as refernces
  to RFCs.
 
(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 except for a thorough review
  by IANA which will be conducted anyway.

(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 references to draft-ietf-ipfix-protocol-rfc5101bis
  and draft-ietf-ipfix-ie-doctors-07.  Both documents are progressed
  by the IPFIX working group and will be published before or together
  with this document.

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

  RFC 5102 will be obsoleted by this document.  This is explicitly
  mentioned in the abstract and introduction.

(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 IANA considerations are of particular importance for this
  documents, because one of its main subjects is the registration
  of IPFIX information elements at IANA.  Consequently, the IANA
  considerations sections has been checked thoroughly by WG and
  shepherd.
 
(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 IANA registries requested by this document.  It
  rather updates the descriptions of existing ones.

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