Subject: [ipfix] [issue] INFO-26 Section 7 of info-02 should be reworded

From: "Jeff Meyer" <[email-masked]>
Date: Mon, 26 Jan 2004 23:23:13 -0800

The current section 7 describes in general the benefits of an XML based 
information model,
some would say too much.  It does not describe any specific applications of 
this approach.

Specifically the ability to serialize as either XML or binary documents, 
collections of received
IPFIX flow records is a benefit.  This can be realized with existing open 
source tools from
IPDR.  Elaborating on how this connection can be established would be 
helpful to the
community, since persisting collected sets of flows is a common task in 
today's netflow
deployments.

-- Jeff Meyer

_________________________________________________________________
Find high-speed ‘net deals — comparison-shop your local providers here. 
https://broadband.msn.com

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

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 27 Jan 2004 09:41:19 +0000

Jeff Meyer wrote:
> some would say too much.  It does not describe any specific applications 
> of this approach.
> 
> IPFIX flow records is a benefit.  This can be realized with existing 
> open source tools from

Jeff

Section 7 contains no information necessary to implement the protocol
and should be deleted.

Assuming that we retain Appendix A, a synopsys of section 7 might be
used in the introduction to that appendix, but I don't think that
you really needs to say any more than "here is the definition
in XML".

If you think that an expanded version of section 7 is useful to
the IETF community, then I think that should go in a seperate
informational draft.

BTW the current intro to Appendix A says:

"The normative status of this appendix versus the section "Flow
Attributes" is a point of discussion.  The "Flow Attributes" section
is simply machine generated from the formal XML document below.  As
such using the formal XML document would seem preferable.  However
historical conventions and IETF's overall level of XML adoption may
lead to selection of the human readable text in the "Flow Attributes"
section as being preferable as normative."

This needs to be replaced with a simple statement saying either:

a) The text in the numeric sections of this draft/RFC is the
    normative text,

or

b) The XML desctiption in this appendix is the normative text.

thereby removing any ambigutity of the status of Appendix A.

- Stewart

---

From: Nevil Brownlee <[email-masked]>
Date: Thu, 29 Jan 2004 13:17:07 +1300

Hello all:

Following a long-running discussion between the Transport ADs and
some IPFIX WG members, we have the following test proposed for
the IPFIX protocol draft:

Section 5.x Transport Compliance and Transport Usage

  We must differentiate between what must be implemented (so that
  operators can interoperably deploy compliant implementations
  from different vendors) and what should or could be used in
  various operational environments. We must also make sure that ALL
  implementations can operate in a congention-aware and congestion
  avoiding mode.
  
  SCTP MUST be implemented by all compliant implementations.
  UDP and TCP MAY also be implemented by compliant implementations.

  SCTP SHOULD be used in deployments where exporters and collectors
  are communicating over links which are susceptible to congestion.

  TCP MAY be used in deployments where exporters and collectors
  communicate over links which are suscepible to congestion, but SCTP
  is preferred, due to its ability to limit back pressure on exporters
  (especially when using PR-SCTP) and its message vs. stream orientation.

  Other non-congestion aware protocols (like UDP) MAY be used in
  deployments where exporters and collectors always communicate over
  dedicated links which are not susceptible to congestion.

The 'MUST implement SCTP' reflects the WG consensus from our last
meeting in Minneapolis; seems to me that the challenge for WG 
members now is to write text for the 'how to implement IPFIX
on SCTP/TCP/UDP' sections of the protocol draft, and to work
on implementations.

Of course we don't have to have an implementation before the IPFIX
drafts are published, but having one (or better, two!) would help
things along.

Comments, suggestions, .. ?

Cheers, Nevil

-----------------------------------------------------------------------
   Nevil Brownlee                   Director, Technology Development
   Phone: +64 9 373 7599 x88941     ITSS, The University of Auckland
   FAX: +64 9 373 7021      Private Bag 92019, Auckland, New Zealand

-------------------------------------------------
This mail sent through University of Auckland
http://www.auckland.ac.nz/

---

From: Juergen Quittek <[email-masked]>
Date: Thu, 29 Jan 2004 12:42:01 +0100

Stewart,

I completely agree.  Section 7 should be merged into the appendix,
because it explains why the appendix is there at all.  I do not
see a reason for seaprating Section 7 from the appendix.

    Juergen

--On 27.01.2004 9:41 Uhr +0000 Stewart Bryant wrote:

>> Find high-speed ‘net deals ? comparison-shop your local providers here.