Exporting Type Information for IP Flow Information Export (IPFIX) Information Elements
draft-ietf-ipfix-exporting-type-05

[Ballot discuss]
[Updated as per revision -04]

All my previous issues were addressed. Here is a new one that results from a change in -04, that tried to address my earlier DISCUSS:

3.2.  informationElementDescription

[...]

      Language tags SHOULD be kept as simple as
      possible; it is NOT RECOMMENDED for an Exporting Process to export
      a language tag with any subtags other than the primary language
      subtag.

I think this text oversimplifies language tag matching rules and might
be interpreted as contradicting them. I suggest deleting this sentence.

[Ballot discuss]
Updated as per revision -04:

3.2.  informationElementDescription

[...]

      Language tags SHOULD be kept as simple as
      possible; it is NOT RECOMMENDED for an Exporting Process to export
      a language tag with any subtags other than the primary language
      subtag.

I think this text oversimplifies language tag matching and might
be interpreted as contradicting them.
I suggest deleting this sentence.

[Ballot discuss]
3.2.  informationElementDescription

  Description:  A string containing a human-readable description of an
      Information Element.

The document needs to say that the description is in Unicode, encoded
as UTF-8 [RFC3629]. (This is already mentioned in passing in the Security Considetations section.)
A normative reference to RFC 3629 needs to be added.

Moreover, BCP 18 (RFC 2277), section 4.2 says:

  Protocols that transfer text MUST provide for carrying information
  about the language of that text.

[...]

  Note that this does NOT mean that such information must always be
  present; the requirement is that if the sender of information wishes
  to send information about the language of a text, the protocol
  provides a well-defined way to carry this information.

I think this clearly applies in this case.

See last paragraph of Section 3.2 in RFC 5466 for an example text for addressing this issue.

(Note: I am agreeing with Lisa that that is not the only way to address
this issue. Most of her other suggestions are acceptable to me.
I am disagreeing with Lisa about the idea of late binding - I think this document is not restricted in use to one domain/organization where the language of text is known and fixes.)

      See the Security Considerations section for
      notes on string handling for Information Element type records.


3.3.  informationElementName

  Description:  A string containing the name of an Information
      Element.

Character set and encoding should be specified here.
Comments mentioned above for section 3.2 are likely to apply here as well.

      See the Security Considerations section for notes on
      string handling for Information Element type records.

[Ballot discuss]
3.2.  informationElementDescription

  Description:  A string containing a human-readable description of an
      Information Element.

The document needs to say that the description is in Unicode, encoded
as UTF-8 [RFC3629]. (This is already mentioned in passing in the Security Considetations section.)
A normative reference to RFC 3629 needs to be added.

Moreover, BCP 18 (RFC 2277), section 4.2 says:

  Protocols that transfer text MUST provide for carrying information
  about the language of that text.

[...]

  Note that this does NOT mean that such information must always be
  present; the requirement is that if the sender of information wishes
  to send information about the language of a text, the protocol
  provides a well-defined way to carry this information.

I think this clearly applies in this case.

See last paragraph of Section 3.2 in RFC 5466 for an example text for addressing this issue.

(Note: I am agreeing with Lisa that that is not the only way to address
this issue.)

      See the Security Considerations section for
      notes on string handling for Information Element type records.


3.3.  informationElementName

  Description:  A string containing the name of an Information
      Element.

Character set and encoding should be specified here.
Comments mentioned above for section 3.2 are likely to apply here as well.

      See the Security Considerations section for notes on
      string handling for Information Element type records.

[Ballot comment]
The following three issues were raised by OPS-DIR member Margaret Wassermann. They should be addressed before the publication of the document.

ISSUE #1:  Security Requirements

This document does not seem to be consistent with its own stated security requirements, nor does it specify any interoperable security mechanisms.  In particular, sections 5.6 of the document says:
"5.6. Creator Authentication and Confidentiality "Archival storage of flow data may also require assurance that no unauthorized entity can read or modify the stored data. Asymmetric- key cryptography can be applied to this problem, by signing flow data with the private key of the creator, and encrypting it with the public keys of those authorized to read it. The ideal flow storage format will support the encryption and signing of flow data. As with error correction, this problem has been addressed well at a layer below that addressed by this document. Instead of specifying a particular choice of encryption technology, we can leverage the fact Trammell, et al. 
Expires April 27, 2009 [Page 12]? Internet-Draft IPFIX Files October 20
08 that existing cryptographic technologies work quite well on data stored in files to meet this requirement. Beyond support for the use of TLS for transport over TCP or DTLS for transport over SCTP or UDP, both of which provide transient authentication and confidentiality, the IPFIX protocol does not support this requirement directly. It is assumed that this requirement will be met externally."
I agree with this section, but I cannot find any place in the document where it describes what type of file signing technology should be implemented in File Readers and Writers, what the certificates would look like and/or how they would be bound to the file data.  It also doesn't indicate what encryption technologies should be used by a File Writer to encrypt the file, what elements should/shouldn't be encrypted or how a File Reader would determine what type of decryption to perform.  Without including this information, the document is, essentially, suggesting (or nearly mandating) the implementation of non-interoperable security mechanisms.
ISSUE #2:  Option Scoping
There are options defined that are meant to apply to "the the whole IPFIX Transport Session (i.e., the IPFIX File in the common case)", such as the Export Session Details Option.  However, the document also indicates that the IPFIX file format is intended to support the free concatenation and splitting of IPFIX files at IPFIX Message boundaries.  Is it expected that session-scoped options will appear in all of the messages to which they apply?  If not, how would the session boundaries be determined?  I see that there are min and max export times in the session scoped options, but I don't see anything that prohibits (or even warns against) concatenating IPFIX sessions with overlapping times.  There is some discussion of this topic in section 7.1, where it is stated that File Readers may treat multiple files as a single Transport Session, but that they will not treat a single file as representing multiple Transport Sessions.  However, that doesn't seem to be consistent with the "free manipulability of IPFIX Files through concatenation, appending, and splitting (on IPFIX Message boundaries)" described in section 3.
ISSUE #3:  Data Compression
This issues is similar to the security issue described in ISSUE #1 
above.  The document indicates that data compression is desirable. 
Section 9.1 talks in details about issues with data compression and suggests that block compression be used.  However, the document does not mandate the implementation of any specific compression algorithm, nor does it indicate how a File Reader would determine that a file had been compressed and/or what type of compression was used.  Without this information, the document is suggesting the implementation of a non-interoperable compression mechanism.

[Ballot comment]
The following three issues were raised by OPS-DIR member Margaret Wassermann:

ISSUE #1:  Security Requirements

This document does not seem to be consistent with its own stated security requirements, nor does it specify any interoperable security mechanisms.  In particular, sections 5.6 of the document says:
"5.6. Creator Authentication and Confidentiality "Archival storage of flow data may also require assurance that no unauthorized entity can read or modify the stored data. Asymmetric- key cryptography can be applied to this problem, by signing flow data with the private key of the creator, and encrypting it with the public keys of those authorized to read it. The ideal flow storage format will support the encryption and signing of flow data. As with error correction, this problem has been addressed well at a layer below that addressed by this document. Instead of specifying a particular choice of encryption technology, we can leverage the fact Trammell, et al. 
Expires April 27, 2009 [Page 12]? Internet-Draft IPFIX Files October 20
08 that existing cryptographic technologies work quite well on data stored in files to meet this requirement. Beyond support for the use of TLS for transport over TCP or DTLS for transport over SCTP or UDP, both of which provide transient authentication and confidentiality, the IPFIX protocol does not support this requirement directly. It is assumed that this requirement will be met externally."
I agree with this section, but I cannot find any place in the document where it describes what type of file signing technology should be implemented in File Readers and Writers, what the certificates would look like and/or how they would be bound to the file data.  It also doesn't indicate what encryption technologies should be used by a File Writer to encrypt the file, what elements should/shouldn't be encrypted or how a File Reader would determine what type of decryption to perform.  Without including this information, the document is, essentially, suggesting (or nearly mandating) the implementation of non-interoperable security mechanisms.
ISSUE #2:  Option Scoping
There are options defined that are meant to apply to "the the whole IPFIX Transport Session (i.e., the IPFIX File in the common case)", such as the Export Session Details Option.  However, the document also indicates that the IPFIX file format is intended to support the free concatenation and splitting of IPFIX files at IPFIX Message boundaries.  Is it expected that session-scoped options will appear in all of the messages to which they apply?  If not, how would the session boundaries be determined?  I see that there are min and max export times in the session scoped options, but I don't see anything that prohibits (or even warns against) concatenating IPFIX sessions with overlapping times.  There is some discussion of this topic in section 7.1, where it is stated that File Readers may treat multiple files as a single Transport Session, but that they will not treat a single file as representing multiple Transport Sessions.  However, that doesn't seem to be consistent with the "free manipulability of IPFIX Files through concatenation, appending, and splitting (on IPFIX Message boundaries)" described in section 3.
ISSUE #3:  Data Compression
This issues is similar to the security issue described in ISSUE #1 
above.  The document indicates that data compression is desirable. 
Section 9.1 talks in details about issues with data compression and suggests that block compression be used.  However, the document does not mandate the implementation of any specific compression algorithm, nor does it indicate how a File Reader would determine that a file had been compressed and/or what type of compression was used.  Without this information, the document is suggesting the implementation of a non-interoperable compression mechanism.

[Ballot comment]
Each element's status in this draft is currently "Proposed" - a value rfc 5102 doesn't allow. I'm guessing the intent on approval is for this to become "current"? If so, an RFC/IANA note might be nice so they don't have to guess too.

[Ballot comment]
The Gen-ART Review by Miguel Garcia on 20 April 2009 provides some
  editorial suggestions.

  Section 1.1, last paragraph. There is an unfinished sentence:

  It draws data type definitions and data type semantics
  definitions from the Information Model; the encodings of these data
  types

  Section 3, last paragraph. There is  an unfinished sentence:

  This Information Element supports
  references only to IANA-defined Information Elements; the
  privateEnterprseNumber Information Element

  A nit revealed by idnits: RFC 2434 has been obsoleted by RFC 5226.

  The draft contains a number of tables. It would be nice to add a
  table number and a caption under each of them, so that the text (or
  text from other drafts and RFC) can safely refer to "Table nn in
  RFC xxxx". This is similar to what the draft does with Figures.

[Ballot discuss]
I support Alexey's DISCUSS.  Language information is needed to know how to display, search on and sort human-readable fields.  However, there may be other ways to get language information in this case, besides tagging each description field, e.g. tagging a document or file or allowing the user to choose a "late binding" of a language (on viewing, rather than on saving the data), provided that all description fields within a file can be treated as the same language.

[Ballot discuss]
This is formality discuss. Easily fixed:

First of all the references to RFC 2434 are in the wrong category. The reference is a normative one, as you can't follow the process definition without understanding what the categories means.

This results in a normative reference to RFC 2434, an obsoleted RFC, replaced by RFC 5226. Please update but watch out for the renaming of some categories for better clarity.

[Ballot comment]
Section 1., paragraph 3:
>    This document proposes a general mechanism to encode the full set of
  s/proposes/defines/

Section 3., paragraph 2:
>    privateEnterprseNumber Information Element
  Nit: s/privateEnterprseNumber/privateEnterpriseNumber/

Section 3.9., paragraph 7:
>    | informationElementID          | The Information Element          |
  Nit: s/informationElementID/informationElementId/

[Ballot discuss]
3.2.  informationElementDescription

  Description:  A string containing a human-readable description of an
      Information Element.

The document needs to say that the description is in Unicode, encoded
as UTF-8 [RFC3629]. (This is already mentioned in passing in the Security Considetations section.)
A normative reference to RFC 3629 needs to be added.

Moreover, BCP 18 (RFC 2277), section 4.2 says:

  Protocols that transfer text MUST provide for carrying information
  about the language of that text.

[...]

  Note that this does NOT mean that such information must always be
  present; the requirement is that if the sender of information wishes
  to send information about the language of a text, the protocol
  provides a well-defined way to carry this information.

I think this clearly applies in this case.

See last paragraph of Section 3.2 in RFC 5466 for an example text for addressing this issue.

      See the Security Considerations section for
      notes on string handling for Information Element type records.


3.3.  informationElementName

  Description:  A string containing the name of an Information
      Element.

Character set and encoding should be specified here.
Comments mentioned above for section 3.2 are likely to apply here as well.

      See the Security Considerations section for notes on
      string handling for Information Element type records.

[Ballot comment]
1.1.  IPFIX Documents Overview

[...]

  It draws data type definitions and data type semantics
  definitions from the Information Model; the encodings of these data
  types

Unfinished sentence.


3.  Type Information Export

[...]

  This Information Element supports
  references only to IANA-defined Information Elements; the
  privateEnterprseNumber Information Element

Unfinished sentence.

In Section 3.1:

      Data Type subregistry.  This subregistry is intended to assign
      numbers for type names, not to provide a mechanism for adding data
      types to the IPFIX Protocol, and as such requires a Standards
      Action [RFC2434] to modify.

RFC 2434 was obsoleted by RFC 5226 (this can be fixed by RFC Editor).


4.  Security Considerations

[...]

  Note that Information Element type records may contain two strings
  describing Information Elements: informationElementName and
  informationElementDescription.  IPFIX strings on the wire are length-
  prefixed and UTF-8 encoded, most often within an IPFIX variable-

A reference to UTF-8 (RFC 3629) would be nice here.

  length Information Element, which mitigates the risk of unterminated-
  string attacks against IPFIX Collecting Processes.  However, care
  should still be taken when handling strings within the type system of
  the Collecting Process.

[Ballot comment]
1.1.  IPFIX Documents Overview

[...]

  It draws data type definitions and data type semantics
  definitions from the Information Model; the encodings of these data
  types

Unfinished sentence.


3.  Type Information Export

[...]

  This Information Element supports
  references only to IANA-defined Information Elements; the
  privateEnterprseNumber Information Element

Unfinished sentence.

In Section 3.1:

      Data Type subregistry.  This subregistry is intended to assign
      numbers for type names, not to provide a mechanism for adding data
      types to the IPFIX Protocol, and as such requires a Standards
      Action [RFC2434] to modify.

RFC 2434 was obsoleted by RFC 5226 (this can be fixed by RFC Editor).


3.2.  informationElementDescription

  Description:  A string containing a human-readable description of an
      Information Element.

The document needs to say that the description is in Unicode, encoded
as UTF-8 [RFC3629].

      See the Security Considerations section for
      notes on string handling for Information Element type records.


3.3.  informationElementName

  Description:  A string containing the name of an Information
      Element.

Character set and encoding should be specified here.

      See the Security Considerations section for notes on
      string handling for Information Element type records.


4.  Security Considerations

[...]

  Note that Information Element type records may contain two strings
  describing Information Elements: informationElementName and
  informationElementDescription.  IPFIX strings on the wire are length-
  prefixed and UTF-8 encoded, most often within an IPFIX variable-

A normative reference to UTF-8 (RFC 3629) is needed here.

  length Information Element, which mitigates the risk of unterminated-
  string attacks against IPFIX Collecting Processes.  However, care
  should still be taken when handling strings within the type system of
  the Collecting Process.

IANA comments:

Note: Expert Reviewer assignment required for Actions 3 and 4.

Action 1:

Upon approval of this document, IANA will make the following
assignments in the "IPFIX Information Elements" registry at
http://www.iana.org/assignments/ipfix/ipfix.xhtml

Value: TBD1
Name: informationElementDataType
Data Type: unsigned8
D.T.Semantics:
Status: Proposed
Description: A description of the abstract data type of an IPFIX
information element. These are taken from the
abstract data types defined in section 3.1 of the
IPFIX Information Model [RFC5102]
Units:
Range:
References: Section 3.1 of the IPFIX Information Model [RFC5102]
Requester: [RFC-ipfix-exporting-type-02]
---------
Value: TBD2
Name: informationElementDescription
Data Type: string
D.T.Semantics:
Status: Proposed
Description: A string containing a human-readable description of an
Information Element.
Units:
Range:
References:
Requester: [RFC-ipfix-exporting-type-02]
---------
Value: TBD3
Name: informationElementName
Data Type: string
D.T.Semantics:
Status: Proposed
Description: A string containing the name of an Information Element.
Units:
Range:
References:
Requester: [RFC-ipfix-exporting-type-02]
---------
Value: TBD4
Name: informationElementRangeBegin
Data Type: unsigned64
D.T.Semantics: quantity
Status: Proposed
Description: Contains the inclusive low end of the range of
acceptable values for an Information Element.
Units:
Range:
References:
Requester: [RFC-ipfix-exporting-type-02]
---------
Value: TBD5
Name: informationElementRangeEnd
Data Type: unsigned64
D.T.Semantics: quantity
Status: Proposed
Description: Contains the inclusive high end of the range of
acceptable values for an Information Element.
Units:
Range:
References:
Requester: [RFC-ipfix-exporting-type-02]
---------
Value: TBD6
Name: informationElementSemantics
Data Type: unsigned8
D.T.Semantics:
Status: Proposed
Description: A description of the semantics of an IPFIX information
element. These are taken from the data type semantics
defined in section 3.2 of the IPFIX Information Model
[RFC5102]; see that section for more information on
the types described below. This field may take the
following values; the special value 0x00 (default) is
used to note that no semantics apply to the field; it
cannot be manipulated by a Collecting Process or File
Reader that does not understand it a priori.
Units:
Range:
References: Section 3.2 of the IPFIX Information Model [RFC5102]
Requester: [RFC-ipfix-exporting-type-02]
---------
Value: TBD7
Name: informationElementUnits
Data Type: unsigned16
D.T.Semantics:
Status: Proposed
Description: A description of the units of an IPFIX Information
Element. These correspond to the units implicitly
defined in the Information Element definitions in
section 5 of the IPFIX Information Model [RFC5102];
see that section for more information on the types
described below. This field may take the following
values; the special value 0x00 (none) is used to note
that the field is unitless.
Units:
Range:
References: Section 5 of the IPFIX Information Model [RFC5102]
Requester: [RFC-ipfix-exporting-type-02]
---------
Value: TBD8
Name: privateEnterpriseNumber
Data Type: unsigned32
D.T.Semantics: identifier
Status: Proposed
Description: A private enterprise number, as assigned by IANA. Within
the context of an Information Element Type record,
this element can be used along with the
informationElementId element to scope properties to a
specific Information Element. If this Information
Element is present, then the Enterprise bit in the
associated informationElementId Information Element
SHOULD be cleared by the Exporting Process and SHOULD
be ignored by the Collecting Process.
Units:
Range:
References: Section 3.4.1 of the IPFIX Protocol [RFC5101]; section
8.2.3 of the PSAMP Information Model [I-D.ietf-psamp-info].
Requester: [RFC-ipfix-exporting-type-02]


Action 2:

Upon approval of this document, IANA will create the following
registry at
http://www.iana.org/assignments/ipfix/ipfix.xhtml

Registry Name: informationElementSemantics Element Data Type
subregistry (type TBD6)
Registration Procedures: Standards Action
Initial contents of this sub-registry will be:

+-------+----------------------+-------------------------------+


| Value | Description | Reference |


+-------+----------------------+-------------------------------+


| 0x00 | octetArray | [RFC-ipfix-exporting-type-02] |
| 0x01 | unsigned8 | [RFC-ipfix-exporting-type-02] |
| 0x02 | unsigned16 | [RFC-ipfix-exporting-type-02] |
| 0x03 | unsigned32 | [RFC-ipfix-exporting-type-02] |
| 0x04 | unsigned64 | [RFC-ipfix-exporting-type-02] |
| 0x05 | signed8 | [RFC-ipfix-exporting-type-02] |
| 0x06 | signed16 | [RFC-ipfix-exporting-type-02] |
| 0x07 | signed32 | [RFC-ipfix-exporting-type-02] |
| 0x08 | signed64 | [RFC-ipfix-exporting-type-02] |
| 0x09 | float32 | [RFC-ipfix-exporting-type-02] |
| 0x0A | float64 | [RFC-ipfix-exporting-type-02] |
| 0x0B | boolean | [RFC-ipfix-exporting-type-02] |
| 0x0C | macAddress | [RFC-ipfix-exporting-type-02] |
| 0x0D | string | [RFC-ipfix-exporting-type-02] |
| 0x0E | dateTimeSeconds | [RFC-ipfix-exporting-type-02] |
| 0x0F | dateTimeMilliseconds | [RFC-ipfix-exporting-type-02] |
| 0x10 | dateTimeMicroseconds | [RFC-ipfix-exporting-type-02] |
| 0x11 | dateTimeNanoseconds | [RFC-ipfix-exporting-type-02] |
| 0x12 | ipv4Address | [RFC-ipfix-exporting-type-02] |
| 0x13 | ipv6Address | [RFC-ipfix-exporting-type-02] |


+-------+----------------------+-------------------------------+

Action 3:

Upon approval of this document, IANA will create the following
registry at
http://www.iana.org/assignments/ipfix/ipfix.xhtml

Registry Name: informationElementSemantics Information Element
Semantics subregistry (type TBD6)
Registration Procedures: Expert Review
Initial contents of this sub-registry will be:

+-------+--------------+-------------------------------+


| Value | Description | Reference |


+-------+--------------+-------------------------------+


| 0x00 | default | [RFC-ipfix-exporting-type-02] |
| 0x01 | quantity | [RFC-ipfix-exporting-type-02] |
| 0x02 | totalCounter | [RFC-ipfix-exporting-type-02] |
| 0x03 | deltaCounter | [RFC-ipfix-exporting-type-02] |
| 0x04 | identifier | [RFC-ipfix-exporting-type-02] |
| 0x05 | flags | [RFC-ipfix-exporting-type-02] |


+-------+--------------+-------------------------------+

Action 4:

Upon approval of this document, IANA will create the following
registry at
http://www.iana.org/assignments/ipfix/ipfix.xhtml

Registry Name: informationElementUnits Information Element Units
subregistry (type TBD7)
Registration Procedures: Expert Review [RFC2434]
Initial contents of this sub-registry will be:

+--------+---------------+------------------------+------------+


| Value | Name | Notes | Reference
|


+--------+---------------+---------------------+---------------+


| 0x0000 | none | |


[RFC-ipfix-exporting-type-02] |


| 0x0001 | bits | |


[RFC-ipfix-exporting-type-02] |


| 0x0002 | octets | |


[RFC-ipfix-exporting-type-02] |


| 0x0003 | packets | |


[RFC-ipfix-exporting-type-02] |


| 0x0004 | flows | |


[RFC-ipfix-exporting-type-02] |


| 0x0005 | seconds | |


[RFC-ipfix-exporting-type-02] |


| 0x0006 | milliseconds | |


[RFC-ipfix-exporting-type-02] |


| 0x0007 | microseconds | |


[RFC-ipfix-exporting-type-02] |


| 0x0008 | nanoseconds | |


[RFC-ipfix-exporting-type-02] |


| 0x0009 | 4-octet words | for IPv4 header length |


[RFC-ipfix-exporting-type-02] |


| 0x000A | messages | for reliability reporting |


[RFC-ipfix-exporting-type-02] |


| 0x000B | hops | for TTL |


[RFC-ipfix-exporting-type-02] |


| 0x000C | entries | for MPLS label stack |


[RFC-ipfix-exporting-type-02] |
+--------+---------------+---------------------------+---------+

We understand the above to be the only IANA Actions for this document.

Document:  draft-ietf-ipfix-exporting-type-02.txt
Title:    Exporting Type Information for IPFIX Information Elements
Editors:  E. Boschi, B. Trammell, L. Mark, T. Zseby
Intended status:  Standards Track

As required by RFC-to-be draft-ietf-proto-wgchair-doc-shepherding,
this is the current template for the Document Shepherd Write-Up.
Changes are expected over time. This version is dated September 17, 2008.

(1.a) Who is the Document Shepherd for this document? Has the
      Document Shepherd personally reviewed this version of the
      document and, in particular, does he or she believe this
      version is ready for forwarding to the IESG for publication?

        Nevil Brownlee.  I have reviewed this draft, I believe
        it is ready to forward to the IESG for publication.

(1.b) Has the document had adequate review both from key WG members
      and from key non-WG members? Does the Document Shepherd have
      any concerns about the depth or breadth of the reviews that
      have been performed?

        This is version 2 of the draft.  It has had extensive review
        by the WG members, and by others from the PSAMP WG.
        These reviews seem sufficiently thorough to me.

(1.c) Does the Document Shepherd have concerns that the document
      needs more review from a particular or broader perspective,
      e.g., security, operational complexity, someone familiar with
      AAA, internationalization or XML?

        No.  The draft is concerned only with specifying a
        way to export data type information about IPFIX Information
        Elements, so that developers of Anaalysis tools for IPFIX
        data will  have an effective way to handle non-standard
        Information Elements.

(1.d) Does the Document Shepherd have any specific concerns or
      issues 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. Has an IPR disclosure related to this document
      been filed? If so, please include a reference to the
      disclosure and summarize the WG discussion and conclusion on
      this issue.

        There are no specific concerns for this document.

(1.e) 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?

        This document has strong consensus within the IPFIX
        Working Group.

(1.f) 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
      entered into the ID Tracker.)

        No.

(1.g) Has the Document Shepherd personally verified that the
      document satisfies all ID nits? (See
      http://www.ietf.org/ID-Checklist.html and
      http://tools.ietf.org/tools/idnits/). Boilerplate checks are
      not enough; this check needs to be thorough. Has the document
      met all formal review criteria it needs to, such as the MIB
      Doctor, media type and URI type reviews?

        idnits 2.10.02 says
          a. Change boilerplate to RFC 4748-style
              16 Dec 08 is the 'required from' date
          b. One unused reference (to RFC5102)
              can be deleted
          c. Outdated reference to psamp-info-08
              This draft is now in RFC Editor queue

        b. and c. can be fixed at Authors 48hr edits,
        a. could also be fixed that way if neccessary.

        The draft is IPFIX-centric, it needs no other formal checks.

(1.h) Has the document split its references into normative and
      informative? 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
      strategy for their completion? Are there normative references
      that are downward references, as described in [RFC3967]? If
      so, list these downward references to support the Area
      Director in the Last Call procedure for them [RFC3967].

        Yes, the references are split.
        No, now that psamp-info is in RFC EDitor queue, all the
          normative reference RFCs do (or will soon) exist.
        No, there are no downward references.

(1.i) Has the Document Shepherd verified that the document IANA
      consideration section exists and is consistent with the body
      of the document? If the document specifies protocol
      extensions, are reservations requested in appropriate IANA
      registries? Are the IANA registries clearly identified? If
      the document creates a new registry, does it define the
      proposed initial contents of the registry and an allocation
      procedure for future registrations? Does it suggest a
      reasonable name for the new registry? See [RFC5226]. If the
      document describes an Expert Review process has Shepherd
      conferred with the Responsible Area Director so that the IESG
      can appoint the needed Expert during the IESG Evaluation?

        The document has an IANA Considerations section that
        clearly explains what IANA should do.  It asks for:
          8 new Information Element numbers in the IPFIX IE Registry
          3 new subregistries for:
            IE Data Types, IE Semantics, IE Units
        This all seems sensible and clear to me.  Also, I have
        discussed it with Michelle Cotton (IANA); she agreed that
        now we have an IPFIX sub-registries entry in the IANA pages,
        there should be no problem adding three more sub-registries.

(1.j) Has the Document Shepherd verified that sections of the
      document that are written in a formal language, such as XML
      code, BNF rules, MIB definitions, etc., validate correctly in
      an automated checker?

        The document has no parts written in a formal language.

(1.k) 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 describes an extension to IPFIX to allow the encoding of
IPFIX Information Model properties within an IPFIX Message stream.
This enables the export of extended type information for enterprise-
specific Information Elements, facilitating interoperability and
reusability among a wide variety of applications and tools.

Working Group Summary

This document started out as a section in the 'IPFIX File' draft;
it was split out because it is useful in other contexts than files
of IPFIX data.  There was considerable mailing-list discussion on
the best ways to do this, it took several months for all the issues
to be resolved.  Discussion ended late in June 08.  The final version
of this draft (July 08) resolved issues raised in discussion.
The WG has reached a clear consensus on this draft.

Document Quality

This document has been reviwed by Paul Aitken and Gerhard Muenz;
their reviews prompted discussion on the list.  It has also been
reviewed by the WG chairs.  It describes a set of new IPFIX Information
Elements, but does not make any changes to the IPFIX protocol.