Thanks Darren,
I was wondering about that. RFC 1761 is pretty
old and has only been referenced once (RFC2626) to
mention its Y2.038K problem (outside of the standard
list of Official Standards and request for comment RFCs).
Since the only packet capture technology mentioned in
recent RFC's has been tcpdump, I was thinking about
tackling the informational model by talking about tcpdump.
Hmmmm, ....., a comparison between snoop and tcpdump
may work as tcpdump does improve on the file format and the
information for each packet. I could then present that
we need to add the source identifier to the mix to make it
work for remote packet capture.
Does that sound like it would work?
Carter
Carter Bullard
QoSient, LLC
300 E. 56th Street, Suite 18K
New York, New York 10022
[EMAIL PROTECTED]
Phone +1 212 588-9133
Fax +1 212 588-9134
http://qosient.com
> -----Original Message-----
> From: Darren Reed [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, March 08, 2001 8:58 AM
> To: Carter Bullard
> Cc: [EMAIL PROTECTED]
> Subject: Re: [tcpdump-workers] IETF draft for remote packet capture
>
>
> In some email I received from Carter Bullard, sie wrote:
> > Gentle People,
> > I've submitted an IETF draft (I-D) that describes a
> > packet format for remote packet capture and I'd like to
> > get comments from this group. There are a number
> > of ideas in the draft, but the basic idea is to build
> > remote packet taps, but without the problems of RMON
> > packet capture or "port copy" schemes.
> >
> > http://www.ietf.org/internet-drafts/draft-bullard-pcap-01.txt
> >
> > I'm trying to address performance, privacy and
> > deployment problems in existing packet capture strategies.
> > If you get a chance to read it, and have any comments,
> > reactions, opinions, flames, whatever, I'd love to hear
> > them.
>
> Hmmm, I think you would do well to at discuss/reference the
> RFC on the snoop packet capture file format.
>
> Darren
>
