Re: [babel] info-model: message log

["STARK, BARBARA H" <[e-mail]>]

> Is that URL a stable referent?  Or might the wireshark folks change what is
> documented there (as they evolve).

They've been stable for 3 years and seem to understand that changing the "libpcap" format would not be a good thing because of its support in more than just wireshark. Rather, they've tried to evolve by defining a new format (pcapng).

> For an RFC, particularly for something we are mandating, the definition has to
> be stable.

Conditionally mandatory isn't quite the same as mandatory. The condition is "if creating a message log is supported". Supporting creation of a message log is optional. Also, there's a difference between (conditionally) mandatory to use vs. support. I'm only suggesting mandatory to support this file format. I think implementations need to be free to support (and use) other file formats, as well. 

But, I agree that stability is desirable.
As I see it, options are:
1. Decide anyway that the Wireshark reference is good enough for this purpose.
2. Define a different format (won't happen; not a real option)
3. Use a different already-defined stable format (doesn't exist; not a real option)
4. Copy the libpcap format definition into this draft (with proper attribution to Wireshark; would we need to get permission from Wireshark to copy it?)
5. Remove any and all suggestions that it might be possible for a message log to be generated (while I find message logs to be valuable in trouble-shooting and am aware of many devices that successfully provide such logs with apparent ease, I'm starting to think it's more trouble than it's worth to include one as an optional element in this info model)
6. Leave the optional message log but remove all mention of how to format the file (anybody who supports the message log is likely to use libpcap anyway, and this way there's no potentially-unstable references or plagiarized content in an IETF RFC; there is the danger of lack of interoperability)

I'm open to other options. So long as they're simple. If they aren't simple, I think option 5 is the best approach. I'm not willing to put a lot of effort into this.

Barbara

> Yours,
> Joel
> 
> On 1/3/19 5:42 PM, STARK, BARBARA H wrote:
> >>> I vote one format for implementation simplicity.  I do not really
> >>> know which one.
> >>
> >> pcap is much simpler.
> >
> > OK. And by "pcap", we mean libpcap per <url>
> > 
> > I'm fine with that.
> > "The libpcap file format
> (<url>) with ".pcap" file extension MUST be supported for message log
> files."? Note that supporting message log files is optional, so this is
> conditionally mandatory.
> >
> >> pcapng supports nanosecond timestamps, comments, vendor-defined
> TLVs,
> >> and bidirectional scanning.  While it looks reasonably easy to
> >> generate, it's a little more challenging to parse in its full
> >> generality.  Heck, even Wireshark doesn't :-/
> >>
> >> (Note that picking a dump format doesn't mean we can parse it --
> >> there's the small matter of the encapsulation used, which could be
> >> 802.2, radiotap, raw IPv6, or something else.  Do we need to specify
> >> that?)
> >
> > Encapsulation is the job of the management protocol. The info model will
> allow the file to be exposed either as a URL (in which case encapsulation is
> specified by that URL; e.g., "https:\\<router IP
> address>/mylogfiles/babellog.pcap") or as a file known to the info model
> that can be gotten using a management protocol operation.
> >
> > Barbara
> >
> > _______________________________________________
> > babel mailing list
> > [e-mail]