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

Note: This ballot was opened for revision 06 and is now closed.

(Benoît Claise; former steering group member) Yes

Yes ( for -06)
No email
send info

(Adrian Farrel; former steering group member) No Objection

No Objection ( for -06)
No email
send info

(Alia Atlas; former steering group member) No Objection

No Objection (2014-07-07 for -06)
No email
send info
Should this be PS instead of Informational?

(Alissa Cooper; former steering group member) No Objection

No Objection ( for -06)
No email
send info

(Barry Leiba; former steering group member) No Objection

No Objection (2014-07-08 for -06)
No email
send info
-- 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.  :-)

(Jari Arkko; former steering group member) No Objection

No Objection ( for -06)
No email
send info

(Joel Jaeggli; former steering group member) No Objection

No Objection (2014-07-01 for -06)
No email
send info
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.

(Kathleen Moriarty; former steering group member) No Objection

No Objection ( for -06)
No email
send info

(Martin Stiemerling; former steering group member) No Objection

No Objection ( for -06)
No email
send info

(Pete Resnick; former steering group member) No Objection

No Objection (2014-07-10 for -06)
No email
send info
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.

(Richard Barnes; former steering group member) No Objection

No Objection (2014-07-09 for -06)
No email
send info
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.

(Spencer Dawkins; former steering group member) No Objection

No Objection ( for -06)
No email
send info

(Stephen Farrell; former steering group member) (was Discuss) No Objection

No Objection (2014-07-16 for -07)
No email
send info
Thanks for resolving my discuss with the additional security
considerations.