at the Collector of 60 minutes. The
Collecting Process MAY estimate each Exporting Process's resend time
and adapt the expiry time for the corresponding Templates
accordingly.
Scott O. Bradner wrote:
I reviewed draft-ietf-ipfix-protocol-26.txt as part of the Transport
Area review effort
we received similar comments during the transport directorate review of
the IPFIX implementation guidelines. The new revision of the document, now
available at:
http://www.ietf.org/internet-drafts/draft-ietf-ipfix-implementation-guidelines-07.txt
might address your concerns.
I'm
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
: 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
Scott
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
PROTECTED]
Subject: Re: [IPFIX] draft-ietf-ipfix-protocol-26.txt
Scott
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
