Information Model for IP Flow Information Export
draft-ietf-ipfix-info-15

[Ballot comment]
I reviewed this briefly, rather than in detail, to get this done sooner.  I'm largely trusting prior reviews by Ted and Scott.

When the RFC editor note is applied to the main document, please also apply it to the appendix for consistency.

Also one nit in Appendix B, paragraph 2:

OLD:
  Elements in extensions of the IPFIX information model.  Thi schema
NEW:
  Elements in extensions of the IPFIX information model.  This schema

[Ballot discuss]
This document under describes timestamps as "normalized to the GMT
  time zone" and it specifies the epoch.  However, it does not tell how
  to handle Leap seconds.  This issue was discussed at great length
  during the Last Call for RFC 4049.  To ensure interoperability,
  a similar wording should be used here.  The Leap second handling is
  important regardless of the units (seconds, milliseconds, or
  nanoseconds).

  I agreed to the following revised text:

  3.1.15.  dateTimeSeconds

  The type "dateTimeSeconds" represents a time value in units of
  seconds based on coordinated universal time (UTC).  The choice of an
  epoch, such as, for example, 00:00 UTC, January 1, 1970, is left to
  corresponding encoding specifications for this type, such as, for
  example, the IPFIX protocol specification.  Leap seconds are
  excluded.  Note, that transformation of values might be required
  between different encodings if different epoch values are used.

  3.1.16.  dateTimeMilliseconds

  The type "dateTimeMilliseconds" represents a time value in units of
  milliseconds based on coordinated universal time (UTC).  The choice of
  an epoch, such as, for example, 00:00 UTC, January 1, 1970, is left
  to corresponding encoding specifications for this type, such as, for
  example, the IPFIX protocol specification.  Leap seconds are
  excluded.  Note, that transformation of values might be required
  between different encodings if different epoch values are used.

  3.1.17.  dateTimeMicroseconds

  The type "dateTimeMicroseconds" represents a time value in units of
  microseconds based on coordinated universal time (UTC).  The choice of
  an epoch, such as, for example, 00:00 UTC, January 1, 1970, is left
  to corresponding encoding specifications for this type, such as, for
  example, the IPFIX protocol specification.  Leap seconds are
  excluded.  Note, that transformation of values might be required
  between different encodings if different epoch values are used.

  3.1.18.  dateTimeNanoseconds

  The type "dateTimeNamoseconds" represents a time value in units of
  nanoseconds based on coordinated universal time (UTC).  The choice of
  an epoch, such as, for example, 00:00 UTC, January 1, 1970, is left
  to corresponding encoding specifications for this type, such as, for
  example, the IPFIX protocol specification.  Leap seconds are
  excluded.  Note, that transformation of values might be required
  between different encodings if different epoch values are used.

[Ballot discuss]
This document under describes timestamps as "normalized to the GMT
  time zone" and it specifies the epoch.  However, it does not tell how
  to handle Leap seconds.  This issue was discussed at great length
  during the Last Call for RFC 4049.  To ensure interoperability,
  a similar wording should be used here.  The Leap second handling is
  important regardless of the units (seconds, milliseconds, or
  nanoseconds).

My Discuss was cleared after the following e-mail from the
author:

We posted a new version of the IPFIX info model draft-ietf-ipfix-info-15
addressing your discuss and comment.

> Discuss:
>
>> 5.4.30.  payloadLengthIPv6
>> 5.4.31.  ipPayloadLength
>
> From the descriptions I do not see any
> difference in the value of these where
> IPv6 is used. Why have two variables?
> Note that since both are unsigned32,
> there does not seem to be the same
> backwards compatibility issue as there
> was for ipTotalLength and totalLengthIPv4.

We fixed this.  Now  payloadLengthIPv6 reports
the value of the Payload Length field in the IPv6 header,
while ipPayloadLength reports the actual length of
the payload for IPv4, and IPv6 with and without Jumbo
payloads.  therefore, we moved ipPayloadLength from the
header field section to the section of Information Elements
reporting derived properties.

> Comment:
>>  9, AUT      51      Authentication Header
>>  10, ENC      50      Encrypted security payload
>
> "AH" and "ESP" would have been easier-to-remember
> mnemonics. Same for ROU / RH.

Done.

[Ballot discuss]
The types for dateTime do not match the ipfix-protcol document which specified size of integer and an epoc.

It is not clear how to encode a ipv4address, ipv6address, octet array, or macAddress into the ipfix-protocol.

[Ballot discuss]
> 7.  IANA Considerations
...
>  New assignments for IPFIX Information Elements will be administered
>  by IANA, on a First Come First Served basis [RFC2434], subject to
>  Expert Review [RFC2434], i.e. review by one of a group of experts
>  designated by an IETF Operations and Management Area Director. 
...
>  New assignments for MPLS label types will be administered by IANA, on
>  a First Come First Served basis [RFC2434], subject to Expert Review
>  [RFC2434], i.e. review by one of a group of experts designated by an
>  IETF Operations and Management Area Director.

FCFS and Expert Review are mutually exclusive. Pick one.

(Also, the IESG can reorganize its Areas any time it wants.
So it is more future-proof to delete 'Operations and Management'.)

[Ballot comment]
>  9, AUT      51      Authentication Header
>  10, ENC      50      Encrypted security payload

"AH" and "ESP" would have been easier-to-remember
mnemonics. Same for ROU / RH.

[Ballot discuss]
> 5.4.30.  payloadLengthIPv6
> 5.4.31.  ipPayloadLength

From the descriptions I do not see any
difference in the value of these where
IPv6 is used. Why have two variables?
Note that since both are unsigned32,
there does not seem to be the same
backwards compatibility issue as there
was for ipTotalLength and totalLengthIPv4.

[Ballot discuss]
Section 3.1.12:
macAddress

  The type "macAddress" represents a string of 6 octets.

How is this field going to be able to handle IEEE EUI-64 (64 bits) MACs? I do suggest that you either define two types of MAC or expand it to 64 bit.

5.2.8.  collectorTransportProtocol

  Description:
      The value of the protocol number used by the Exporting Process for
      sending Flow information.  The protocol number identifies the IP
      packet payload type.  Protocol numbers are defined in the IANA
      Protocol Numbers registry.
      In Internet Protocol version 4 (IPv4) this is carried in the
      "Protocol" field.  In Internet Protocol version 6 (IPv6) this is
      carried in the "Next Header" field in the last extension header of
      the packet.

What about nested protocols? Which level should be included here. The definition needs to clarify which protocol this applies to in a nested situation or if the complete chain should be included.

In general how does the collector transport handle cases where protocols are nested. Does it only care about the transport protocol (TCP, UDP, etc.) or does it need to know if there was IP in IP tunneling, or something else that also was happening.

So please explain if you intend to handle nested protocols and then update the definition to clarify on which level the next protocol ID filed should be read.

Section 5.5.10:

The tcpWindowSize is useless unless you capture and store the WSCALE option that appears on the SYN [RFC1323]. The document needs to specify inforamtion element and capture method for this inforamtion.


Section 7.3:

  1.  Registration request for the IPFIX information model namespace
      *  URI: urn:ietf:params:xml:ns:ipfix-info-10
      *  Registrant Contact: TBD.
      *  XML: None.  Namespace URIs do not represent an XML
  2.  Registration request for the IPFIX information model schema
      *  URI: urn:ietf:params:xml:schema:ipfix-info-10
      *  Registrant Contact: TBD.
      *  XML: See Appendix B for this document.

These registration templates seems incomplete with Registrant contact as TBD. Also is it fully intended to keep the draft version (of a previous version) in the URN?

Section 8.

The security section should note that exposing some of the objects in the
IPFIX information model blur the distinction between on-path and off-path
attacks.  In particular exposing the connection 4-tuple, sequence and
acknowledgment numbers to an authorized but insufficiently secure remote
agent makes a monitored connection subject to on-path attacks by proxy, even when the attacker is off-path.

[Ballot discuss]
Section 3.1.12:
macAddress

  The type "macAddress" represents a string of 6 octets.

How is this field going to be able to handle IEEE EUI-64 (64 bits) MACs? I do suggest that you either define two types of MAC or expand it to 64 bit.

5.2.8.  collectorTransportProtocol

  Description:
      The value of the protocol number used by the Exporting Process for
      sending Flow information.  The protocol number identifies the IP
      packet payload type.  Protocol numbers are defined in the IANA
      Protocol Numbers registry.
      In Internet Protocol version 4 (IPv4) this is carried in the
      "Protocol" field.  In Internet Protocol version 6 (IPv6) this is
      carried in the "Next Header" field in the last extension header of
      the packet.

What about nested protocols? Which level should be included here. The definition needs to clarify which protocol this applies to in a nested situation or if the complete chain should be included.

In general how does the collector transport handle cases where protocols are nested. Does it only care about the transport protocol (TCP, UDP, etc.) or does it need to know if there was IP in IP tunneling, or something else that also was happening.

So please explain if you intend to handle nested protocols and then update the definition to clarify on which level the next protocol ID filed should be read.

Section 5.5.10:

The tcpWindowSize is useless unless you capture and store the WSCALE option that appears on the SYN [RFC1323]. The document needs to specify inforamtion element and capture method for this inforamtion.


Section 7.3:

  1.  Registration request for the IPFIX information model namespace
      *  URI: urn:ietf:params:xml:ns:ipfix-info-10
      *  Registrant Contact: TBD.
      *  XML: None.  Namespace URIs do not represent an XML
  2.  Registration request for the IPFIX information model schema
      *  URI: urn:ietf:params:xml:schema:ipfix-info-10
      *  Registrant Contact: TBD.
      *  XML: See Appendix B for this document.

These registration templates seems incomplete with Registrant contact as TBD. Also is it fully intended to keep the draft version (of a previous version) in the URN?

Section 8.

The security section should note that exposing some of the objects in the
IPFIX information model blur the distinction between on-path and off-path
attacks.  In particular exposing the connection 4-tuple, sequence and
acknowledgment numbers to an authorized but insufficiently secure remote
agent makes a monitored connection subject to on-path attacks by proxy, even when the attacker is off-path.

[Ballot discuss]
This document under describes timestamps as "normalized to the GMT
  time zone", which is good.  However, but does not specify the epoch
  or the handling of Leap seconds.  These issues were discussed at great
  length during the Last Call for RFC 4049.  To ensure interoperability,
  a similar wording should be used here.

  The following points are from the SecDir Review by Jeffrey Hutzelman.

  The security considerations section points out that some attributes
  "may for privacy or business issues be considered sensitive
  information", and goes on to indicate that appropriate measures must
  be taken in the protocol used to exchange such information.  These
  issues should be addressed primarily in the IPFIX protocol document.
  However, the potential for information elements to carry keying
  material deservises a few words.  Either say that is should not be
  done, say that doing so will require additional care in handling to
  avoid compromising the security of monitored flows.

  The IANA Considerations section calls for assignments based "on a
  First Come First Served basis [RFC2434], subject to Expert Review
  [RFC2434]".  These two are mutually exclusive.  I believe that
  Expert Review is the appropriate on in this case.

  Section 3.1 defines a variety of types, but leaves their encoding up
  to the IPFIX protocol document.  In the IPFIX protocol draft, address
  types are described as being "encoded the same way as the integral
  data types."  We have conventions for Ethernet, IPv4, and IPv6
  addresses, and they ought to be followed here.

[Ballot discuss]
The types for dateTime do not match the ipfix-protcol document which specified size of integer and an epoc.

It is not clear how to encode a ipv4address, ipv6address, octet array, or macAddress into the ipfix-protocol.

You should verify with IANA if they want URLs to registries in documents. The document may be fine as is - you should just verify with someone that knows.

[Ballot discuss]
Section 3.1.12:
macAddress

  The type "macAddress" represents a string of 6 octets.

How is this field going to be able to handle IEEE EUI-64 (64 bits) MACs? I do suggest that you either define two types of MAC or expand it to 64 bit.

5.2.8.  collectorTransportProtocol

  Description:
      The value of the protocol number used by the Exporting Process for
      sending Flow information.  The protocol number identifies the IP
      packet payload type.  Protocol numbers are defined in the IANA
      Protocol Numbers registry.
      In Internet Protocol version 4 (IPv4) this is carried in the
      "Protocol" field.  In Internet Protocol version 6 (IPv6) this is
      carried in the "Next Header" field in the last extension header of
      the packet.

What about nested protocols? Which level should be included here. The definition needs to clarify which protocol this applies to in a nested situation or if the complete chain should be included.

In general how does the collector transport handle cases where protocols are nested. Does it only care about the transport protocol (TCP, UDP, etc.) or does it need to know if there was IP in IP tunneling, or something else that also was happening.

So please explain if you intend to handle nested protocols and then update the definition to clarify on which level the next protocol ID filed should be read.

Section 7.3:

  1.  Registration request for the IPFIX information model namespace
      *  URI: urn:ietf:params:xml:ns:ipfix-info-10
      *  Registrant Contact: TBD.
      *  XML: None.  Namespace URIs do not represent an XML
  2.  Registration request for the IPFIX information model schema
      *  URI: urn:ietf:params:xml:schema:ipfix-info-10
      *  Registrant Contact: TBD.
      *  XML: See Appendix B for this document.

These registration templates seems incomplete with Registrant contact as TBD. Also is it fully intended to keep the draft version (of a previous version) in the URN?

[Ballot discuss]
Section 3.1.12:
macAddress

  The type "macAddress" represents a string of 6 octets.

How is this field going to be able to handle IEEE EUI-64 (64 bits) MACs?

5.2.8.  collectorTransportProtocol

  Description:
      The value of the protocol number used by the Exporting Process for
      sending Flow information.  The protocol number identifies the IP
      packet payload type.  Protocol numbers are defined in the IANA
      Protocol Numbers registry.
      In Internet Protocol version 4 (IPv4) this is carried in the
      "Protocol" field.  In Internet Protocol version 6 (IPv6) this is
      carried in the "Next Header" field in the last extension header of
      the packet.

What about nested protocols? Which level should be included here. The definition needs to clarify which protocol this applies to in a nested situation or if the complete chain should be included.

In general how does the collector transport handle cases where protocols are nested. Does it only care about the transport protocol (TCP, UDP, etc.) or does it need to know if there was IP in IP tunneling, or something else that also was happening.

Section 7.3:

  1.  Registration request for the IPFIX information model namespace
      *  URI: urn:ietf:params:xml:ns:ipfix-info-10
      *  Registrant Contact: TBD.
      *  XML: None.  Namespace URIs do not represent an XML
  2.  Registration request for the IPFIX information model schema
      *  URI: urn:ietf:params:xml:schema:ipfix-info-10
      *  Registrant Contact: TBD.
      *  XML: See Appendix B for this document.

These registration templates seems incomplete with Registrant contact as TBD. Also is it fully intended to keep the draft version (of a previous version) in the URN?

[Ballot discuss]
Section 2.3:

Handling of middleboxes modifying data values. I think this topic needs to be taken much more serius. I do understand that there exist a need to support middleboxes. However allowing them to modify the values orignally entered indicates that one hasn't tried to allow them in a usable and secure  way. I definitly think one need to be able to ensure the authenticity of the original data. Thus it would be much better if the middlebox created its own instance of the data and linked that to the orignal one/latest instance. Thus each entity can sign its own data. It also allows one to debug which middlebox that is introducing errors. I don't think the proposed mechanism with including "post" is sufficient to ensure security and follow up on modifications.

Section 3.1.12:
macAddress

  The type "macAddress" represents a string of 6 octets.

How is this field going to be able to handle IEEE EUI-64 (64 bits) MACs?

5.2.8.  collectorTransportProtocol

  Description:
      The value of the protocol number used by the Exporting Process for
      sending Flow information.  The protocol number identifies the IP
      packet payload type.  Protocol numbers are defined in the IANA
      Protocol Numbers registry.
      In Internet Protocol version 4 (IPv4) this is carried in the
      "Protocol" field.  In Internet Protocol version 6 (IPv6) this is
      carried in the "Next Header" field in the last extension header of
      the packet.

What about nested protocols? Which level should be included here. The definition needs to clarify which protocol this applies to in a nested situation or if the complete chain should be included.

In general how does the collector transport handle cases where protocols are nested. Does it only care about the transport protocol (TCP, UDP, etc.) or does it need to know if there was IP in IP tunneling, or something else that also was happening.

Section 7.3:

  1.  Registration request for the IPFIX information model namespace
      *  URI: urn:ietf:params:xml:ns:ipfix-info-10
      *  Registrant Contact: TBD.
      *  XML: None.  Namespace URIs do not represent an XML
  2.  Registration request for the IPFIX information model schema
      *  URI: urn:ietf:params:xml:schema:ipfix-info-10
      *  Registrant Contact: TBD.
      *  XML: See Appendix B for this document.

These registration templates seems incomplete with Registrant contact as TBD. Also is it fully intended to keep the draft version (of a previous version) in the URN?

[Ballot comment]
Section 5.5:

I am missing a meter on UDP checksum usage. As the UDP checksum may be turned of by setting it to 0 one can meter on this.

[Ballot comment]
Section 5.5:

I am missing a meter on UDP checksum usage. As the UDP checksum may be turned of by setting it to 0 one can meter on this.

5.12.1.  paddingOctets

Shouldn't this be paddingOctet as each value is a single octet?

[Ballot comment]
Section 5.5:

I am missing a meter on UDP checksum usage. As the UDP checksum may be turned of by setting it to 0 one can meter on this.

[Ballot discuss]
Section 2.3:

Handling of middleboxes modifying data values. I think this topic needs to be taken much more serius. I do understand that there exist a need to support middleboxes. However allowing them to modify the values orignally entered indicates that one hasn't tried to allow them in a usable and secure  way. I definitly think one need to be able to ensure the authenticity of the original data. Thus it would be much better if the middlebox created its own instance of the data and linked that to the orignal one/latest instance. Thus each entity can sign its own data. It also allows one to debug which middlebox that is introducing errors. I don't think the proposed mechanism with including "post" is sufficient to ensure security and follow up on modifications.

Section 3.1.12:
macAddress

  The type "macAddress" represents a string of 6 octets.

How is this field going to be able to handle IEEE EUI-64 (64 bits) MACs?

5.2.8.  collectorTransportProtocol

  Description:
      The value of the protocol number used by the Exporting Process for
      sending Flow information.  The protocol number identifies the IP
      packet payload type.  Protocol numbers are defined in the IANA
      Protocol Numbers registry.
      In Internet Protocol version 4 (IPv4) this is carried in the
      "Protocol" field.  In Internet Protocol version 6 (IPv6) this is
      carried in the "Next Header" field in the last extension header of
      the packet.

What about nested protocols? Which level should be included here. The definition needs to clarify which protocol this applies to in a nested situation or if the complete chain should be included.

In general how does the collector transport handle cases where protocols are nested. Does it only care about the transport protocol (TCP, UDP, etc.) or does it need to know if there was IP in IP tunneling, or something else that also was happening.

[Ballot discuss]
Section 2.3:

Handling of middleboxes modifying data values. I think this topic needs to be taken much more serius. I do understand that there exist a need to support middleboxes. However allowing them to modify the values orignally entered indicates that one hasn't tried to allow them in a usable and secure  way. I definitly think one need to be able to ensure the authenticity of the original data. Thus it would be much better if the middlebox created its own instance of the data and linked that to the orignal one/latest instance. Thus each entity can sign its own data. It also allows one to debug which middlebox that is introducing errors. I don't think the proposed mechanism with including "post" is sufficient to ensure security and follow up on modifications.

Section 3.1.12:
macAddress

  The type "macAddress" represents a string of 6 octets.

How is this field going to be able to handle IEEE EUI-64 (64 bits) MACs?

5.2.8.  collectorTransportProtocol

  Description:
      The value of the protocol number used by the Exporting Process for
      sending Flow information.  The protocol number identifies the IP
      packet payload type.  Protocol numbers are defined in the IANA
      Protocol Numbers registry.
      In Internet Protocol version 4 (IPv4) this is carried in the
      "Protocol" field.  In Internet Protocol version 6 (IPv6) this is
      carried in the "Next Header" field in the last extension header of
      the packet.

What about nested protocols? Which level should be included here. The definition needs to clarify which protocol this applies to in a nested situation or if the complete chain should be included.

[Ballot discuss]
Section 2.3:

Handling of middleboxes modifying data values. I think this topic needs to be taken much more serius. I do understand that there exist a need to support middleboxes. However allowing them to modify the values orignally entered indicates that one hasn't tried to allow them in a usable and secure  way. I definitly think one need to be able to ensure the authenticity of the original data. Thus it would be much better if the middlebox created its own instance of the data and linked that to the orignal one/latest instance. Thus each entity can sign its own data. It also allows one to debug which middlebox that is introducing errors. I don't think the proposed mechanism with including "post" is sufficient to ensure security and follow up on modifications.

Section 3.1.12:
macAddress

  The type "macAddress" represents a string of 6 octets.

How is this field going to be able to handle IEEE EUI-64 (64 bits) MACs?

[Ballot discuss]
Section 2.3:

Handling of middleboxes modifying data values. I think this topic needs to be taken much more serius. I do understand that there exist a need to support middleboxes. However allowing them to modify the values orignally entered indicates that one hasn't tried to allow them in a usable and secure  way. I definitly think one need to be able to ensure the authenticity of the original data. Thus it would be much better if the middlebox created its own instance of the data and linked that to the orignal one/latest instance. Thus each entity can sign its own data. It also allows one to debug which middlebox that is introducing errors. I don't think the proposed mechanism with including "post" is sufficient to ensure security and follow up on modifications.

[Ballot discuss]
Section 2.3:

Handling of middleboxes modifying data values. I think this topic needs to be taken much more serius. I do understand that there exist a need to support middleboxes. However allowing them to modify the values orignally entered indicates that one hasn't tried to allow them in a usable and secure  way. I definitly think one need to be able to ensure the authenticity of the original data. Thus it would be much better if the middlebox created its own instance of the data and linked that to the orignal one/latest instance. Thus each entity can sign its own data. It also allows one to debug which middlebox that is introducing errors.

[Ballot discuss]
(My review isn't complete, so I may add to this.)

> 7.  IANA Considerations
...
>  New assignments for IPFIX Information Elements will be administered
>  by IANA, on a First Come First Served basis [RFC2434], subject to
>  Expert Review [RFC2434], i.e. review by one of a group of experts
>  designated by an IETF Operations and Management Area Director. 
...
>  New assignments for MPLS label types will be administered by IANA, on
>  a First Come First Served basis [RFC2434], subject to Expert Review
>  [RFC2434], i.e. review by one of a group of experts designated by an
>  IETF Operations and Management Area Director.

FCFS and Expert Review are mutually exclusive. Pick one.

(Also, the IESG can reorganize its Areas any time it wants.
So it is more future-proof to delete 'Operations and Management'.)

State Change Notice email list have been change to n.brownlee@auckland.ac.nz, quittek@netlab.nec.de, stbryant@cisco.com, bclaise@cisco.com, paitken@cisco.com, jemeyer@paypal.com from n.brownlee@auckland.ac.nz, n.brownlee@auckland.ac.nz, plonka@doit.wisc.edu; dromasca@avaya.com

IANA Last Call Comments:

#1. Creation of IPFIX Information Elements registry
Upon approval of this document, the IANA will make the following assignments
in the "IPFIX Information Elements" registry located at
http://www.iana.org/assignments/TBD-ipfix

Registration Policy:
New assignments for IPFIX Information Elements will be administered
by IANA, on a First Come First Served basis [RFC2434], subject to
Expert Review [RFC2434], i.e. review by one of a group of experts
designated by an IETF Operations and Management Area Director. The
group of experts must double check the Information Elements
definitions with already defined Information Elements for
completeness, accuracy, redundancy, and correct naming following the
naming conventions in section 2.3.

Value allocation policy:
+---------------------------------+---------------------------------+
| Range of IANA-assigned | Description |
| Information Element identifiers | |
+---------------------------------+---------------------------------+
| 0 | Reserved. |
| 1 - 127 | Information Element identifiers |
| | compatible with NetFlow version |
| | 9 field types [RFC3954]. |
| 128 - 32767 | Further Information Element |
| | identifiers. |
+---------------------------------+---------------------------------+

Initial values using RFC3954 as reference
+-------+-------------------------+-------+-------------------------+
| ID | Name | ID | Name |
+-------+-------------------------+-------+-------------------------+
| 1 | octetDeltaCount | 43 | RESERVED |
| 2 | packetDeltaCount | 44 | sourceIPv4Prefix |
| 3 | RESERVED | 45 | destinationIPv4Prefix |
| 4 | protocolIdentifier | 46 | mplsTopLabelType |
| 5 | ipClassOfService | 47 | mplsTopLabelIPv4Address |
| 6 | tcpControlBits | 48-51 | RESERVED |
| 7 | sourceTransportPort | 52 | minimumTTL |
| 8 | sourceIPv4Address | 53 | maximumTTL |
| 9 | sourceIPv4PrefixLength | 54 | fragmentIdentification |
| 10 | ingressInterface | 55 | postIpClassOfService |
| 11 | destinationTransportPort | 56 | sourceMacAddress |
| 12 | destinationIPv4Address | 57 | postDestinationMacAddr |
| 13 | destinationIPv4PrefixLength| 58 | vlanId |
| 14 | egressInterface | 59 | postVlanId |
| 15 | ipNextHopIPv4Address | 60 | ipVersion |
| 16 | bgpSourceAsNumber | 61 | RESERVED |
| 17 | bgpDestinationAsNumber | 62 | ipNextHopIPv6Address |
| 18 | bgpNexthopIPv4Address | 63 | bgpNexthopIPv6Address |
| 19 | postMCastPacketDeltaCount| 64 | ipv6ExtensionHeaders |
| 20 | postMCastOctetDeltaCount | 65-69 | RESERVED |
| 21 | flowEndSysUpTime | 70 | mplsTopLabelStackEntry |
| 22 | flowStartSysUpTime | 71 | mplsLabelStackEntry2 |
| 23 | postOctetDeltaCount | 72 | mplsLabelStackEntry3 |
| 24 | postPacketDeltaCount | 73 | mplsLabelStackEntry4 |
| 25 | minimumPacketLength | 74 | mplsLabelStackEntry5 |
| 26 | maximumPacketLength | 75 | mplsLabelStackEntry6 |
| 27 | sourceIPv6Address | 76 | mplsLabelStackEntry7 |
| 28 | destinationIPv6Address | 77 | mplsLabelStackEntry8 |
| 29 | sourceIPv6PrefixLength | 78 | mplsLabelStackEntry9 |
| 30 | destinationIPv6Mask | 79 | mplsLabelStackEntry10 |
| 31 | flowLabelIPv6 | 80 | destinationMacAddress |
| 32 | icmpTypeCodeIPv4 | 81 | postSourceMacAddress |
| 33 | igmpType | 82-84 | RESERVED |
|34-35 | RESERVED | 85 | octetTotalCount |
| 36 | flowActiveTimeout | 86 | packetTotalCount |
| 37 | flowIdleTimeout | 87 | RESERVED |
|38-39 | RESERVED | 88 | fragmentOffset |
| 40 | exportedOctetTotalCount | 89 | RESERVED |
| 41 | exportedMessageTotalCount| 90 |mplsVpnRouteDistinguisher|
| 42|exportedFlowRecordTotalCount|91-127 | RESERVED |
+-------+-------------------------+-------+-------------------------+

Additional values using [RFC-ipfix-info] as reference.
+-----+---------------------------+-----+---------------------------+
| ID | Name | ID | Name |
+-----+---------------------------+-----+---------------------------+
| 128 | bgpNextAdjacentAsNumber | 172 | postPacketTotalCount |
| 129 | bgpPrevAdjacentAsNumber | 173 | flowKeyIndicator |
| 130 | exporterIPv4Address | 174 | postMCastPacketTotalCount |
| 131 | exporterIPv6Address | 175 | postMCastOctetTotalCount |
| 132 | droppedOctetDeltaCount | 176 | icmpTypeIPv4 |
| 133 | droppedPacketDeltaCount | 177 | icmpCodeIPv4 |
| 134 | droppedOctetTotalCount | 178 | icmpTypeIPv6 |
| 135 | droppedPacketTotalCount | 179 | icmpCodeIPv6 |
| 136 | flowEndReason | 180 | udpSourcePort |
| 137 | commonPropertiesId | 181 | udpDestinationPort |
| 138 | observationPointId | 182 | tcpSourcePort |
| 139 | icmpTypeCodeIPv6 | 183 | tcpDestinationPort |
| 140 | mplsTopLabelIPv6Address | 184 | tcpSequenceNumber |
| 141 | lineCardId | 185 | tcpAcknowledgementNumber |
| 142 | portId | 186 | tcpWindowSize |
| 143 | meteringProcessId | 187 | tcpUrgentPointer |
| 144 | exportingProcessId | 188 | tcpHeaderLength |
| 145 | templateId | 189 | ipHeaderLength |
| 146 | wlanChannelId | 190 | totalLengthIPv4 |
| 147 | wlanSSID | 191 | payloadLengthIPv6 |
| 148 | flowId | 192 | ipTTL |
| 149 | observationDomainId | 193 | nextHeaderIPv6 |
| 150 | flowStartSeconds | 194 | mplsPayloadLength |
| 151 | flowEndSeconds | 195 | ipDiffServCodePoint |
| 152 | flowStartMilliseconds | 196 | ipPrecedence |
| 153 | flowEndMilliseconds | 197 | fragmentFlags |
| 154 | flowStartMicroseconds | 198 | octetDeltaSumOfSquares |
| 155 | flowEndMicroseconds | 199 | octetTotalSumOfSquares |
| 156 | flowStartNanoseconds | 200 | mplsTopLabelTTL |
| 157 | flowEndNanoseconds | 201 | mplsLabelStackLength |
| 158 | flowStartDeltaMicroseconds| 202 | mplsLabelStackDepth |
| 159 | flowEndDeltaMicroseconds | 203 | mplsTopLabelExp |
| 160 | systemInitTimeMilliseconds| 204 | ipPayloadLength |
| 161 | flowDurationMilliseconds | 205 | udpMessageLength |
| 162 | flowDurationMicroseconds | 206 | isMulticast |
| 163 | observedFlowTotalCount | 207 | ipv4IHL |
| 164 | ignoredPacketTotalCount | 208 | ipv4Options |
| 165 | ignoredOctetTotalCount | 209 | tcpOptions |
| 166 | notSentFlowTotalCount | 210 | paddingOctets |
| 167 | notSentPacketTotalCount | 211 | collectorIPv4Address |
| 168 | notSentOctetTotalCount | 212 | collectorIPv6Address |
| 169 | destinationIPv6Prefix | 213 | collectorInterface |
| 170 | sourceIPv6Prefix | 214 | collectorProtocolVersion |
| 171 | postOctetTotalCount | 215 | collectorTransportProtocol|
| | | 216 | collectorTransportPort |

Following types are defined in the document but are not assigned a code
and IANA will allocate codes for them upon approval of this document
variable assignment section
destinationTransportPort NONE 5.4.2.
exportedMessageTotalCount NONE 5.2.3.
exportedOctetTotalCount NONE 5.2.4.
flowStartDeltaMicroSeconds NONE 5.8.9.
ipPayloadLength NONE 5.3.34.
ipv6ExtensionHeaders NONE 5.7.6.
mplsLabelStackDepth NONE 5.5.11.
notSentOctetTotalCount NONE 5.2.11.
notSentPacketTotalCount NONE 5.2.10.
postMCastOctetDeltaCount NONE 5.9.16.
postMCastPacketDeltaCount NONE 5.9.15.
sourceMacAddress NONE 5.5.1.
systemInitTimeMilliSeconds NONE 5.8.11.


#2: MPLS Label Type registry
Upon approval of this document, the IANA will make the following assignments
in the "IPFIX MPLS label type" registry located at
http://www.iana.org/assignments/TBD-ipfix-mpls

Registration Policy:
New assignments for MPLS label types will be administered by IANA, on
a First Come First Served basis [RFC2434], subject to Expert Review
[RFC2434], i.e. review by one of a group of experts designated by an
IETF Operations and Management Area Director. The group of experts
must double check the label type definitions with already defined
label types for completeness, accuracy, and redundancy. The
specification of new MPLS label types MUST be published using a well
established and persistent publication medium.

Initial Contents:
All have RFC-ipfix-info as reference
1 TE-MIDPT: Any TE tunnel mid-point or tail label
2 Pseudowire: Any PWE3 or Cisco AToM based label
3 VPN: Any label associated with VPN
4 BGP: Any label associated with BGP or BGP routing
05 LDP: Any label associated with dynamically assigned
labels using LDP


#3 URI Registration
Upon approval of this document, the IANA will make the following assignments
in the XML-NS registry located at
http://www.iana.org/assignments/xml-registry/ns.html

ID URN filename REFERNCE
ipfix urn:ietf:params:xml:ns:ipfix-info TBD RFC-ipfix-info


#4 URI Registration
Upon approval of this document, the IANA will make the following assignments
in the XMLschema registry located at
http://www.iana.org/assignments/xml-registry/schema.html

ID URN filename REFERNCE
ipfix urn:ietf:params:xml:schema:ipfix-info TBD RFC-ipfix-info

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

AD review posted to WG list.
Checking if it indeed will result in a new revision.
I think such makes sense.

-----Original Message-----
From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On Behalf
Of Wijnen, Bert (Bert)
Sent: Friday, March 17, 2006 17:42
To: 'Ipfix Wg' (E-mail) (E-mail)
Cc: Dan Romascanu (E-mail); David Kessens (E-mail)
Subject: [ipfix] AD review for: draft-ietf-ipfix-info-11.txt


Sorry that it took so long (if I say it 4 times, i.e.
for each doc I have reviewed, will you please forgive me).

Seems that a new rev might be in order ??

Bert

- bottom of page 8. enterpriseId -
  it speaks about "Information Element Identifier described above"
  I do not see where "above" it is described. In fact, I think the
  Identifier is described in sect 4, no?

- In the 3 paragraphs of sect 3 and 3.1, I would insert the word "abstract"
  in from of each occurence of "data type(s)".
  Also the title of sect 3.1 probably reads better as "Abstract Data Types".

- sect 3.1.9
  "it is expected that strings will be encoded in UTF-8"
  That does not make it interoperable, does it?
  Would it not be better to say "strings MUST be encoded..."
  And I woudl add a citation and reference to RFC3629.

- sect 3.2
  s/future protocol extensions/future information model extensions/ ??

- page 16
  What are ID 211 and 212 ?? blank ?? reserved?? something else?
  I see the explanation on page 17. I'd suggest to make them RESERVED
  or OBSOLLETE or DEPRECATEd or give them some name with the note
  that they are not part of the standard.

- section 5 1st sentence
  s/Flow attributes/Information Elements/ ??

- sections 5.1.3, 5.1.4., 5.1.5 and 5.1.6
  I worry about referential integrety when the ifIndex gets stored
  in offline/archive storage. On a reboot, many devices renumber the
  ifIndex for various interfaces.
  Is this not a problem? I'd think it is at least something to
  mention/discuss/warn for.

- sect 5.2.3
  Is the message that contains this Information Element included in the
  count?? May want to make that clear for better interoperability.
  Same for some of the other exportXXXCounters

- sect 5.2.5
  Text says: number of flow records
  But in Units it says: flows
  So what is it?
  Same for sect 5.2.9

- sect 5.2.8
  Does the count include header octets?

- sect 5.2.12
  It is not clear/sopecific as to which bit is bit zero, bit one etc.

- Sect 5.2.3 and 5.2.5
  Is it best to speak about Mask?
  Or would speaking of (and naming it) PrefixLength be better?

- Sect 5.6.3
  I worry about the fact that there is discussion already about AS numbers
  of 32-bit length. So are we future proof here?
  In the MIB/SMI world we have made it a 32bit unsigned, see
  InetAutonomousSystemNumber in RFC4001.

- sect 5.6.9
  How are new values of Labeltypes be added in the future?
  last line in this section, remove "and IP addresses" ??

- sect 5.8
  Just for my understanding, why do you need all 4 levels
  of granularity here (i.e. sec, milisec, microsec and nanosec)??

- sect 5.5.x
  Would it be usefull to add a line of text to explain how long
  (how many minutes, months, years) each granularity allows
  based on the underlying datatype?

- sect 5.9.11 to 5.9.14
  I wondered if it makes sense to say some thing more about
  "packet treatment". Like what sort of treatment? Any
  reference to an RFC?

- sect 5.10.2 speaks about flowInactiveTimeout while sect 5.10.3
  speaks about idle timeout. Should you have flowIdleTimeout
  instead of flowInactievTimeout for consistency?

- sect 5.10.11
  Make it clear that the value is hex 00 (0 could be read
  as decimal zero)

- sect 6, page 69
  I think I would make it MUST instead of SHOULD in 2nd
  and 3rd para.

- sect 7
  first para, pls add a ptr to the list of Information
  Element Identifiers that need to be recorded as the
  initially assigned values for this registry.
  I guess you need to point them to sect 4.
  I doubt it is clear to IANA though what exactly to record
  from that section. You can check directly with iana to
  ask if things are clear or not and if not to work out
  text with them that they understand.

  I wonder if it would not be much better to have new
  Information Elements require a Standards Track action.
  I think that ensure much better review and evaluation
  and certainly ensure well-documented registrations.

  In any event, if you do do FCFS with expert review,
  then I would
  - require proper documentation to be publicly available
  - maybe setup some sort of template that MUST be filled
    out and approved to request registration.

  You speak about an Appendix B as having a schema/example
  on how to extend. It is howeer (I think) the Schema
  for the currently assigned values.

- Sect 8.
  I am pretty sure that the Security ADs will want to see
  more detail here. They probably want to understand which
  Information Elements contain sensitive data (and why it
  is sensitive) or privacy sensitive data (and why so).
  Probably similar to why they want to see that a MIB
  document lists the objects that are sensitive and
  why so and what the risks are if the data gets
  intercepted.

- Appendix A and B
  I am a bit confused when I read as title
  "Formal Specification..." and then in the first para
  I read that it is informational and not normative.

  If it is a "fomral machine readable spec.." is it then not
  intended as input to tools, code-generators, data-structure
  generators and such? In that case I would be very worried
  if no tthis schema but the text earlier in the document
  is normative and authoritative.
 
  Anyway, I asked an APPS AD if he could check the "formal"
  machine readable schema, but he does not recognize it as
  a schema that can be checked by any of his tools. So
  what is it? How can we (or anyone) check it for correctness?

administrative/bureaucracy/nits/spelling:

- sect 5.10.4

  "bewtween in time" in first sentence ??
 
  same in sect 5.10.5

- 3rd para in sect 1. I suspect that the ptrs to the various sections
  do not completely match with the actual content claimed to be
  in those sections. Specifically, the ptrs to 4 and 5 should probably
  be 5 and 6 ??

- I see that you use MUST (i.e. rfc2119 type) language and
  so there MUST be a normative citation/reference to RFC2119.

- problems with references/citations.
  Note that my tool may give false warnings, so just check
  them.

  !! Missing citation for Informative reference:
  P071 L006:    [IEEE.802-11.1999]

  !! Missing citation for Informative reference:
  P071 L015:    [IEEE.802-3.2002]

  !! Missing citation for Informative reference:
  P071 L023:    [IEEE.P802-1Q.2003]

  !! Missing citation for Informative reference:
  P072 L026:    [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6

  !! Missing citation for Informative reference:
  P072 L029:    [RFC2463]  Conta, A. and S. Deering, "Internet Control Message

  !! Missing citation for Informative reference:
  P072 L033:    [RFC2547]  Rosen, E. and Y. Rekhter, "BGP/MPLS VPNs", RFC 2547,

  !! Missing citation for Informative reference:
  P072 L036:    [RFC2629]  Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,

  !! Missing citation for Informative reference:
  P072 L039:    [RFC2863]  McCloghrie, K. and F. Kastenholz, "The Interfaces Group

  !! Missing citation for Informative reference:
  P072 L042:    [RFC2960]  Stewart, R., Xie, Q., Morneault, K., Sharp, C.,

  !! Missing citation for Informative reference:
  P072 L047:    [RFC3031]  Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol

  !! Missing citation for Informative reference:
  P072 L050:    [RFC3032]  Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,

  !! Missing citation for Informative reference:
  P073 L006:    [RFC3036]  Andersson, L., Doolan, P., Feldman, N., Fredette, A., and

  !! Missing citation for Informative reference:
  P073 L012:    [RFC3260]  Grossman, D., "New Terminology and Clarifications for

  !! Missing citation for Informative reference:
  P073 L015:    [RFC3667]  Bradner, S., "IETF Rights in Contributions", RFC 3667,

  !! Missing citation for Informative reference:
  P073 L018:    [RFC3668]  Bradner, S., "Intellectual Property Rights in IETF

  !! Missing citation for Informative reference:
  P073 L021:    [RFC3917]  Quittek, J., Zseby, T., Claise, B., and S. Zander,

--