Subject: RE: [ipfix] Re: Scope of IPFIX (was Answer to the recent comments on the Architecture Draft)

From: "Reinaldo Penno"<[email-masked]>
Date: Mon, 11 Feb 2002 20:57:07 -0800

Hello Norseth,
 
I think the right question to answer is not if it is "necessary", since you
can always pay somebody to be some sort of CLI configuration master and do
everything by hand.  
I think the right question is if it should be on the architecture document
or not and with whihch level of compliance. 
 
I think it should be on the arch document and maybe putting it with a SHOULD
instead of a MUST will make (most) people happy.
 
cheers,
 
Reinaldo

 -----Original Message-----
From: K.C. Norseth [mailto:[email-masked]]
Sent: Monday, February 11, 2002 8:25 PM
To: [email-masked]; [email-masked]
Subject: [ipfix] Re: Scope of IPFIX (was Answer to the recent comments on
the Architecture Draft)

Will,
 
I agree. Let's go for the wg concensus.  What do people say?
 
| - the exporter configuration is out of the scope of this document   (the
exporter configuration out of band)
 
Configuration I think is out of scope, unless we hook it to an existing mib
or something.  I so, we can refer to that mib or process.

|- no transport negotiation (which transport)

we need to define the action of each transport type.

| - no capability negotiation

Nice, but necessary?  

K.C.

----- Original Message ----- 
From: Will Eatherton <mailto:[email-masked]>  
To: Reinaldo Penno <mailto:[email-masked]>  ;
[email-masked] <mailto:[email-masked]>  ;
[email-masked]
<mailto:[email-masked]>  
Cc: [email-masked] <mailto:[email-masked]>  ;
[email-masked] <mailto:[email-masked]>  ;
[email-masked] <mailto:[email-masked]>  
Sent: Monday, February 11, 2002 8:24 AM
Subject: Scope of IPFIX (was Answer to the recent comments on the
Architecture Draft)

Group,
 
Cisco's interest in IPFIX  was to help establish a non-proprietary protocol
similar to netflow but more flexible allowing us to add value to our
customers (and do so in a timely manner).  If IPFIX goes down a path along
the lines as being advocated recent threads by Reinaldo,  it is unclear if
the added burden of the protocol will be make it worth the benefits of a
non-proprietary protocol.  Given it seems I have seen roughly the same
conversation occur 3 times in past several day, It is unclear if further
email discussion on this topic will resolve the underlying question as to
the scope of IPFIX.  It seems time for an official call on what is in/out of
scope for IPFIX.  As has been mentioned here multiple times we would like to
hear :  
- the exporter configuration is out of the scope of this document   (the
exporter configuration out of band)

- no transport negotiation (which transport)

 - no capability negotiation

Will

:So lets have a protocol which is more flexible as NetFlow version 
:1-7, 

I will not comment on that too much...Basically we are not here to
reverse-engineer Netflow, but to incorporate some good ideas from it.

:but not much more complicated, in order to be successfully 
:accepted by hardware vendors and application programmers. 

ohh, please...Then Netflow is just right? 

Reinaldo

---

From: "K.C. Norseth" <[email-masked]>
Date: Mon, 11 Feb 2002 22:11:25 -0700

Answer to the recent comments on the Architecture DraftHi Reinaldo,

Althoug it is a dream of all operators to have a common CLI, IPFIX would never happen if we wait for it to happen. Would the configuration be XML, Text, SNMP,COPS,?

K.C.

  ----- Original Message ----- 
  From: Reinaldo Penno 
  To: K.C. Norseth ; [email-masked] ; [email-masked] 
  Sent: Monday, February 11, 2002 9:57 PM
  Subject: RE: [ipfix] Re: Scope of IPFIX (was Answer to the recent comments on the Architecture Draft)

  Hello Norseth,
   
  I think the right question to answer is not if it is "necessary", since you can always pay somebody to be some sort of CLI configuration master and do everything by hand.  
  I think the right question is if it should be on the architecture document or not and with whihch level of compliance. 
   
  I think it should be on the arch document and maybe putting it with a SHOULD instead of a MUST will make (most) people happy.
   
  cheers,
   
  Reinaldo

   -----Original Message-----
  From: K.C. Norseth [mailto:[email-masked]]
  Sent: Monday, February 11, 2002 8:25 PM
  To: [email-masked]; [email-masked]
  Subject: [ipfix] Re: Scope of IPFIX (was Answer to the recent comments on the Architecture Draft)

    Will,

    | - the exporter configuration is out of the scope of this document   (the exporter configuration out of band)
     
    Configuration I think is out of scope, unless we hook it to an existing mib or something.  I so, we can refer to that mib or process.
    |- no transport negotiation (which transport)

    Nice, but necessary?  

    K.C.
      ----- Original Message ----- 
      From: Will Eatherton 
      To: Reinaldo Penno ; [email-masked] ; [email-masked] 
      Cc: [email-masked] ; [email-masked] ; [email-masked] 
      Sent: Monday, February 11, 2002 8:24 AM
      Subject: Scope of IPFIX (was Answer to the recent comments on the Architecture Draft)

      Group,
       
      Cisco's interest in IPFIX  was to help establish a non-proprietary protocol similar to netflow but more flexible allowing us to add value to our customers (and do so in a timely manner).  If IPFIX goes down a path along the lines as being advocated recent threads by Reinaldo,  it is unclear if the added burden of the protocol will be make it worth the benefits of a non-proprietary protocol.  Given it seems I have seen roughly the same conversation occur 3 times in past several day, It is unclear if further email discussion on this topic will resolve the underlying question as to the scope of IPFIX.  It seems time for an official call on what is in/out of scope for IPFIX.  As has been mentioned here multiple times we would like to hear :  
      - the exporter configuration is out of the scope of this document   (the exporter configuration out of band)

      Will

        I will not comment on that too much...Basically we are not here to reverse-engineer Netflow, but to incorporate some good ideas from it.

        Reinaldo

---

From: "Will Eatherton" <[email-masked]>
Date: Mon, 11 Feb 2002 21:37:12 -0800

Answer to the recent comments on the Architecture DraftLets be more clear
cut then this. I dont want to have a major architectural SHOULD on something
we believe is fundamentally flawed and will occupy signficant group time to
spec if it is left in.  We need a clear decision to move forward.  A spec
that includes SHOULDS for all proposed features is weak.

WIll
  -----Original Message-----
  From: majordomo listserver [mailto:[email-masked]]On Behalf
Of Reinaldo Penno
  Sent: Monday, February 11, 2002 8:57 PM
  To: K.C. Norseth; [email-masked]; [email-masked]
  Subject: RE: [ipfix] Re: Scope of IPFIX (was Answer to the recent comments
on the Architecture Draft)

  Hello Norseth,

  I think the right question to answer is not if it is "necessary", since
you can always pay somebody to be some sort of CLI configuration master and
do everything by hand.
  I think the right question is if it should be on the architecture document
or not and with whihch level of compliance.

  I think it should be on the arch document and maybe putting it with a
SHOULD instead of a MUST will make (most) people happy.

  cheers,

  Reinaldo

   -----Original Message-----
  From: K.C. Norseth [mailto:[email-masked]]
  Sent: Monday, February 11, 2002 8:25 PM
  To: [email-masked]; [email-masked]
  Subject: [ipfix] Re: Scope of IPFIX (was Answer to the recent comments on
the Architecture Draft)

    Will,

    | - the exporter configuration is out of the scope of this document
(the exporter configuration out of band)

    Configuration I think is out of scope, unless we hook it to an existing
mib or something.  I so, we can refer to that mib or process.
    |- no transport negotiation (which transport)

    Nice, but necessary?

    K.C.
      ----- Original Message -----
      From: Will Eatherton
      To: Reinaldo Penno ; [email-masked] ;
[email-masked]
      Cc: [email-masked] ; [email-masked] ;
[email-masked]
      Sent: Monday, February 11, 2002 8:24 AM
      Subject: Scope of IPFIX (was Answer to the recent comments on the
Architecture Draft)

      Group,

      Cisco's interest in IPFIX  was to help establish a non-proprietary
protocol similar to netflow but more flexible allowing us to add value to
our customers (and do so in a timely manner).  If IPFIX goes down a path
along the lines as being advocated recent threads by Reinaldo,  it is
unclear if the added burden of the protocol will be make it worth the
benefits of a non-proprietary protocol.  Given it seems I have seen roughly
the same conversation occur 3 times in past several day, It is unclear if
further email discussion on this topic will resolve the underlying question
as to the scope of IPFIX.  It seems time for an official call on what is
in/out of scope for IPFIX.  As has been mentioned here multiple times we
would like to hear :
      - the exporter configuration is out of the scope of this document
(the exporter configuration out of band)

      Will

        Reinaldo