Subject: [ipfix] RE: AD review for: draft-ietf-ipfix-architecture-09.txt

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Thu, 6 Apr 2006 21:06:07 +0200

Thanks.
Looks good to me.

Bert

> -----Original Message-----
> From: Nevil Brownlee [mailto:[email-masked]]
> Sent: Thursday, April 06, 2006 05:20
> To: [email-masked]; Bert
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: Re: AD review for: draft-ietf-ipfix-architecture-09.txt
> 
> 
> 
> Hi Bert:
> 
> It's taken me longer than I'd expected to revise the IPFIX 
> architecture
> draft - that's a tribute to your caeful and very helpful review!
> 
> I've commented on the changes inline below ..
> 
> - sect 2, under bullet observation domain
>   it speaks a bout a "unique ID".
>   Is that administratively unique?
>   or globally unique?
> 
>   * Unique per Exporting Process (i.e. administratively unique,
>     certainly not globally unique).a
> 
> - sect 5.4 last line
>   s/Source ID/Domain ID/ ??
>   Or should the section title be somthing about "Soutrce" ??
>   I am getting a bit confused about DOmain and Source ID I guess?
>   Protocol doc does indeed speak about SOurce ID.
> 
>   * Changed to Observation Domain ID (ditto for all four IPFIX drafts)
> 
> - sect 6.4 2nd para.
>   How can a IPfix device count the p[ackets losts in all
>   the possible problem scenarios?
>   Maybe the solution is to say that it should try to count
>   them and if it can, then it should report. Of it cannot count
>   them, then maybe give a indication of the time period that
>   packets could not be handled/seen?
> 
>   * Reowrked para to:
>   In such situations, the IPFIX Device should attempt to count the
>   number of packet losses that have occurred, and report them to its
>   Collector(s).  If it is not possible to count losses accurately,
>   e.g. when transport layer errors are detected, the IPFIX 
> device should
>   report this fact, and perhaps indicate the time period during which
>   some packets might not have been observed.
> 
> - sect 8.1 last para
>   I think it would be good to add a few more words on how operators
>   can avoid congestion. Just keeping it in their own domain helps
>   to not impact other networks, but if it is a live network with
>   normal user data, then it is still problemantic. Maybe you mean that
>   they should use a dedicated network for it?
>   Anyway, best to elaborate somewhat I think.
> 
>   * Added:      For example, one could    use a dedicated network (or 
> Ethernet link) to carry IPFIX
>     traffic from Exporter to Collector.
> 
> - I suspect that the Security Considerations section will be 
> considered
>   weak by the security ADs. You may want to check with them for early
>   review/comment. Early meaning right before or in parallel 
> with IETF LC.
>   For example, I am not sure that just MD5 is sufficient anymore.
> 
>   * I've emailed the Security ADs asking for some feedback, but
>     haven't received any answer.  I got my Network Security people
>     here at Auckland to read the Security Considerations sections
>     of all the drafts they weren't able to add anything useful.
> 
>     So I've made one slight change to the 
> 'Authentication-only' section:
>        TCP with MD5 options.  becomes  TCP with 'signed packet' option
>        - It seems to me that sect 11 is also Security 
> COnsideratons, no?
>   So should they be subsections of Sect 10?
> 
>   * Yes.  I've done that.
> 
> - Sect 12.1
>   I think you rather want Standards Action for approval of a new IPfix
>   version or template, no?
> 
>   * We chose 'Specification Required' from RFC 2434, because that
>     provides the highest degree of review.  Since 'IPFIX Protocol'
>     and 'IPFIX Info Model' are standards-track documents, 
> Standards Track
>     action will be needed for the new RFCs defining them, so I don't
>     think the words here need changing.
> 
>   * However, I've changed the words 'template number' to 'set ID,'
>     so that they line up properly with the IPFIX Protocol draft.
> 
> - page 30: Intellectual Property
>   the last para can be removed. We normally do not add such a 
> statement
>   because such claims can be filed any time, even after RFC 
> publication.
> 
>   * Deleted
> 
> admin/nites/spelling
> 
> - refernces/citation issues:
>   !! Missing Reference for citation: [IPFIX-INFO]
>   P008 L037:       The IPFIX information model [IPFIX-INFO] 
> defines the 
> base set of
> 
>   * Fixed
> 
> - In the abstract you should not use a citation
> 
>   * Removed the citation
> 
> - sect 1.2 last para
>   I would assume that config is done by network ops staff,  
> regardless 
> if it can be done remote or local or whatever
>   the tools are.
> 
>   * Changed para to:
>     Note that the IPFIX system does not provide for remote 
> configuration
>     of an IPFIX device.  Instead, implementors must provide an
>     effective way to configure their IPFIX devices.
> 
> - sect 2, middle of page 5
>   s/vvery/very/
> 
>   * Done
> 
> - page 6, 1st line: s/field/fields/
>   3rd line add closing parethesis
>   one but last line: remove 1 open parenthesis
> 
>   * Done
> 
> - page 8: s/sender Exporter/sending Exporter/ ??
> 
>   * OK
> 
> - page 9
>   In exmaples you should use IP addresses 192.0.2.x/24
>   as per RFC3330
> 
>   * Done, addresses mapped as follows ..
>     198.18.40/24 -> 102.0.2.0/26
>     198.18.23/24 -> 192.0.2.64/26
>     198.18.20/24 -> 192.0.2.128/26
> 
> - last sentence on page 10.
>   I do not see the difference between "<-->" and "<-->"
>   I know my eyes are getting worse, but this time I suspect
>   it is not caused by my eyes ;-)
> 
>   * The second used tildes instead of minuses.
>     I've changed them to = signs to make it clearer.
> 
> - sect 5.1.2 last sentence
>   s/Metering Process/Exporting Process/ ??
> 
>   * Yes  changed to /Exporting'
> 
> - sect 5.3.1. 2nd line
>   s/is/are/
> 
>   * Done
> 
> - sect 5.5  Pls use RFC3330 IP addresses in example IP addresses
> 
>   * Done (as above)
> 
> - Sect 6.3 speaks about "ID". Is that the "Domain ID" ??
> 
>   * Yes, I've changed the text to make this clear.
>     {ID, configuration domain (O1,O2), sampling algorithm, 
> interval    
> (1 in 100)}, where ID is the Observation Domain ID for the domain
>     containing O1 and O2.  The Observation Domain ID uniquely 
> identifies
>     this configuration, and must be sent within the Flow 
> Records in order
>     to be able to match the right configuration control information.
> 
> - sect 10: s/IPSEC/IPsec/
> 
>   * Done
> 
> I submitted the new version, draft-ietf-ipfix-architecture-10.txt
> to [email-masked], it should be up in a day or so.
> 
> 
> Thanks again, Nevil
> 
> --------------------------------------------------------------
> ---------
>    Nevil Brownlee                 Computer Science Department | ITSS
>    Phone: +64 9 373 7599 x88941           The University of Auckland
>    FAX: +64 9 373 7453      Private Bag 92019, Auckland, New Zealand
> 
> --------------------------------------------------------------
> ---------
> This mail sent through University of Auckland 
http://www.auckland.ac.nz

--
Help        mailto:[email-masked] and say "help" in message body
Unsubscribe mailto:[email-masked] and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/