Subject: Re: [ipfix-arch] Answer to the recent comments on the Architecture Draft

From: Benoit Claise <[email-masked]>
Date: Mon, 11 Feb 2002 08:53:34 +0100 (CET)

Mister Penno,

> 
> 1 - General Stuff:
> 
> :
> :The draft distributed by KC discusses a lot of far related
> :issues, but some essential components of the architecture are
> :(so far) rather poorly described. This is different in the 
> :I-D of Ganesh and Benoit.
> :
> :So why don't we take some text from it. I think their intention
> :is to contribute to the joint document (see their title).
> 
> I really do not know what you mean by this. Are you trying to help them? 
> 

It seems that you have a little problem either with Ganesh and me. Or either with the company that Ganesh and I are working for. As I don't know you from anywhere, I tend to be believe of the latter option.
Because, what kind of reply did you formulate? Is this a technical argument?
Or just to be negative to what engineers of a certain company are proposing.

Please explain.

BTW, one of Steve Coya's sentence during the introduction presentation before an IETF is: "don't come to the playground if you're not ready to share your toys".And this is what Ganesh and I have doing, by even sharing our customers feedback. But you seem to be negativ to whatever we propose... by principle?

While we are at the explanation time, just a little remark that made me smile. 
But I'm not sure many people noticed.

I read through your paragraph

   IPFIX WG                                                 Kevin Zhang  
   Internet Draft                                    XACCT Technologies 
   Expiration: August 2002                               Reinaldo Penno
                                                         NortelNetworks
    
                                                          February 2002 

                Contributions to the IPFIX Architecture 
                       (Capability Negotiation)

  ...

10.2.2 Reliability 

  ...

  In the case there are multiple collectors operating redundant mode, 
  the exporter MAY multicast the flow records to the set of collectors 
  that joined the export multicast group, instead of sending several 
  unicast streams towards the different collectors. Multicast would 
  lower the bandwidth requirements on the export link in case that the 
  collectors are on the same media, and could lower the internal bus 
  utilization on the exporter.

And I thought.. Hmmm, I know this paragraph. It looks familiar.
http://www.ietf.org/internet-drafts/draft-gsadasiv-ipfix-proposal-00.txt
Yes actually I wrote it ;)

So what's the point here? Instead of having a discussion on basic architecture pints, are we just writing and writing paragraphs just to make sure to have his own name on a draft/rfc?
Basically, I don't care too much about my name if we do this IPFIX right...

Have a nice day. Benoit.

--
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/