Re: [sip-clf] IETF 76 Minutes posted -> IPFIX questions

["Spencer Dawkins" <[e-mail]>]

Just to follow up on David's note to the mailing list...

David has been asked to act as our Technical Advisor (please see
http://tools.ietf.org/wg/sipclf/charters to confirm), so we need to take his
concerns seriously as we move forward.

The "how to have a successful BOF" document David referenced is RFC 5434,
"Considerations for Having a Successful Birds-of-a-Feather (BOF) Session".
Although this document was published as Informational, it's the best
guidance that the IESG has been able to provide to the community about how
to produce specifications that are approved by the community - if you
haven't already looked it over, you might want to spend a few minutes with
http://www.rfc-editor.org/rfc/rfc5434.txt.

Yes, we are post-BOF. No, these considerations don't disappear because we
had a "successful BOF", where "success" is defined as "we got a charter out
of the IESG" ;-)

If you have comments on
http://www.ietf.org/proceedings/09nov/minutes/sipclf.htm, please let me/Theo
know quickly. We're talking about next steps for the working group, and want
to have an accurate basis for that - and what you guys think happened in
Hiroshima is as important as what I think happened.

Thanks,

Spencer, as chair


> Hi,
>
> I have a concern with sipclf.
> I have been looking at "How to have a successful BOF":
>
> the goal of the
>   BOF is to demonstrate that the community has agreement that:
>
>      - there is a problem that needs solving, and the IETF is the
> right
>        group to attempt solving it.
>
>      - the scope of the problem is well defined and understood, that
>        is, people generally understand what the WG will work on (and
>        what it won't) and what its actual deliverables will be.
>
> Note the emphasis on what ***problem*** needs to be solved.
> The sipclf community decided "we need a logging file format"
> That is not a clear problem description; that is a solution - a
> partial solution.
>
> The members of the sipclf WG have very different problems they are
> trying to solve.
> Some want to dump everything so they can later grep to find entries.
> Some express concern about dumping everything and think maybe filters
> are needed to limit what gets dumped.
> Some want a dump from a single device.
> Some want to be able to reconstruct SIP conversations across multiple
> devices.
>
> I do not think the WG has consensus on what ***problem*** is being
> solved.
> The appropriate file format to use for a solution depends a lot on
> what problem you are trying to solve, and how the information will get
> used (and possibly moved).
>
> Some think the apache file format is a great starting place. I have
> concerns about modeling sipclf after a web-server logging format. Web
> servers typically run on hosts, with lots of CPU cycles and lots of
> disk storage. Very appropriate for logging EVERYTHING. Maybe I just
> don't know SIP well enough to understand the environments in which it
> runs. Where does SIP typically run? on hosts? on routers? on
> middleboxes? in embedded systems? Would these environments have the
> same resources that web server environments typically have?
>
> IPFIX may not be the right solution. But IPFIX has considered issues
> of CPU impact, limited storage, filters to select subsets of
> information to log, how to move the data off the box quickly, etc. The
> sipclf WG has not done that analysis because it is starting with a
> presumption of what they want for a solution, apparently without
> agreement on the problem to be solved.
>
> I question whether a simple ascii dump is the right answer. And I
> don't think the WG has done the necessary analysis of requirements
> based on the various problems to be solved, and the environments that
> must be supported.
>
> dbh