Scott, Please note the note included in the IETF Last Call: > A previous version draft-ietf-ipfix-protocol-24.txt of this draft was already approved by the IESG. The IPFIX WG decided to make changes to that version of the document with the principal goal of removing the SCTP stream 0 restriction. Reviews should focus on the changes since draft-ietf-ipfix-protocol-24.txt which are mentioned in an editorial note currently placed after the Table of Contents. I believe that none of your comments refers to the changes since draft-24. Do you consider any of your notes critical to the point that we should reopen aspects of the protocol already approved by the IESG? Thanks and Regards, Dan > -----Original Message----- > From: Scott O. Bradner [mailto:sob@xxxxxxxxxxx] > Sent: Tuesday, September 25, 2007 1:16 PM > To: ietf@xxxxxxxx > Cc: ipfix@xxxxxxxx; tsv-dir@xxxxxxxx > Subject: draft-ietf-ipfix-protocol-26.txt > > I reviewed draft-ietf-ipfix-protocol-26.txt as part of the > Transport Area review effort. > > I did not find any particular issues in the described > technology - a few > nits: > > section 3.1 "Export Time" someday the IETF needs to stop > using 32-bit "seconds since 1 jan 1970" for timing - at least > within in the next 31 years > > section 6.1.2 - it might be reasonable to add the IEEE 8-byte > MAC address as an address type - this is used in ZigBee and > may be in wider use in the future > > section 10.3.3 - a max packet size of 1280 could be used if > the connection is known to be running in an IPv6-only environment > > I'm not sure why the packet size discussion is only listed > for UDP - it seems like the same restriction should apply to > all protocols - fragmentation is not your friend > > Historically the biggest issue with IPFIX has been that most > implementers want to run it over UDP with consequences be > dammed. - this was weaseled in the IPFIX Requirements > document (RFC 3917) by requiring (in section 6.3.1) that "For > the data transfer, a congestion aware protocol must be > supported." This draft meets that requirement by making the > implementation of SCTP a MUST. That will not stop many > implementers from ignoring the requirement for implementation > or users to enable UDP and thus creating a potentially very > high bandwidth non-congestion avoiding fire hose that can > quite easily wipe out a net by misconfiguration or become a > DoS engine by purposeful configuration. > > I'm not sure if anything can be actually be done about this > risk - It might help some to say that UDP is a "MUST NOT" but > I doubt it - in any case it would help somewhat, imho, to > expand section 10.3 to be clearer about the threats posed by > any use of a non-congestion avoiding transport protocol or to > do that in the Security Considerations section > > Scott > > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www1.ietf.org/mailman/listinfo/ietf > _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf