Re: [OPSAWG] đź”” WG Adoption Call for draft-tuexen-opsawg-pcapng-05 and draft-richardson-opsawg-pcaplinktype-01
> On 8. Dec 2022, at 21:34, Henk Birkholz > wrote: > > Dear OPSAWG members, > > this starts a Working Group Adoption call for a bundle of two documents: > >> https://www.ietf.org/archive/id/draft-tuexen-opsawg-pcapng-05.html >> https://www.ietf.org/archive/id/draft-richardson-opsawg-pcaplinktype-01.html > > ending on Monday, December 30th. > > As a recap: we already went through a first WGLC for > draft-tuexen-opsawg-pcapng-03 and this is the second WGLC. The last WGLC did > not yield a critical mass of active support. > > Since the last WGLC, two relevant decisions were made: > > 1.) The Intended Status of the main document draft-tuexen-opsawg-pcapng is > now Informational. > > 2.) The draft-richardson-opsawg-pcaplinktype document was split from the main > documents, focuses solely on the PCAP LINK Type registry content, and retains > the Intended Status Standards Track (as informational documents cannot > request a registry). > > As a generic reminder, these internet drafts describe the PCAPng format and > its corresponding registry - retaining the established design patterns of > PCAP and adding new capabilities as well as a an extensibility feature. > Please note that the corresponding document > https://www.ietf.org/archive/id/draft-ietf-opsawg-pcap-01.html was adopted in > October 2021 and its Intended Status is Historical. > > Please reply with your active support (+1 required) or objections and > especially any substantive comments you may have. +1. (Obvious at least for one document, since I'm a co-author). Best regards Michael > > For the OPSAWG co-chairs, > > Henk > > ___ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] đź”” WG Adoption Call for draft-tuexen-opsawg-pcapng-05 and draft-richardson-opsawg-pcaplinktype-01
From: OPSAWG on behalf of Henk Birkholz Sent: 08 December 2022 20:34 Dear OPSAWG members, this starts a Working Group Adoption call for a bundle of two documents: > https://www.ietf.org/archive/id/draft-tuexen-opsawg-pcapng-05.html > https://www.ietf.org/archive/id/draft-richardson-opsawg-pcaplinktype-01.html ending on Monday, December 30th. Henk As December 30th is gets closer it is looking less like a Monday to me; I like the idea of CoB on Monday and have penciled that into my brain as a deadline Tom Petch As a recap: we already went through a first WGLC for draft-tuexen-opsawg-pcapng-03 and this is the second WGLC. The last WGLC did not yield a critical mass of active support. Since the last WGLC, two relevant decisions were made: 1.) The Intended Status of the main document draft-tuexen-opsawg-pcapng is now Informational. 2.) The draft-richardson-opsawg-pcaplinktype document was split from the main documents, focuses solely on the PCAP LINK Type registry content, and retains the Intended Status Standards Track (as informational documents cannot request a registry). As a generic reminder, these internet drafts describe the PCAPng format and its corresponding registry - retaining the established design patterns of PCAP and adding new capabilities as well as a an extensibility feature. Please note that the corresponding document https://www.ietf.org/archive/id/draft-ietf-opsawg-pcap-01.html was adopted in October 2021 and its Intended Status is Historical. Please reply with your active support (+1 required) or objections and especially any substantive comments you may have. For the OPSAWG co-chairs, Henk ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] đź”” WG Adoption Call for draft-tuexen-opsawg-pcapng-05 and draft-richardson-opsawg-pcaplinktype-01
> On 8. Dec 2022, at 21:34, Henk Birkholz > wrote: > > Dear OPSAWG members, > > this starts a Working Group Adoption call for a bundle of two documents: > >> https://www.ietf.org/archive/id/draft-tuexen-opsawg-pcapng-05.html >> https://www.ietf.org/archive/id/draft-richardson-opsawg-pcaplinktype-01.html > > ending on Monday, December 30th. > > As a recap: we already went through a first WGLC for > draft-tuexen-opsawg-pcapng-03 and this is the second WGLC. The last WGLC did > not yield a critical mass of active support. Hi Henk, just a clarification question: you are referring to a WGLC in the past. As far as I know, the document has not been accepted as a WG document. That is why it still has draft-tuexen in its name. Are you referring to an adoption call instead of WGLC? Best regards Michael > > Since the last WGLC, two relevant decisions were made: > > 1.) The Intended Status of the main document draft-tuexen-opsawg-pcapng is > now Informational. > > 2.) The draft-richardson-opsawg-pcaplinktype document was split from the main > documents, focuses solely on the PCAP LINK Type registry content, and retains > the Intended Status Standards Track (as informational documents cannot > request a registry). > > As a generic reminder, these internet drafts describe the PCAPng format and > its corresponding registry - retaining the established design patterns of > PCAP and adding new capabilities as well as a an extensibility feature. > Please note that the corresponding document > https://www.ietf.org/archive/id/draft-ietf-opsawg-pcap-01.html was adopted in > October 2021 and its Intended Status is Historical. > > Please reply with your active support (+1 required) or objections and > especially any substantive comments you may have. > > For the OPSAWG co-chairs, > > Henk > > ___ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] đź”” WG Adoption Call for draft-tuexen-opsawg-pcapng-05 and draft-richardson-opsawg-pcaplinktype-01
Hi Tom, Hi Michael, hi all, thanks for your help! As I am continuously challenged by reading my own calendar properly, replies for this Working Group Call for Adoption may drizzle in until Monday (and then some, as I am not sure how many folks will look at this on Jan 1st). In essence, we can relax the deadline a bit as there are probably more important things to plan for this weekend! Also, Michael is correct. This is just about adoption: OLD: Since the last WGLC NEW: Since the last WGAC (Working Group Call for Adoption) A Happy New year to all of you! Henk On 28.12.22 19:46, Michael Tuexen wrote: On 8. Dec 2022, at 21:34, Henk Birkholz wrote: Dear OPSAWG members, this starts a Working Group Adoption call for a bundle of two documents: https://www.ietf.org/archive/id/draft-tuexen-opsawg-pcapng-05.html https://www.ietf.org/archive/id/draft-richardson-opsawg-pcaplinktype-01.html ending on Monday, December 30th. As a recap: we already went through a first WGLC for draft-tuexen-opsawg-pcapng-03 and this is the second WGLC. The last WGLC did not yield a critical mass of active support. Hi Henk, just a clarification question: you are referring to a WGLC in the past. As far as I know, the document has not been accepted as a WG document. That is why it still has draft-tuexen in its name. Are you referring to an adoption call instead of WGLC? Best regards Michael Since the last WGLC, two relevant decisions were made: 1.) The Intended Status of the main document draft-tuexen-opsawg-pcapng is now Informational. 2.) The draft-richardson-opsawg-pcaplinktype document was split from the main documents, focuses solely on the PCAP LINK Type registry content, and retains the Intended Status Standards Track (as informational documents cannot request a registry). As a generic reminder, these internet drafts describe the PCAPng format and its corresponding registry - retaining the established design patterns of PCAP and adding new capabilities as well as a an extensibility feature. Please note that the corresponding document https://www.ietf.org/archive/id/draft-ietf-opsawg-pcap-01.html was adopted in October 2021 and its Intended Status is Historical. Please reply with your active support (+1 required) or objections and especially any substantive comments you may have. For the OPSAWG co-chairs, Henk ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] đź”” WG Adoption Call for draft-tuexen-opsawg-pcapng-05 and draft-richardson-opsawg-pcaplinktype-01
> On 29. Dec 2022, at 12:18, Henk Birkholz > wrote: > > Hi Tom, > Hi Michael, > hi all, > > thanks for your help! > > As I am continuously challenged by reading my own calendar properly, replies > for this Working Group Call for Adoption may drizzle in until Monday (and > then some, as I am not sure how many folks will look at this on Jan 1st). In > essence, we can relax the deadline a bit as there are probably more important > things to plan for this weekend! > > Also, Michael is correct. This is just about adoption: > > OLD: > Since the last WGLC > > NEW: > Since the last WGAC (Working Group Call for Adoption) Thanks a lot for the clarification. > > > A Happy New year to all of you! Happy New Year for you. Best regards Michael > > Henk > > > On 28.12.22 19:46, Michael Tuexen wrote: >>> On 8. Dec 2022, at 21:34, Henk Birkholz >>> wrote: >>> >>> Dear OPSAWG members, >>> >>> this starts a Working Group Adoption call for a bundle of two documents: >>> https://www.ietf.org/archive/id/draft-tuexen-opsawg-pcapng-05.html https://www.ietf.org/archive/id/draft-richardson-opsawg-pcaplinktype-01.html >>> >>> ending on Monday, December 30th. >>> >>> As a recap: we already went through a first WGLC for >>> draft-tuexen-opsawg-pcapng-03 and this is the second WGLC. The last WGLC >>> did not yield a critical mass of active support. >> Hi Henk, >> just a clarification question: >> you are referring to a WGLC in the past. As far as I know, the document has >> not been >> accepted as a WG document. That is why it still has draft-tuexen in its name. >> Are you referring to an adoption call instead of WGLC? >> Best regards >> Michael >>> >>> Since the last WGLC, two relevant decisions were made: >>> >>> 1.) The Intended Status of the main document draft-tuexen-opsawg-pcapng is >>> now Informational. >>> >>> 2.) The draft-richardson-opsawg-pcaplinktype document was split from the >>> main documents, focuses solely on the PCAP LINK Type registry content, and >>> retains the Intended Status Standards Track (as informational documents >>> cannot request a registry). >>> >>> As a generic reminder, these internet drafts describe the PCAPng format and >>> its corresponding registry - retaining the established design patterns of >>> PCAP and adding new capabilities as well as a an extensibility feature. >>> Please note that the corresponding document >>> https://www.ietf.org/archive/id/draft-ietf-opsawg-pcap-01.html was adopted >>> in October 2021 and its Intended Status is Historical. >>> >>> Please reply with your active support (+1 required) or objections and >>> especially any substantive comments you may have. >>> >>> For the OPSAWG co-chairs, >>> >>> Henk >>> >>> ___ >>> OPSAWG mailing list >>> OPSAWG@ietf.org >>> https://www.ietf.org/mailman/listinfo/opsawg ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] đź”” WG Adoption Call for draft-tuexen-opsawg-pcapng-05 and draft-richardson-opsawg-pcaplinktype-01
From: OPSAWG on behalf of Henk Birkholz Sent: 08 December 2022 20:34 Dear OPSAWG members, this starts a Working Group Adoption call for a bundle of two documents: > https://www.ietf.org/archive/id/draft-tuexen-opsawg-pcapng-05.html > https://www.ietf.org/archive/id/draft-richardson-opsawg-pcaplinktype-01.html Not Ready The linktype I-D is defective with its documentary references so the website is going to be as well. The number of references for links is considerable in the I-D although none appear as references of the I-D as anyone familiar with the work of the IETF would expect. Bringing this up to the standard expected of an IETF document would be considerable and it is not clear to me if it should be attempted. The only good news is that the tcpdump website is accessible, although its omission from the I-D references puzzles me. The list of linktypes in the I-D is at odds with that on the website. The website does in many cases give an adequate reference such as a URL to an IEEE, ISO, ITU-T or IBM resource. In other cases it does not as for example for IPv4 or IPv6 or IEEE 802.5 or it refers to a private website. The I-D needs to acknowledge its deficiencies with respect to references. Whether it should try to provide references at all I am uncertain. It could enhance the website but I do not see it ever replacing the website. The I-D also needs to clarify what to do when the website and the IANA registry conflist I think that this needs an executive decision. If the IETF cannot produce a specification to its usual standards, how far should it go? In passing, 65000 appears in two ranges. Tom Petch ending on Monday, December 30th. As a recap: we already went through a first WGLC for draft-tuexen-opsawg-pcapng-03 and this is the second WGLC. The last WGLC did not yield a critical mass of active support. Since the last WGLC, two relevant decisions were made: 1.) The Intended Status of the main document draft-tuexen-opsawg-pcapng is now Informational. 2.) The draft-richardson-opsawg-pcaplinktype document was split from the main documents, focuses solely on the PCAP LINK Type registry content, and retains the Intended Status Standards Track (as informational documents cannot request a registry). As a generic reminder, these internet drafts describe the PCAPng format and its corresponding registry - retaining the established design patterns of PCAP and adding new capabilities as well as a an extensibility feature. Please note that the corresponding document https://www.ietf.org/archive/id/draft-ietf-opsawg-pcap-01.html was adopted in October 2021 and its Intended Status is Historical. Please reply with your active support (+1 required) or objections and especially any substantive comments you may have. For the OPSAWG co-chairs, Henk ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] đź”” WG Adoption Call for draft-tuexen-opsawg-pcapng-05 and draft-richardson-opsawg-pcaplinktype-01
On 2022-12-29, at 12:55, tom petch wrote: > > The linktype I-D is defective with its documentary references so the > website is going to be as well. The number of references for links is > considerable in the I-D although none appear as references of the I-D as > anyone familiar with the work of the IETF would expect. Hmm. The registry has four columns, of which the fourth is the "document/requestor reference" column. The draft does not say, but to me implies, that this column will be populated with a reference to the linktypes RFC for all rows in the initial set. I’m no quite sure what Tom is trying to say with “The number…” but it would be good to have references to the documents that supply further information (say, what “IEEE 802.3 Ethernet” really is). Having these listed at "http://www.tcpdump.org/linktypes.html” is fine with me; this will allow updates to the document references as these tend to shift over time. Having them added in the fourth column of the IANA registry is also fine, but sounds a bit like busywork to me. All this editorial work can be done after adoption by the working group. Re the pcapng document itself, I’m not sure that Figure 3 to 6 should really use bit tick marks (+-+-+), as these seem to be multi-byte passages shown as if they were three (or four to six) bits each. It has been a couple of years since I reviewed a version of this document, and I’d rather have the iddiff bugs fixed before I re-review the current version, but I’m quite confident that we can fix the remaining problems in normal WG work (of which there will be some — no, I’m not responding to a WGLC here). So, repeating and updating my affirmative response from 2021-10-20 [1]: +1 from me for adopting both documents. Grüße, Carsten [1]: https://mailarchive.ietf.org/arch/msg/opsawg/8BEuzv9VaDs_RIantEPKRGtK-KE ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] đź”” WG Adoption Call for draft-tuexen-opsawg-pcapng-05 and draft-richardson-opsawg-pcaplinktype-01
From: Carsten Bormann Sent: 29 December 2022 13:20 On 2022-12-29, at 12:55, tom petch wrote: > > The linktype I-D is defective with its documentary references so the > website is going to be as well. The number of references for links is > considerable in the I-D although none appear as references of the I-D as > anyone familiar with the work of the IETF would expect. Hmm. The registry has four columns, of which the fourth is the "document/requestor reference" column. The draft does not say, but to me implies, that this column will be populated with a reference to the linktypes RFC for all rows in the initial set. I’m no quite sure what Tom is trying to say with “The number…” but it would be good to have references to the documents that supply further information (say, what “IEEE 802.3 Ethernet” really is). Having these listed at "http://www.tcpdump.org/linktypes.html” is fine with me; this will allow updates to the document references as these tend to shift over time. Having them added in the fourth column of the IANA registry is also fine, but sounds a bit like busywork to me. The underlying question is what is the point of this IANA registry? 1) Duplicate the contents of the tcpdump website so that there are two sources of information which differ slightly and so make it unclear as to which is right? 2) Replace the tcpdump website with one that does not include any of the many URLs that the tcpdump website and so is not so useful? 3) Augment the tcpdump website with some additional linktypes but without indicating where the tcpdump website is the authoritative source? I do not know. Hence oppose adoption. Tom Petch All this editorial work can be done after adoption by the working group. Re the pcapng document itself, I’m not sure that Figure 3 to 6 should really use bit tick marks (+-+-+), as these seem to be multi-byte passages shown as if they were three (or four to six) bits each. It has been a couple of years since I reviewed a version of this document, and I’d rather have the iddiff bugs fixed before I re-review the current version, but I’m quite confident that we can fix the remaining problems in normal WG work (of which there will be some — no, I’m not responding to a WGLC here). So, repeating and updating my affirmative response from 2021-10-20 [1]: +1 from me for adopting both documents. Grüße, Carsten [1]: https://mailarchive.ietf.org/arch/msg/opsawg/8BEuzv9VaDs_RIantEPKRGtK-KE ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] đź”” WG Adoption Call for draft-tuexen-opsawg-pcapng-05 and draft-richardson-opsawg-pcaplinktype-01
> On 29. Dec 2022, at 17:45, tom petch wrote: > > From: Carsten Bormann > Sent: 29 December 2022 13:20 > > On 2022-12-29, at 12:55, tom petch wrote: >> >> The linktype I-D is defective with its documentary references so the >> website is going to be as well. The number of references for links is >> considerable in the I-D although none appear as references of the I-D as >> anyone familiar with the work of the IETF would expect. > > Hmm. The registry has four columns, of which the fourth is the > "document/requestor reference" column. > > The draft does not say, but to me implies, that this column will be populated > with a reference to the linktypes RFC for all rows in the initial set. > > I’m no quite sure what Tom is trying to say with “The number…” but it would > be good to have references to the documents that supply further information > (say, what “IEEE 802.3 Ethernet” really is). > Having these listed at "http://www.tcpdump.org/linktypes.html” is fine with > me; this will allow updates to the document references as these tend to shift > over time. Having them added in the fourth column of the IANA registry is > also fine, but sounds a bit like busywork to me. > > > The underlying question is what is the point of this IANA registry? > > 1) Duplicate the contents of the tcpdump website so that there are two > sources of information which differ slightly and so make it unclear as to > which is right? > > 2) Replace the tcpdump website with one that does not include any of the many > URLs that the tcpdump website and so is not so useful? > > 3) Augment the tcpdump website with some additional linktypes but without > indicating where the tcpdump website is the authoritative source? The plan is to move the registry from the tcpdump website to IANA and use the currently defined values at the tcpdump website as the initial value for the IANA table. Once this is done, the table hosted at the IANA website will be the only source of truth for this registry. Does this make the intention clearer? Best regards Michael > > I do not know. Hence oppose adoption. > > Tom Petch > > All this editorial work can be done after adoption by the working group. > > Re the pcapng document itself, I’m not sure that Figure 3 to 6 should really > use bit tick marks (+-+-+), as these seem to be multi-byte passages shown as > if they were three (or four to six) bits each. It has been a couple of years > since I reviewed a version of this document, and I’d rather have the iddiff > bugs fixed before I re-review the current version, but I’m quite confident > that we can fix the remaining problems in normal WG work (of which there will > be some — no, I’m not responding to a WGLC here). > > So, repeating and updating my affirmative response from 2021-10-20 [1]: > +1 from me for adopting both documents. > > Grüße, Carsten > > [1]: https://mailarchive.ietf.org/arch/msg/opsawg/8BEuzv9VaDs_RIantEPKRGtK-KE > > ___ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] đź”” WG Adoption Call for draft-tuexen-opsawg-pcapng-05 and draft-richardson-opsawg-pcaplinktype-01
> OPSAWG on behalf of Henk Birkholz > writes: > Not Ready That wasn't the question Tom. This is not a WGLC. This is a WG adoption call. by replying, I think you have indicated that you are interested in the WG taking on this work? > The linktype I-D is defective with its documentary references so the > website is going to be as well. The number of references for links is > considerable in the I-D although none appear as references of the I-D > as anyone familiar with the work of the IETF would expect. Bringing > this up to the standard expected of an IETF document would be > considerable and it is not clear to me if it should be attempted. I have simply no idea what you are saying. Are you asking for every single entry in the registry to be documented to IETF Specification Required level? These are historical entries which were registered, essentially on a First-Come First-Served basis. > The I-D needs to acknowledge its deficiencies with respect to > references. Whether it should try to provide references at all I am > uncertain. It could enhance the website but I do not see it ever > replacing the website. > The I-D also needs to clarify what to do when the website and the IANA > registry conflist The web site content will go away, and/or reference the IANA. > I think that this needs an executive decision. If the IETF cannot > produce a specification to its usual standards, how far should it go? > In passing, 65000 appears in two ranges. Yes. [32678,65000) then. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] đź”” WG Adoption Call for draft-tuexen-opsawg-pcapng-05 and draft-richardson-opsawg-pcaplinktype-01
From: Michael Tuexen Sent: 29 December 2022 17:13 > On 29. Dec 2022, at 17:45, tom petch wrote: > > From: Carsten Bormann > Sent: 29 December 2022 13:20 > > On 2022-12-29, at 12:55, tom petch wrote: >> >> The linktype I-D is defective with its documentary references so the >> website is going to be as well. The number of references for links is >> considerable in the I-D although none appear as references of the I-D as >> anyone familiar with the work of the IETF would expect. > > Hmm. The registry has four columns, of which the fourth is the > "document/requestor reference" column. > > The draft does not say, but to me implies, that this column will be populated > with a reference to the linktypes RFC for all rows in the initial set. > > I’m no quite sure what Tom is trying to say with “The number…” but it would > be good to have references to the documents that supply further information > (say, what “IEEE 802.3 Ethernet” really is). > Having these listed at "http://www.tcpdump.org/linktypes.html” is fine with > me; this will allow updates to the document references as these tend to shift > over time. Having them added in the fourth column of the IANA registry is > also fine, but sounds a bit like busywork to me. > > > The underlying question is what is the point of this IANA registry? > > 1) Duplicate the contents of the tcpdump website so that there are two > sources of information which differ slightly and so make it unclear as to > which is right? > > 2) Replace the tcpdump website with one that does not include any of the many > URLs that the tcpdump website and so is not so useful? > > 3) Augment the tcpdump website with some additional linktypes but without > indicating where the tcpdump website is the authoritative source? The plan is to move the registry from the tcpdump website to IANA and use the currently defined values at the tcpdump website as the initial value for the IANA table. Once this is done, the table hosted at the IANA website will be the only source of truth for this registry. Does this make the intention clearer? Yes, that is clear; I do not see any such statement in the I-D. It also seems to be a giant leap backwards. The tcpdump website has a mass of useful information, 150 or so links to the reference documents for the link protocols that it references which could be useful outside the context of tcpdump, while the I-D, and I assume the IANA registry, has not one, not single reference - to me that is, well, a giant leap backwards. Tom Petch Best regards Michael > > I do not know. Hence oppose adoption. > > Tom Petch > > All this editorial work can be done after adoption by the working group. > > Re the pcapng document itself, I’m not sure that Figure 3 to 6 should really > use bit tick marks (+-+-+), as these seem to be multi-byte passages shown as > if they were three (or four to six) bits each. It has been a couple of years > since I reviewed a version of this document, and I’d rather have the iddiff > bugs fixed before I re-review the current version, but I’m quite confident > that we can fix the remaining problems in normal WG work (of which there will > be some — no, I’m not responding to a WGLC here). > > So, repeating and updating my affirmative response from 2021-10-20 [1]: > +1 from me for adopting both documents. > > Grüße, Carsten > > [1]: https://mailarchive.ietf.org/arch/msg/opsawg/8BEuzv9VaDs_RIantEPKRGtK-KE > > ___ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] đź”” WG Adoption Call for draft-tuexen-opsawg-pcapng-05 and draft-richardson-opsawg-pcaplinktype-01
> On 30. Dec 2022, at 12:41, tom petch wrote: > > From: Michael Tuexen > Sent: 29 December 2022 17:13 > >> On 29. Dec 2022, at 17:45, tom petch wrote: >> >> From: Carsten Bormann >> Sent: 29 December 2022 13:20 >> >> On 2022-12-29, at 12:55, tom petch wrote: >>> >>> The linktype I-D is defective with its documentary references so the >>> website is going to be as well. The number of references for links is >>> considerable in the I-D although none appear as references of the I-D as >>> anyone familiar with the work of the IETF would expect. >> >> Hmm. The registry has four columns, of which the fourth is the >> "document/requestor reference" column. >> >> The draft does not say, but to me implies, that this column will be >> populated with a reference to the linktypes RFC for all rows in the initial >> set. >> >> I’m no quite sure what Tom is trying to say with “The number…” but it would >> be good to have references to the documents that supply further information >> (say, what “IEEE 802.3 Ethernet” really is). >> Having these listed at "http://www.tcpdump.org/linktypes.html” is fine with >> me; this will allow updates to the document references as these tend to >> shift over time. Having them added in the fourth column of the IANA >> registry is also fine, but sounds a bit like busywork to me. >> >> >> The underlying question is what is the point of this IANA registry? >> >> 1) Duplicate the contents of the tcpdump website so that there are two >> sources of information which differ slightly and so make it unclear as to >> which is right? >> >> 2) Replace the tcpdump website with one that does not include any of the >> many URLs that the tcpdump website and so is not so useful? >> >> 3) Augment the tcpdump website with some additional linktypes but without >> indicating where the tcpdump website is the authoritative source? > The plan is to move the registry from the tcpdump website to IANA and use the > currently defined values > at the tcpdump website as the initial value for the IANA table. > > Once this is done, the table hosted at the IANA website will be the only > source of truth for this > registry. > > Does this make the intention clearer? > > > > Yes, that is clear; I do not see any such statement in the I-D. OK. That can be addressed... But let us separate two questions: (1) Should this document be adopted as a WG document? (2) How could this document be improved? I think these questions are independent. This document can be improved during the time after the WG adoption and the end of the WGLC. Most of the times the documents improve even further during IESG last call. > > It also seems to be a giant leap backwards. The tcpdump website has a mass > of useful information, 150 or so links to the reference documents for the > link protocols that it references which could be useful outside the context > of tcpdump, while the I-D, and I assume the IANA registry, has not one, not > single reference - to me that is, well, a giant leap backwards. The IANA registry will have a reference to the web page for each old entry. But if you suggest that the links should be integrated, this can be discussed. So the question which still needs to be answered is (1). Any opinion? Best regards Michael > > Tom Petch > > Best regards > Michael >> >> I do not know. Hence oppose adoption. >> >> Tom Petch >> >> All this editorial work can be done after adoption by the working group. >> >> Re the pcapng document itself, I’m not sure that Figure 3 to 6 should really >> use bit tick marks (+-+-+), as these seem to be multi-byte passages shown as >> if they were three (or four to six) bits each. It has been a couple of >> years since I reviewed a version of this document, and I’d rather have the >> iddiff bugs fixed before I re-review the current version, but I’m quite >> confident that we can fix the remaining problems in normal WG work (of which >> there will be some — no, I’m not responding to a WGLC here). >> >> So, repeating and updating my affirmative response from 2021-10-20 [1]: >> +1 from me for adopting both documents. >> >> Grüße, Carsten >> >> [1]: https://mailarchive.ietf.org/arch/msg/opsawg/8BEuzv9VaDs_RIantEPKRGtK-KE >> >> ___ >> OPSAWG mailing list >> OPSAWG@ietf.org >> https://www.ietf.org/mailman/listinfo/opsawg > ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] đź”” WG Adoption Call for draft-tuexen-opsawg-pcapng-05 and draft-richardson-opsawg-pcaplinktype-01
From: Michael Tuexen Sent: 30 December 2022 14:48 > On 30. Dec 2022, at 12:41, tom petch wrote: > From: Michael Tuexen > Sent: 29 December 2022 17:13 >> On 29. Dec 2022, at 17:45, tom petch wrote: >> From: Carsten Bormann >> Sent: 29 December 2022 13:20 >> On 2022-12-29, at 12:55, tom petch wrote: >>> >>> The linktype I-D is defective with its documentary references so the >>> website is going to be as well. The number of references for links is >>> considerable in the I-D although none appear as references of the I-D as >>> anyone familiar with the work of the IETF would expect. >> >> Hmm. The registry has four columns, of which the fourth is the >> "document/requestor reference" column. >> >> The draft does not say, but to me implies, that this column will be >> populated with a reference to the linktypes RFC for all rows in the initial >> set. >> >> I’m no quite sure what Tom is trying to say with “The number…” but it would >> be good to have references to the documents that supply further information >> (say, what “IEEE 802.3 Ethernet” really is). >> Having these listed at "http://www.tcpdump.org/linktypes.html” is fine with >> me; this will allow updates to the document references as these tend to >> shift over time. Having them added in the fourth column of the IANA >> registry is also fine, but sounds a bit like busywork to me. >> >> >> The underlying question is what is the point of this IANA registry? >> >> 1) Duplicate the contents of the tcpdump website so that there are two >> sources of information which differ slightly and so make it unclear as to >> which is right? >> >> 2) Replace the tcpdump website with one that does not include any of the >> many URLs that the tcpdump website and so is not so useful? >> >> 3) Augment the tcpdump website with some additional linktypes but without >> indicating where the tcpdump website is the authoritative source? > The plan is to move the registry from the tcpdump website to IANA and use the > currently defined values > at the tcpdump website as the initial value for the IANA table. > > Once this is done, the table hosted at the IANA website will be the only > source of truth for this > registry. > > Does this make the intention clearer? > > > > Yes, that is clear; I do not see any such statement in the I-D. OK. That can be addressed... But let us separate two questions: (1) Should this document be adopted as a WG document? (2) How could this document be improved? I think these questions are independent. This document can be improved during the time after the WG adoption and the end of the WGLC. Most of the times the documents improve even further during IESG last call. > > It also seems to be a giant leap backwards. The tcpdump website has a mass > of useful information, 150 or so links to the reference documents for the > link protocols that it references which could be useful outside the context > of tcpdump, while the I-D, and I assume the IANA registry, has not one, not > single reference - to me that is, well, a giant leap backwards. The IANA registry will have a reference to the web page for each old entry. But if you suggest that the links should be integrated, this can be discussed. So the question which still needs to be answered is (1). Any opinion? Oppose adoption. The I-D lacks much useful information compared with the tcpdump website which you say this replaces, notably the references that the website links to for the various llnk specifications.. Given the inadequacy of the references in the I-D (setting aside those related to the linktype), then I cannot be confident that the authors will do anything to address this deficiency. Tom Petch Best regards Michael > > Tom Petch > > Best regards > Michael >> >> I do not know. Hence oppose adoption. >> >> Tom Petch >> >> All this editorial work can be done after adoption by the working group. >> >> Re the pcapng document itself, I’m not sure that Figure 3 to 6 should really >> use bit tick marks (+-+-+), as these seem to be multi-byte passages shown as >> if they were three (or four to six) bits each. It has been a couple of >> years since I reviewed a version of this document, and I’d rather have the >> iddiff bugs fixed before I re-review the current version, but I’m quite >> confident that we can fix the remaining problems in normal WG work (of which >> there will be some — no, I’m not responding to a WGLC here). >> >> So, repeating and updating my affirmative response from 2021-10-20 [1]: >> +1 from me for adopting both documents. >> >> Grüße, Carsten >> >> [1]: https://mailarchive.ietf.org/arch/msg/opsawg/8BEuzv9VaDs_RIantEPKRGtK-KE >> >> ___ >> OPSAWG mailing list >> OPSAWG@ietf.org >> https://www.ietf.org/mailman/listinfo/opsawg > ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] đź”” WG Adoption Call for draft-tuexen-opsawg-pcapng-05 and draft-richardson-opsawg-pcaplinktype-01
On 2022-12-31, at 13:09, tom petch wrote: > > The I-D lacks much useful information compared with the tcpdump website which > you say this replaces I read Michael’s response as a promise to do the necessary work. (If he doesn’t keep the promise, we can always fail WGLC.) More fundamentally, I’m having a problem with arguments of the form “The website did such a good job we can’t move the registration function to IANA”. (If we have a problem with IANA registrations, we should identify it and address it.) Grüße, Carsten ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] đź”” WG Adoption Call for draft-tuexen-opsawg-pcapng-05 and draft-richardson-opsawg-pcaplinktype-01
On 31.12.22 16:00, Carsten Bormann wrote: On 2022-12-31, at 13:09, tom petch wrote: The I-D lacks much useful information compared with the tcpdump website which you say this replaces I read Michael’s response as a promise to do the necessary work. (If he doesn’t keep the promise, we can always fail WGLC.) More fundamentally, I’m having a problem with arguments of the form “The website did such a good job we can’t move the registration function to IANA”. (If we have a problem with IANA registrations, we should identify it and address it.) Especially since we're being asked to by that community. So +1 for adoption. Eliot OpenPGP_signature Description: OpenPGP digital signature ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] đź”” WG Adoption Call for draft-tuexen-opsawg-pcapng-05 and draft-richardson-opsawg-pcaplinktype-01
> On 31. Dec 2022, at 13:09, tom petch wrote: > > From: Michael Tuexen > Sent: 30 December 2022 14:48 >> On 30. Dec 2022, at 12:41, tom petch wrote: >> From: Michael Tuexen >> Sent: 29 December 2022 17:13 >>> On 29. Dec 2022, at 17:45, tom petch wrote: >>> From: Carsten Bormann >>> Sent: 29 December 2022 13:20 >>> On 2022-12-29, at 12:55, tom petch wrote: The linktype I-D is defective with its documentary references so the website is going to be as well. The number of references for links is considerable in the I-D although none appear as references of the I-D as anyone familiar with the work of the IETF would expect. >>> >>> Hmm. The registry has four columns, of which the fourth is the >>> "document/requestor reference" column. >>> >>> The draft does not say, but to me implies, that this column will be >>> populated with a reference to the linktypes RFC for all rows in the initial >>> set. >>> >>> I’m no quite sure what Tom is trying to say with “The number…” but it would >>> be good to have references to the documents that supply further information >>> (say, what “IEEE 802.3 Ethernet” really is). >>> Having these listed at "http://www.tcpdump.org/linktypes.html” is fine with >>> me; this will allow updates to the document references as these tend to >>> shift over time. Having them added in the fourth column of the IANA >>> registry is also fine, but sounds a bit like busywork to me. >>> >>> >>> The underlying question is what is the point of this IANA registry? >>> >>> 1) Duplicate the contents of the tcpdump website so that there are two >>> sources of information which differ slightly and so make it unclear as to >>> which is right? >>> >>> 2) Replace the tcpdump website with one that does not include any of the >>> many URLs that the tcpdump website and so is not so useful? >>> >>> 3) Augment the tcpdump website with some additional linktypes but without >>> indicating where the tcpdump website is the authoritative source? >> The plan is to move the registry from the tcpdump website to IANA and use >> the currently defined values >> at the tcpdump website as the initial value for the IANA table. >> >> Once this is done, the table hosted at the IANA website will be the only >> source of truth for this >> registry. >> >> Does this make the intention clearer? >> >> >> >> Yes, that is clear; I do not see any such statement in the I-D. > OK. That can be addressed... > > But let us separate two questions: > (1) Should this document be adopted as a WG document? > (2) How could this document be improved? > I think these questions are independent. This document can be improved during > the > time after the WG adoption and the end of the WGLC. Most of the times the > documents > improve even further during IESG last call. >> >> It also seems to be a giant leap backwards. The tcpdump website has a mass >> of useful information, 150 or so links to the reference documents for the >> link protocols that it references which could be useful outside the context >> of tcpdump, while the I-D, and I assume the IANA registry, has not one, not >> single reference - to me that is, well, a giant leap backwards. > The IANA registry will have a reference to the web page for each old entry. > But if you suggest that > the links should be integrated, this can be discussed. > > So the question which still needs to be answered is (1). Any opinion? > > > > Oppose adoption. > > The I-D lacks much useful information compared with the tcpdump website which > you say this replaces, notably the references that the website links to for > the various llnk specifications.. Given the inadequacy of the references in > the I-D (setting aside those related to the linktype), then I cannot be > confident that the authors will do anything to address this deficiency. I do not understand that point for two reasons: (1) I promised that constructive feedback will be integrated. The authors want to get such feedback. (2) Once the ID is a WG document, the editors of the document have to change the document based on the consensus of the WG, not based on the preference of the editors. At least this us my understanding of the IETF process (at least in other WGs). When I think about the question whether a document should be adopted or not, I'm not so much (actually not at all) focussing on technical / editorial details, but more whether the document addresses a problem which should be addressed or not. Please note that the tcpdump website is currently providing information you like and that some people run the registry on their spare time. But this registry is used by more applications than tcpdump and the pcap and pcapng file format has some substantial deployment (In my view). So it would be good to ensure that the registry and file formats are usable also in the future. You can't guarantee the the website will continue to exist or the people
Re: [OPSAWG] đź”” WG Adoption Call for draft-tuexen-opsawg-pcapng-05 and draft-richardson-opsawg-pcaplinktype-01
> The I-D lacks much useful information compared with the tcpdump website > which you say this replaces, notably the references that the website > links to for the various llnk specifications.. Given the inadequacy of > the references in the I-D (setting aside those related to the > linktype), then I cannot be confident that the authors will do anything > to address this deficiency. So if I am understanding you Tom, you prefer the web site content, and don't trust the authors to be responsive during a WG process, and you don't think that the WG will listen to your requests, and you think that the WG will publish the document without changes? Do you understand that the authors/maintainers of the web site are in fact the authors of the document? -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] đź”” WG Adoption Call for draft-tuexen-opsawg-pcapng-05 and draft-richardson-opsawg-pcaplinktype-01
Carsten Bormann wrote: > More fundamentally, I’m having a problem with arguments of the form > “The website did such a good job we can’t move the registration > function to IANA”. (If we have a problem with IANA registrations, we > should identify it and address it.) Thank you for wondering if it's better at IANA or not. Here are 44 pull requests for new link types. take a look at the history: https://github.com/the-tcpdump-group/libpcap/pulls?q=is%3Apr+link+add For example: https://github.com/the-tcpdump-group/libpcap/pull/1075 https://github.com/the-tcpdump-group/libpcap/pull/1143 Our goal is to: a) lighten the load of submitters and reviewers by creating the FCFS category, and the more rigorous specification required. (We don't know ahead of time what's right, and it's hard to direct people) b) allow for more use of PCAP*NG* in new places and old places. In particular, some entities can't ask for pcap format files because there isn't a specification that they can (legally: according to trade agreements) cite. (Of course, we know that we'll still wind up as Expert Reviewers) signature.asc Description: PGP signature ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] đź”” WG Adoption Call for draft-tuexen-opsawg-pcapng-05 and draft-richardson-opsawg-pcaplinktype-01
From: Carsten Bormann Sent: 31 December 2022 15:00 On 2022-12-31, at 13:09, tom petch wrote: > > The I-D lacks much useful information compared with the tcpdump website which > you say this replaces I read Michael’s response as a promise to do the necessary work. (If he doesn’t keep the promise, we can always fail WGLC.) I see no such promise; and I learnt several decades ago that the earlier a problem is fixed, the less the cost of fixing it (e.g. an I-D currently with the IESG that references an IANA registry that does not exist will cost more to fix if this issue had been detected in the WG). More fundamentally, I’m having a problem with arguments of the form “The website did such a good job we can’t move the registration function to IANA”. (If we have a problem with IANA registrations, we should identify it and address it.) I am sure you can see that I am not saying anything like that. I am saying that replacing a resource with lots of useful information with a resource that lacks useful information is a step backwards that I do not think that the WG should take. Tom Petch Grüße, Carsten ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] đź”” WG Adoption Call for draft-tuexen-opsawg-pcapng-05 and draft-richardson-opsawg-pcaplinktype-01
From: Michael Richardson Sent: Saturday, December 31, 2022 22:17 To: tom petch; Michael Tuexen; opsawg Subject: Re: [OPSAWG] 🔔 WG Adoption Call for draft-tuexen-opsawg-pcapng-05 and draft-richardson-opsawg-pcaplinktype-01 > The I-D lacks much useful information compared with the tcpdump website > which you say this replaces, notably the references that the website > links to for the various llnk specifications.. Given the inadequacy of > the references in the I-D (setting aside those related to the > linktype), then I cannot be confident that the authors will do anything > to address this deficiency. So if I am understanding you Tom, you prefer the web site content, and don't trust the authors to be responsive during a WG process, and you don't think that the WG will listen to your requests, and you think that the WG will publish the document without changes? Do you understand that the authors/maintainers of the web site are in fact the authors of the document? A slight overstatement of my position but along the right lines. Yes I guessed that the authors of this I-D had a connection with the maintainers of the tcpdump website although the only name I see on the website appears to have no connection with the names of the I-D authors. Given how far removed in utility the I-D is from the website, for me, I do not have confidence in the IETF process to address my concerns. The I-D falls short of what I expect where references are concerned (setting aside my concern about the references specific to the link types). The authors of the I-D have carried across the descriptive text from the website some of which I see as of poor quality and have not carried across the references to the specifications of the links most of which I see as of high quality and were I to embark on the exercise of setting up an IANA replacement I would have taken the directly opposite approach. Hence my lack of confidence that the IANA website will be an adequate replacement at the end of the IETF process. Tom Petch -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] đź”” WG Adoption Call for draft-tuexen-opsawg-pcapng-05 and draft-richardson-opsawg-pcaplinktype-01
From: Michael Tuexen Sent: 31 December 2022 18:19 > On 31. Dec 2022, at 13:09, tom petch wrote: > > From: Michael Tuexen > Sent: 30 December 2022 14:48 >> On 30. Dec 2022, at 12:41, tom petch wrote: >> From: Michael Tuexen >> Sent: 29 December 2022 17:13 >> >> >> Yes, that is clear; I do not see any such statement in the I-D. > OK. That can be addressed... > > But let us separate two questions: > (1) Should this document be adopted as a WG document? > (2) How could this document be improved? > I think these questions are independent. This document can be improved during > the > time after the WG adoption and the end of the WGLC. Most of the times the > documents > improve even further during IESG last call. >> >> It also seems to be a giant leap backwards. The tcpdump website has a mass >> of useful information, 150 or so links to the reference documents for the >> link protocols that it references which could be useful outside the context >> of tcpdump, while the I-D, and I assume the IANA registry, has not one, not >> single reference - to me that is, well, a giant leap backwards. > The IANA registry will have a reference to the web page for each old entry. > But if you suggest that > the links should be integrated, this can be discussed. > > So the question which still needs to be answered is (1). Any opinion? > > > > Oppose adoption. > > The I-D lacks much useful information compared with the tcpdump website which > you say this replaces, notably the references that the website links to for > the various llnk specifications.. Given the inadequacy of the references in > the I-D (setting aside those related to the linktype), then I cannot be > confident that the authors will do anything to address this deficiency. I do not understand that point for two reasons: (1) I promised that constructive feedback will be integrated. The authors want to get such feedback. (2) Once the ID is a WG document, the editors of the document have to change the document based on the consensus of the WG, not based on the preference of the editors. At least this us my understanding of the IETF process (at least in other WGs). Michael That is the theory and in some WG it happens; in others it does not and an I-D seems to become the personal plaything of the author(s). I am aware of the work you have done in the IETF and have no concerns about that where you are concerned nor have I had any such concerns with the work of WGs such as TSVWG. As to whether or not the I-D addresses a problem that is worth addressing, I do not know. I am not privy to the information you give below but that information, which is new to me, does suggest that there is a problem that is worth resolving, a statement of requirements of a problem if you will. In a sense, the linktype I-D says here is a solution but we are not telling you what the problem that it is addressing is. That may or may not be worth adding to the I-D. At the same time, I am aware that in engineering, in all its forms, a project that starts off in the wrong direction is costly to fix at a later date so I do look ahead as to where a project might lead and seek to steer it in what I think will be the best direction. HTH Tom Petch When I think about the question whether a document should be adopted or not, I'm not so much (actually not at all) focussing on technical / editorial details, but more whether the document addresses a problem which should be addressed or not. Please note that the tcpdump website is currently providing information you like and that some people run the registry on their spare time. But this registry is used by more applications than tcpdump and the pcap and pcapng file format has some substantial deployment (In my view). So it would be good to ensure that the registry and file formats are usable also in the future. You can't guarantee the the website will continue to exist or the people will still run the registry in their spare time. Having a specification, for example, for pcapng seems to be very useful. I got a couple of questions in the past due to the fact that my name is on it and the document being available at github. But, I would pretty much prefer to have a cleaned-up version available at the IETF website and not hoping that some people keep it up some where. Best regards Michael > > Tom Petch > > > Best regards > Michael >> >> Tom Petch >> >> Best regards >> Michael >>> >>> I do not know. Hence oppose adoption. >>> >>> Tom Petch >>> >>> All this editorial work can be done after adoption by the working group. >>> >>> Re the pcapng document itself, I’m not sure that Figure 3 to 6 should >>> really use bit tick marks (+-+-+), as these seem to be multi-byte passages >>> shown as if they were three (or four to six) bits each. It has been a >>> couple of years since I reviewed a version of this document, and I’d rather >>> have the iddiff bugs fixed before I re-review the cu
Re: [OPSAWG] đź”” WG Adoption Call for draft-tuexen-opsawg-pcapng-05 and draft-richardson-opsawg-pcaplinktype-01
On 8 Dec 2022, at 21:34, Henk Birkholz wrote: > Dear OPSAWG members, > > this starts a Working Group Adoption call for a bundle of two documents: > >> https://www.ietf.org/archive/id/draft-tuexen-opsawg-pcapng-05.html >> https://www.ietf.org/archive/id/draft-richardson-opsawg-pcaplinktype-01.html > > ending on Monday, December 30th. > > As a recap: we already went through a first WGLC for > draft-tuexen-opsawg-pcapng-03 and this is the second WGLC. The last WGLC did > not yield a critical mass of active support. > > Since the last WGLC, two relevant decisions were made: > > 1.) The Intended Status of the main document draft-tuexen-opsawg-pcapng is > now Informational. > > 2.) The draft-richardson-opsawg-pcaplinktype document was split from the main > documents, focuses solely on the PCAP LINK Type registry content, and retains > the Intended Status Standards Track (as informational documents cannot > request a registry). > > As a generic reminder, these internet drafts describe the PCAPng format and > its corresponding registry - retaining the established design patterns of > PCAP and adding new capabilities as well as a an extensibility feature. > Please note that the corresponding document > https://www.ietf.org/archive/id/draft-ietf-opsawg-pcap-01.html was adopted in > October 2021 and its Intended Status is Historical. > > Please reply with your active support (+1 required) or objections and > especially any substantive comments you may have. Sorry for the (to)late response, but I was on PTO for a while… +1 for these documents! Cheers, Eelco > For the OPSAWG co-chairs, > > Henk ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] đź”” WG Adoption Call for draft-tuexen-opsawg-pcapng-05 and draft-richardson-opsawg-pcaplinktype-01
Dear OPSAWG members, this email concludes the 2nd call for Working Group Adoption on the bundle of https://www.ietf.org/archive/id/draft-tuexen-opsawg-pcapng-05.html and https://www.ietf.org/archive/id/draft-richardson-opsawg-pcaplinktype-01.html. Looking back on both WGLCs, we received a reasonable number of replies, including an extensive discussion about transfer, maintenance, and quality of content in the pcaplinktype I-D. The chairs discussed the inputs and comments and believe this work to be feasible to be adopted as working group I-Ds. The chairs also acknowledge the concerns raised and expect the authors/editors (with the help of the pcap community and working group members) to create a summary of the issues raised and rephrase them as dedicated action items here on the list so that the working group can track, understand, and address them. Authors, please rename the document draft-tuexen-opsawg-pcapng-05 to draft-ietf-opsawg-pcapng-00 with an Intended Status of Informational, keeping the content as is, and resubmit. Also, please rename the document draft-richardson-opsawg-pcaplinktype-01 to draft-ietf-opsawg-pcaplinktype-00 with an Intended Status of Standards Track, keeping the content as is, and resubmit. For the OPSAWG co-chairs, Henk On 08.12.22 21:34, Henk Birkholz wrote: Dear OPSAWG members, this starts a Working Group Adoption call for a bundle of two documents: https://www.ietf.org/archive/id/draft-tuexen-opsawg-pcapng-05.html https://www.ietf.org/archive/id/draft-richardson-opsawg-pcaplinktype-01.html ending on Monday, December 30th. As a recap: we already went through a first WGLC for draft-tuexen-opsawg-pcapng-03 and this is the second WGLC. The last WGLC did not yield a critical mass of active support. Since the last WGLC, two relevant decisions were made: 1.) The Intended Status of the main document draft-tuexen-opsawg-pcapng is now Informational. 2.) The draft-richardson-opsawg-pcaplinktype document was split from the main documents, focuses solely on the PCAP LINK Type registry content, and retains the Intended Status Standards Track (as informational documents cannot request a registry). As a generic reminder, these internet drafts describe the PCAPng format and its corresponding registry - retaining the established design patterns of PCAP and adding new capabilities as well as a an extensibility feature. Please note that the corresponding document https://www.ietf.org/archive/id/draft-ietf-opsawg-pcap-01.html was adopted in October 2021 and its Intended Status is Historical. Please reply with your active support (+1 required) or objections and especially any substantive comments you may have. For the OPSAWG co-chairs, Henk ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] đź”” WG Adoption Call for draft-tuexen-opsawg-pcapng-05 and draft-richardson-opsawg-pcaplinktype-01
On Jan 2, 2023, at 2:52 AM, tom petch wrote (about the pcaplinktype I-D): > The authors of the I-D have carried across the descriptive text from the > website some of which I see as of poor quality and have not carried across > the references to the specifications of the links most of which I see as of > high quality and were I to embark on the exercise of setting up an IANA > replacement Both the I-D and the website have a table of link-layer types. The table in the website has longer descriptions for some types than does the I-D. For example, LINKTYPE_NULL has a more detailed description on the website: BSD loopback encapsulation; the link layer header is a 4-byte field, in host byte order, containing a value of 2 for IPv4 packets, a value of either 24, 28, or 30 for IPv6 packets, a value of 7 for OSI packets, or a value of 23 for IPX packets. All of the IPv6 values correspond to IPv6 packets; code reading files should check for all of them. Note that ``host byte order'' is the byte order of the machine on that the packets are captured; if a live capture is being done, ``host byte order'' is the byte order of the machine capturing the packets, but if a ``savefile'' is being read, the byte order is not necessarily that of the machine reading the capture file. than it does in the I-D: BSD loopback encapsulation The BSD loopback encapsulation has never had a formal specification; instead, it's "specified" by the code in various BSD-derived kernels. Unfortunately: 1) that code didn't put the link-layer type in network byte order, so, for example, IPv4 packets in a capture on a Motorola 68k-based machine (e.g., Sun-2 or Sun-3) would have a different 4-octet header value of 0x00 0x00 0x00 0x02 from the 0x02 0x00 0x00 0x00 value in a capture on an x86-based machine (e.g., a PC or a Sun386i; 2) that code used AF_ values, as defined by the operating system, for link-layer types, and, while all the BSDs used the 4.2BSD value of 2 for IPv4 (AF_INET), they added different values for IPv6 (AF_INET6). 1) is why the second paragraph in the website's description is there; 2) is why the first paragraph is there. Ugly, but without a time machine, not fixable. So the I-D needs to state that *somewhere*. One possibility would be to put the full description into the table entries in the I-D. Another possibility would be to have a short description in the table that points. if necessary, to a complete description later in the text. The descriptions on the website also have links to external specifications; those should be preserved, in some fashion, in the I-D. In addition, some of those external specifications are stored on the tcpdump.org website; those specifications should perhaps also be handled by having the description in the table point to the specification, given later in the I-D. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] đź”” WG Adoption Call for draft-tuexen-opsawg-pcapng-05 and draft-richardson-opsawg-pcaplinktype-01
Guy Harris wrote: > The table in the website has longer descriptions for some types than > does the I-D. For example, LINKTYPE_NULL has a more detailed > description on the website: I think it's better to reference the web site, and we have expanded many entries, such as: https://www.tcpdump.org/linktypes/LINKTYPE_NORDIC_BLE.html And I think that these would remain as the authoritative reference. If we need one for _NULL, that's not a problem. > So the I-D needs to state that *somewhere*. > One possibility would be to put the full description into the table entries in the I-D. That's not going to be helpful once it goes into an IANA registry. > Another possibility would be to have a short description in the table > that points. if necessary, to a complete description later in the > text. > The descriptions on the website also have links to external > specifications; those should be preserved, in some fashion, in the > I-D. I guess that we need to do a detailed review of each entry. Perhaps there will be entries which WG members have better references, even. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
