<div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">What is the process of getting new proposals merged with the <a href="https://github.com/pcapng/pcapng/blob/master/draft-tuexen-opsawg-pcapng.xml">https://github.com/pcapng/pcapng/blob/master/draft-tuexen-opsawg-pcapng.xml</a> draft?</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Is that that the proposal is discussed on this list and then a PR is submitted to the <a href="https://github.com/pcapng/pcapng">https://github.com/pcapng/pcapng</a> repository?</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Aug 14, 2016 at 12:25 AM, Guy Harris <span dir="ltr"><<a href="mailto:guy@alum.mit.edu" target="_blank">guy@alum.mit.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Aug 13, 2016, at 8:57 PM, Serge Aleynikov <<a href="mailto:serge@aleynikov.org">serge@aleynikov.org</a>> wrote:<br>
<br>
> ​So, with this revision, let's ​modify the layout of this option type, and also for the purpose of preserving alignment, let's keep the code/value 2 octets each:<br>
><br>
> ​ 0                   1                   2                   3<br>
>  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1<br>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<wbr>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<wbr>+-+-+<br>
> |0 0 1|      Option Code        |         Option Value          |<br>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<wbr>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<wbr>+-+-+<br>
><br>
> Hence, revised option codes become (with added apb_iface_id option):<br>
><br>
> Options:<br>
>    Name          Code    Length  Multiple?  Description<br>
>    apb_opt_size  0x2001  -       no         Total byte size of options<br>
>    apb_orig_len  0x2002  -       no         Packet's Original Length<br>
<br>
That means that the APB can't be used if the original length was > 65535.<br>
<br>
Preserving alignment for short options might not be *that* important if supporting packets > 65535 bytes in length *is* important.<br>
<br>
>>>    4-11     Compression type<br>
>>>                 0  = uncompressed<br>
>>>                 1  = lzw<br>
>>>                 2  = gzip<br>
>>>                 3  = bzip2<br>
>>>                 4  = zip<br>
>>>                 5  = 7z<br>
>>>                 6  = lzo<br>
>>>                 7  = ucl<br>
>>>                 8  = snappy<br>
>>>                 ...<br>
>><br>
>> So that indicates the form of compression used on the packet data?<br>
><br>
> ​Right, to conserve space, pcap-ng writing app​lication could choose to compress packets. One thought here is that perhaps that should be a file-level setting in the Interface Description Block rather than on the per-packet basis as proposed here?<br>
<br>
If there's no need to compress different packets with different compression mechanisms (or to compress some but not all packets), putting it in the IDB would make sense.<br>
<br>
However, that wouldn't apply to other block types - a file has to be readable by programs that don't understand that option, so the other block types can't support compression.<br>
<br>
>> There's no ​​FCS length field; do these packets have an FCS iff the "FCS length" field for interface 0's IDB is non-zero (so that all packets for that interface, whether they were transmitted by this host or received by this host, either have an FCS or don't have an FCS)?<br>
><br>
> ​Wouldn't that frame check sequence be part of the packet data?<br>
<br>
Yes, but there needs to be a way to indicate whether it's present, as it's not *always* part of the packet data.  For the EPB, there's both the IDB indication and a per-frame indication, in case either<br>
<br>
        1) the FCS length changes over time (e.g., if the presence or size are changed by negotiation in the middle of a PPP connection)<br>
<br>
or<br>
<br>
        2) not all frames have an FCS (e.g., if received frames have one but transmitted frames don't).<br>
<br>
For the SPB, the FCS must be present, or absent, in all frames, and, if it's present, it must have the same length in all frames, as there's no per-frame indication.<br>
<br>
For the APB, if there's no per-frame FCS indication, it must be present, or absent, in all frames, and, if it's present, it must have the same length in all frames.<br>
______________________________<wbr>_________________<br>
pcap-ng-format mailing list<br>
<a href="mailto:pcap-ng-format@winpcap.org">pcap-ng-format@winpcap.org</a><br>
<a href="https://www.winpcap.org/mailman/listinfo/pcap-ng-format" rel="noreferrer" target="_blank">https://www.winpcap.org/<wbr>mailman/listinfo/pcap-ng-<wbr>format</a></blockquote></div><br></div>