Textual Representation of IP Flow Information Export (IPFIX) Abstract Data Types
draft-ietf-ipfix-text-adt-10

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-ipfix-text-adt-07, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any IANA actions.

While it is helpful for the IANA Considerations section of the document to remain in place upon publication, if the authors prefer to remove it, IANA doesn't object.

If this assessment is not accurate, please respond as soon as possible.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Textual Representation of IPFIX Abstract Data Types) to Proposed Standard


The IESG has received a request from the IP Flow Information Export WG
(ipfix) to consider the following document:
- 'Textual Representation of IPFIX Abstract Data Types'
 

During the IESG telechat, the IESG concluded that this document should be
Proposed Standard, and not Informational as initially proposed in v6.
This IETF LC should focus on the Proposed Standard changes in the
latest version.

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 2014-07-30. 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 defines UTF-8 representations for IPFIX abstract data
  types, to support interoperable usage of the IPFIX Information
  Elements with protocols based on textual encodings.




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

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


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

[Ballot comment]
I question along with Alia: Why is this Informational? Seems like these things will eventually be protocol elements.

4.4:

( "e" / "E" ) is not necessary; in ABNF, any character enclosed in quotes is case insensitive.

The ABNF as written allows the mantissa to terminate with a decimal. So you could end up with:

  1234.E56

Is that legit? Did you instead mean:

  right-decimal = "." 1*DIGIT

?

4.8: I do wish you didn't reuse "partial-time" when it differs from the definition in 3339. How about "whole-time" or "integer-time"?

4.8-4.10: If you are importing the ABNF from somewhere else, it might be better to just do so by reference instead of reproducing the text here.

[Ballot discuss]

Just one thing I'd like to ask: does IPFIX have any way to
represent the special value "I'm not saying" for each of these
basic types? If not, then I think this ought define such
values for each type. The logic for that, is also related to a
missing security consideration - IPFIX data in this format
will likely be more easily searchable and aggregatable and
hence more sensitive than binary or other formats.

The idea would be that anyone creating or schlepping around
data in this form would then have a well known way to elide
values when they decide that's the right thing to do, and
without confusing the receiver/reader into thinking that some
odd value was real. Its kind of like NaN, but for privacy,
and not arithmetical, reasons.

Resolving this might mean defining such "not telling" values
elsewhere, or here. So I might well accept punting on tihs if
you tell me it'll be done, but please do push back if you
think I'm just wrong in the above and don't ask to punt on
this if you disagree with it (yes, its been known to
happen;-).

I do think noting the new security consideration would be good
regardless but that is not by itself discuss-worthy.

[Ballot comment]
Is there any particular reason to insist that white space in octet arrays be inserted at octet boundaries?  It seems like you could just have the ABNF be "octetarray = 1*(hex-octet [WSP])", and deal with odd-length arrays either by forbidding them in text or by zero-padding.

It could be helpful to clarify that the min/max values in Table 1 and Table 2 are decimal.

It seems odd to allow hex/binary for unsigned, but only decimal for signed.  Couldn't you just say "signed = [sign] unsigned"?

Nit: ".." at the end of Section 4.7.

[Ballot comment]
-- Section 4.1 --

  octetarray = 1*(hex-octet [WSP])

I'll note that this allows an octetarray to have trailing WSP.  If that's intended, that's fine, but it does differ from what the text says.  If you want to fix it, this will work:

NEW
  octetarray = hex-octet *([WSP] hex-octet)
END

-- Section 4.3 --
Please fix the table entry for "signed64" so that the minimum value is all on one line.

-- Section 4.4 --
In the ABNF for "naninf", it's not strictly required but it would help readability to put parentheses around << sign "inf" >>.

-- Section 4.7 --
Last paragraph: nicely dodged.  :-)

[Ballot comment]
I'd just note that some of the considerations expressed in section 4.7 do seem like security considerations given the relative dangers associated with string processing.

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-ipfix-text-adt-05, which is currently in Last Call, and has the following comments:

We understand that,  upon approval of this document, there are no IANA Actions that need completion.

While it is helpful for the IANA Considerations section of the document to remain in place upon publication, if the authors prefer to remove it, IANA doesn't object.

If this assessment is not accurate, please respond as soon as possible.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Textual Representation of IPFIX Abstract Data Types) to Informational RFC


The IESG has received a request from the IP Flow Information Export WG
(ipfix) to consider the following document:
- 'Textual Representation of IPFIX Abstract Data Types'
  as Informational RFC

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 2014-05-28. 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 defines UTF-8 representations for IPFIX abstract data
  types, to support interoperable usage of the IPFIX Information
  Elements with protocols based on textual encodings.




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

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


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