On Oct 26, 2021, at 11:57 AM, Michael Richardson wrote:
> LINKTYPE_USB_LINUX_MMAPPED220
> USB packets, beginning with a Linux USB header, as specified by the
> struct usbmon_packet in the Documentation/usb/usbmon.txt file in the
> Linux source tree. All 64 bytes of the
> On 26. Oct 2021, at 20:57, Michael Richardson wrote:
>
>
> Here is an example of a LINKTYPE that would be very difficult to explain if
> it weren't in the context of a pcap/pcapng file.
…
> LINKTYPE_USB_LINUX_MMAPPED220
> USB packets, beginning with a Linux USB header, as specified
Here is an example of a LINKTYPE that would be very difficult to explain if
it weren't in the context of a pcap/pcapng file.
If this goes into a new document, then would it have a normative?
informative? reference to... pcap and pcapng?
I was assuming that pcap and pcapng would wind up with
Carsten Bormann wrote:
>> That's being done by the pcap document.
>> (It could be done by a third document, but that seems wasteful)
> It seems appropriate to have a third document.
> I don’t see the waste, only process improvement.
I'm not convinced that the IESG review of the
PMFJI (and also for top-posting on a random email in the thread)
If your intention is to have an IANA registry, then please note that the
Independent Stream has a strong aversion to publishing documents that
create registries (see RFC 8726).
I leave it to the WG to decide whether a registry is
<#secure method=pgpmime mode=sign>
Qin Wu wrote:
cabo> One way to do this would be to jump-start the process by a short
cabo> document establishing this registry, with a defined registration
cabo> policy.
> [Qin] Good proposal, agree with this.
So the proposal, in order to
Carsten Bormann wrote:
> Pcapng is a format different from pcap.
> It’s a bit like IPv4 and IPv6.
And like IPv4 and IPv6, which happen to share TCP and UDP and therefore a
port number registry... pcap and pcapng share a linktype registry.
--
Michael Richardson. o O ( IPv6 IøT
On 26. Oct 2021, at 15:44, Michael Richardson wrote:
>
> That's being done by the pcap document.
> (It could be done by a third document, but that seems wasteful)
It seems appropriate to have a third document.
I don’t see the waste, only process improvement.
Grüße, Carsten
Guy Harris wrote:
> I would vote for "both should point to a common location" so that
> neither the pcap nor the pcapng spec says "there is *the* list of
> link-layer types" - it points to a registry, and as more types are
> added to the registry, more specs can be published
Qin Wu wrote:
> I am not against this draft. I am just thinking whether Independent
> submission stream process is a better choice for this document in the
> first round when WG and IESG have no change control to this work. Upon
> this work get published as RFC
>
> I have no idea what a second round would be.
> The pcap format needs to be published only once.
>
> [Qin Wu] My impression is that pcap will be the first and pcapng will derive
> from it. Maybe I am wrong, I am not clear
> the relation between these two.
These are independent formats that
-邮件原件-
发件人: Carsten Bormann [mailto:c...@tzi.org]
发送时间: 2021年10月26日 15:18
收件人: Guy Harris
抄送: Qin Wu ; opsawg@ietf.org
主题: Re: [OPSAWG] WG Adoption Call for draft-gharris-opsawg-pcap-02
On 26. Oct 2021, at 09:00, Guy Harris wrote:
>
> I would vote for "both should point to a common
On 25/10/2021 18.27, Michael Richardson wrote:
On 2021-10-20 12:40 p.m., Michael Richardson wrote:
On 2021-10-04 4:00 p.m., Henk Birkholz wrote:
Dear OPSAWG members,
this starts a call for Working Group Adoption of
https://datatracker.ietf.org/doc/html/draft-gharris-opsawg-pcap-02
-邮件原件-
发件人: Carsten Bormann [mailto:c...@tzi.org]
发送时间: 2021年10月26日 14:35
收件人: Qin Wu
抄送: opsawg@ietf.org
主题: Re: [OPSAWG] WG Adoption Call for draft-gharris-opsawg-pcap-02
Hi Qin,
On 26. Oct 2021, at 03:43, Qin Wu wrote:
>
> I am not against this draft. I am just thinking whether
On 26. Oct 2021, at 09:00, Guy Harris wrote:
>
> I would vote for "both should point to a common location" so that neither the
> pcap nor the pcapng spec says "there is *the* list of link-layer types" - it
> points to a registry, and as more types are added to the registry, more specs
> can
Dear OPSA WG,
We've uploaded a new version for the DMLMO draft:
https://datatracker.ietf.org/doc/draft-palmero-opsawg-dmlmo/
Main changes tracked under the "change log" section:
version 02
* "Support case" renamed to "incident".
* Add MAC address and IP address attributes under
On Oct 25, 2021, at 11:34 PM, Carsten Bormann wrote:
> No document here has to wait for any other document to be published.
Currently:
draft-gharris-opsawg-pcap-02 contains its own list of values for the
LinkType field in the file header;
draft-tuexen-opsawg-pcapng-02 points
Hi Qin,
On 26. Oct 2021, at 03:43, Qin Wu wrote:
>
> I am not against this draft. I am just thinking whether Independent
> submission stream process is a better choice for this document
I’m not sure which “this document” you are discussing here, as Michael asked
about both pcap and pcapng.
18 matches
Mail list logo