[OPSAWG]Re: AD review of draft-ietf-opsawg-pcap-08

[Mahesh Jethanandani <[e-mail]>]

[Resending with the correct email address]

> On Aug 6, 2026, at 9:47 PM, Mahesh Jethanandani <[e-mail]> wrote:
> 
> Hi Authors,
> 
> Thanks for working on this (historic) document. And thanks to Michael Tuexen for shepherding the document.
> 
> I have one MAJOR and several MINOR/NIT level comments that I believe will help improve the document.
> 
> ----------------------------------------------------------------------
> MAJOR
> ----------------------------------------------------------------------
> 
> Section 4.1, File Endian Information:
> 
> 274 >    *  0xA1,0xB2,0xC3,0xD4: little endian file, with timestamps in
> 275 >       seconds/microseconds.
> 276 >
> 277 >    *  0x1A,0x2B,0x3C,0x4D: little endian file, with timestamps in
> 278 >       seconds/nanoseconds.
> 279 >
> 280 >    *  0xD4,0xC3,0xB2,0xA1: big endian file, with timestamps in seconds/
> 281 >       microseconds.
> 282 >
> 283 >    *  0x4D,0x3C,0x2B,0x1A: big endian file, with timestamps in seconds/
> 284 >       nanoseconds.
> 
> The two nanosecond entries have the wrong bytes. Section 4 already gives the
> nanosecond magic number as 0xA1B23C4D (line 179-180). Decomposed into bytes
> that's A1,B2,3C,4D -- not 0x1A,0x2B,0x3C,0x4D as written here. The document's
> own contact for this format, tcpdump.org's pcap-savefile(5) man page, spells
> this out explicitly: Both nanosecond bullets here seem to have had the first two 
> bytes nibble-swapped (A1->1A, B2->2B in one case; the same error shows up 
> reversed in the other). The microsecond entries immediately above and below 
> them are correct.
> 
> I'd ask the authors to fix both nanosecond bullets to match the byte
> sequences in pcap-savefile(5) before this moves forward.
> 
> s/0x1A,0x2B,0x3C,0x4D/0xA1,0xB2,0x3C,0x4D/
> s/0x4D,0x3C,0x2B,0x1A/0x4D,0x3C,0xB2,0xA1/
> 
> ----------------------------------------------------------------------
> MINOR
> ----------------------------------------------------------------------
> 
> Section 4, R bit and Reserved3:
> 
> 252 >    R (1 bit):  not used - MUST be set to zero by pcap writers, and MUST
> 253 >       NOT be interpreted by pcap readers; a reader SHOULD treat a non-
> 254 >       zero value as an error.
> 
> 260 >    Reserved3 (10 bits):  not used - MUST be set to zero by pcap writers,
> 261 >       and MUST NOT be interpreted by pcap readers; a reader SHOULD treat
> 262 >       a non-zero value as an error.
> 
> Both of these say a reader MUST NOT interpret the bit(s), then in the next
> clause say a reader SHOULD treat a non-zero value as an error -- which isn't
> possible without looking at the value, i.e. interpreting it.  I'd suggest either dropping 
> the "SHOULD treat... as an error” sentence from R and Reserved3, or replacing “
> MUST NOT be interpreted” with something like "carries no defined meaning."
> 
> ---
> 
> Section 8.1.1, application/pcap registration template:
> 
> 420 >     Encoding considerations:  PCAP files contain network packets
> 421 >     Security considerations:  See Security Considerations, Section
> 422 >     Interoperability considerations:  The format is designed to be broadly interoperable.
> 
> "Encoding considerations" in an RFC 6838 media type template is
> supposed to describe what transfer/content encoding the format needs (a
> value like "binary," or a pointer to a section describing that) -- not what
> the format contains. "PCAP files contain network packets" answers a
> different question than the one the field asks. I'd suggest something like
> "binary" here instead.
> 
> ---
> 
> Section 7, Security Considerations / Section 8.1.1:
> 
> 402 >    See also: https://www.iana.org/assignments/media-types/application/
> 403 >    vnd.tcpdump.pcap
> 
> This pointer to the existing vendor-tree registration sits in Security
> Considerations, but it's really about the relationship between the new
> standards-tree application/pcap registration being requested here and the
> pre-existing application/vnd.tcpdump.pcap entry -- which is exactly the kind
> of thing the shepherd write-up also flagged (item 20). I'd move this note
> into Section 8.1.1 alongside the registration template, and add a sentence
> saying explicitly whether application/pcap is intended to supersede the
> vendor-tree entry, coexist with it, or something else. As it stands a reader
> of Security Considerations has no idea why a vendor-tree media type is being
> mentioned there.
> 
> ---
> 
> Section 8.1.1, Change controller:
> 
> 433 >     Change controller:  The Tcpdump Group
> 
> Since this registration is being requested by an IETF-stream RFC, I'd have
> expected "IETF" here per the usual convention for RFC-defined media types,
> unless there's a deliberate reason to leave ongoing stewardship with the
> Tcpdump Group instead (which, given the Historic intended status and the
> fact that this format is frozen, may well be the right call). I'd just ask
> the authors to confirm this was a deliberate choice rather than a template
> default that didn't get updated.
> 
> ----------------------------------------------------------------------
> NIT
> ----------------------------------------------------------------------
> 
> All comments below are about very minor potential issues that you may
> choose to address in some way - or ignore - as you see fit.
> 
> Section 2, Terminology:
> 
> 122 >    This document uses the term octet in a way consistent with the word
> 123 >    "byte"
> 
> Missing closing period.
> 
> s/"byte"/"byte"./
> 
> ---
> 
> Section 1, Introduction:
> 
> 109 >    More significantly, pcap v2 files can only contain packets in a
> 110 >    single LINKTYPE format, and this often means that packets are often
> 111 >    from a single network interface as not all LINKTYPEs include a way to
> 112 >    indicate which interface a packet is from.
> 
> "often ... are often" reads redundantly.
> 
> s/this often means that packets are often from/this often means that packets are from/
> 
> ---
> 
> Section 3, General File Structure:
> 
> 136 >    The approach of having the file written in the native format of the
> 137 >    host writing the file is more efficient because it avoids translation
> 138 >    of data when writing the file or reading the file on the host that
> 139 >    wrote the file, which is the most common case when generating or
> 140 >    processing capture captures.
> 
> "capture captures" duplicates a word.
> 
> s/processing capture captures/processing captures/
> 
> ---
> 
> Section 3, General File Structure:
> 
> 142 >    When hosts with a different native endian format read a file, they
> 143 >    must swap octets as appropriate.  This is less efficient, but less
> 144 >    common, and if repeated access to the files are important, then files
> 145 >    can be translated and saved.
> 
> Subject-verb agreement: "access... are" should be "access... is."
> 
> s/repeated access to the files are important/repeated access to the files is important/
> 
> Thanks..
> 
> Mahesh Jethanandani
> [e-mail]
> 
> 
> 
> 
> 
> 


Mahesh Jethanandani
[e-mail]