Re: [OPSAWG] advancing PCAP drafts
Re-,
Please see inline.
Cheers,
Med
> -Message d'origine-
> De : Michael Richardson
> Envoyé : lundi 6 mai 2024 12:18
> À : BOUCADAIR Mohamed INNOV/NET ;
> opsawg@ietf.org
> Objet : Re: [OPSAWG] advancing PCAP drafts
>
>
> {please ignore unicast message I sent thirty seconds ago}
>
> mohamed.boucad...@orange.com wrote:
> > I think that it would be useful to have a new column to
> easily tag the
> > status of an assignment. Deprecated ones can be marked as
> such using
> > that new column, instead of having this in the description.
>
> okay, I couldn't quite understand this from the diff, but in
> principal I have no problem with that.
[Med] Actually, I didn't make that change in the PR as I wanted to discuss it
first here. As you are Ok with it, so please update the table accordingly.
Thanks.
>
> > For the DE guidance, I'm afraid that the first part of your
> text is redundant with what is already in 8126, especially this
> part:
>
> > For the Specification Required policy, review and approval
> by a
> > designated expert (see Section 5) is required, and the
> values and
> > their meanings must be documented in a permanent and
> readily
> > available public specification, in sufficient detail so
> that
> > interoperability between independent implementations is
> possible.
>
> So, a reason why I wrote that slight redundant text is so that
> the engineer who is trying to get their marketing person to put
> the document out in a sane place, would have a single place to
> point to.
[Med] Yeah. I think the text in 8126 is well enough.
> But, if the WG feels that redundant, I can go with that.
>
> --
> Michael Richardson , Sandelman Software
> Works
> -= IPv6 IoT consulting =- *I*LIKE*TRAINS*
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.
This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] advancing PCAP drafts
{please ignore unicast message I sent thirty seconds ago}
mohamed.boucad...@orange.com wrote:
> I think that it would be useful to have a new column to easily tag the
> status of an assignment. Deprecated ones can be marked as such using
> that new column, instead of having this in the description.
okay, I couldn't quite understand this from the diff, but in principal I have
no problem with that.
> For the DE guidance, I'm afraid that the first part of your text is
redundant with what is already in 8126, especially this part:
> For the Specification Required policy, review and approval by a
> designated expert (see Section 5) is required, and the values and
> their meanings must be documented in a permanent and readily
> available public specification, in sufficient detail so that
> interoperability between independent implementations is possible.
So, a reason why I wrote that slight redundant text is so that the engineer
who is trying to get their marketing person to put the document out in a sane
place, would have a single place to point to.
But, if the WG feels that redundant, I can go with that.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =- *I*LIKE*TRAINS*
signature.asc
Description: PGP signature
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] advancing PCAP drafts
Hi Michael, Thank you for fixing this. FWIW, I created a PR that you can see at: https://github.com/IETF-OPSAWG-WG/draft-ietf-opsawg-pcap/pull/154/files. Please grab whatever you think useful out there. I think that it would be useful to have a new column to easily tag the status of an assignment. Deprecated ones can be marked as such using that new column, instead of having this in the description. For the DE guidance, I'm afraid that the first part of your text is redundant with what is already in 8126, especially this part: For the Specification Required policy, review and approval by a designated expert (see Section 5) is required, and the values and their meanings must be documented in a permanent and readily available public specification, in sufficient detail so that interoperability between independent implementations is possible. I think that you can reuse most of the text at: https://datatracker.ietf.org/doc/html/rfc9445#name-guidelines-for-the-designat Cheers, Med > -Message d'origine- > De : Michael Richardson > Envoyé : vendredi 26 avril 2024 21:14 > À : BOUCADAIR Mohamed INNOV/NET > Cc : opsawg@ietf.org > Objet : Re: [OPSAWG] advancing PCAP drafts > > > mohamed.boucad...@orange.com wrote: > > However, I checked > > > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2 > Fauthor-tools.ietf.org%2Fapi%2Fiddiff%3Fdoc_1%3Ddraft-ietf- > opsawg-pcaplinktype%26url_2%3Dhttps%3A%2F%2FIETF-OPSAWG- > WG.github.io%2Fdraft-ietf-opsawg-pcap%2Fdraft-ietf-opsawg- > pcaplinktype.txt&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C > 26eac497038c49be9e0d08dc66250bb2%7C90c7a20af34b40bfbc48b9253b6f5d > 20%7C0%7C0%7C638497556498067781%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM > C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C% > 7C%7C&sdata=vvCk3DYritUqEttLZS%2BjnOXfYF2p7eqjPFHjzmcvYT0%3D&rese > rved=0 > > and I'm afraid that your main copy override many changes > agreed in the > > past. May be I'm not looking in the right branch? > > There is definitely a failure on my part to git push after the > last posting. > Guy then patched somethings, and I've just dealt with the > conflict. > Trailing periods on a bunch of entries. > type 209, name changed. > Some line wrapping changes too. > > The table got broken in -02, sorry about that. > > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2 > Fauthor-tools.ietf.org%2Fapi%2Fiddiff%3Fdoc_1%3Ddraft-ietf- > opsawg-pcaplinktype-01%26url_2%3Dhttps%253A%252F%252FIETF-OPSAWG- > WG.github.io%252Fdraft-ietf-opsawg-pcap%252Fdraft-ietf-opsawg- > pcaplinktype.txt&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C > 26eac497038c49be9e0d08dc66250bb2%7C90c7a20af34b40bfbc48b9253b6f5d > 20%7C0%7C0%7C638497556498078518%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM > C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C% > 7C%7C&sdata=KGLwhQ%2FjVG31N2RAY0sXpgRhRTSKRhEq8rg9jKPmb4Y%3D&rese > rved=0 > > might be a better diff. I will post -03 now. > > Let me paste in here the Designated Expert advice. > What do you think about sentence two? We aren't telling them not > to accept specifications that are hard to get at, but rather to > maybe push a bit for something more accessible. > > # Guidance for Designated Experts > > When processing a request for a Specification Required allocation > the Designated Experts are expected to be able to find the > relevant specification at a clearly stable URL. > It is noted that many enterprise web sites do not maintain URLs > over a long period of time, and a documented in a "wp-uploaded" > section is highly likely to disappear. > In addition Specifications that require a reader to click through > any kind of marketing or legal agreement are not considered > public. > (This is the opinion of other corporate lawyers, who worry about > what their employees might have agreed to) > > The specification needs to be clearly written, and when the > contents of the link type can contain an IPv4 or IPv6 header, > then the octets between the beginning of the link type and the IP > header needs to be very clearly specified in that document. > > Specifications which are not publically available, but which may > be obtained via liason agreements (such as to ITU-T, 3GPP, IEEE, > etc.) are acceptable particularly if the document will be public > eventually, but are discouraged. > For other documents, the Designated Expert will need use their > judgement, or consult the WG or an Area Director. > > Linktypes may be allocated for specifications not publically > available may be made within the First-Come/First-Served area. > This includes specifica
Re: [OPSAWG] advancing PCAP drafts
mohamed.boucad...@orange.com wrote: > However, I checked > https://author-tools.ietf.org/api/iddiff?doc_1=draft-ietf-opsawg-pcaplinktype&url_2=https://IETF-OPSAWG-WG.github.io/draft-ietf-opsawg-pcap/draft-ietf-opsawg-pcaplinktype.txt > and I'm afraid that your main copy override many changes agreed in the > past. May be I'm not looking in the right branch? There is definitely a failure on my part to git push after the last posting. Guy then patched somethings, and I've just dealt with the conflict. Trailing periods on a bunch of entries. type 209, name changed. Some line wrapping changes too. The table got broken in -02, sorry about that. https://author-tools.ietf.org/api/iddiff?doc_1=draft-ietf-opsawg-pcaplinktype-01&url_2=https%3A%2F%2FIETF-OPSAWG-WG.github.io%2Fdraft-ietf-opsawg-pcap%2Fdraft-ietf-opsawg-pcaplinktype.txt might be a better diff. I will post -03 now. Let me paste in here the Designated Expert advice. What do you think about sentence two? We aren't telling them not to accept specifications that are hard to get at, but rather to maybe push a bit for something more accessible. # Guidance for Designated Experts When processing a request for a Specification Required allocation the Designated Experts are expected to be able to find the relevant specification at a clearly stable URL. It is noted that many enterprise web sites do not maintain URLs over a long period of time, and a documented in a "wp-uploaded" section is highly likely to disappear. In addition Specifications that require a reader to click through any kind of marketing or legal agreement are not considered public. (This is the opinion of other corporate lawyers, who worry about what their employees might have agreed to) The specification needs to be clearly written, and when the contents of the link type can contain an IPv4 or IPv6 header, then the octets between the beginning of the link type and the IP header needs to be very clearly specified in that document. Specifications which are not publically available, but which may be obtained via liason agreements (such as to ITU-T, 3GPP, IEEE, etc.) are acceptable particularly if the document will be public eventually, but are discouraged. For other documents, the Designated Expert will need use their judgement, or consult the WG or an Area Director. Linktypes may be allocated for specifications not publically available may be made within the First-Come/First-Served area. This includes specifications that might be classified. The minimal requirement is for a contact person for that link type. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] advancing PCAP drafts
On Apr 25, 2024, at 1:02 AM, mohamed.boucad...@orange.com wrote: >> -Message d'origine- >> De : Guy Harris >> Envoyé : jeudi 25 avril 2024 09:53 ... >> The changes I see from that link are: >> >> 1) an unreadable table becomes readable, which is presumably >> what "fixing a bug in Table 3.1" refers to (although that's Table >> 1 in *Section* 3.1); >> > > [Med] The formatting is better, but the content isn't! For example, there > were many entries that was agreed to tag them as deprecated but that tagging > is now lost. I've put the "(deprecated)" text into the IETF-OPSAWG-WG/draft-ietf-opsawg-pcap GitHub repository in 119ff81379ce1e9de5b58d3c7d77a352f5d72615. >> 2) removal of the "Guidance for Designated Experts" section; >> > > [Med] ACK. This one should be reinserted back per a discussion we had in the > past. I've put that into the repository in a110d2f33f44a9322db8c007552cbdb5b439e820. I'm not sure where the -02 draft came from; I don't see any commits to draft-ietf-opsawg-pcaplinktype.md that added it, prior to mine. >> 3) replacement of the "Contributors" section with "Insert >> pcap developers etc. here"; >> >> 4) replacement of the "Acknowledgments" section with "The >> authors wish to thank (many reviewers) and many others for their >> invaluable comments.". Those appear to be left over from when the link types were in draft-ietf-opsawg-pcap.md, as the first of them mentions the pcap developers. A exhaustive list of all the contributors to the list of pcap types would probably be exhausting as well. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] advancing PCAP drafts
Hi Guy, Please see inline. Cheers, Med > -Message d'origine- > De : Guy Harris > Envoyé : jeudi 25 avril 2024 09:53 > À : BOUCADAIR Mohamed INNOV/NET > Cc : Michael Richardson ; opsawg@ietf.org > Objet : Re: [OPSAWG] advancing PCAP drafts > > > On Apr 25, 2024, at 12:04 AM, mohamed.boucad...@orange.com wrote: > > > Other than fixing a bug in Table 3.1, I thought that we were > close to the WGLC. > > > > However, I checked > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2 > Fauthor-tools.ietf.org%2Fapi%2Fiddiff%3Fdoc_1%3Ddraft-ietf- > opsawg-pcaplinktype%26url_2%3Dhttps%3A%2F%2FIETF-OPSAWG- > WG.github.io%2Fdraft-ietf-opsawg-pcap%2Fdraft-ietf-opsawg- > pcaplinktype.txt&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C > 13c4bd5b00e54c70a86608dc64fcbccd%7C90c7a20af34b40bfbc48b9253b6f5d > 20%7C0%7C0%7C638496283902976995%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM > C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C% > 7C%7C&sdata=63vT7d%2BgXfR5uGXyx4IzrF17HtVtE32lVY88KK2B2uQ%3D&rese > rved=0 and I'm afraid that your main copy override many changes > agreed in the past. May be I'm not looking in the right branch? > > The changes I see from that link are: > > 1) an unreadable table becomes readable, which is presumably > what "fixing a bug in Table 3.1" refers to (although that's Table > 1 in *Section* 3.1); > [Med] The formatting is better, but the content isn't! For example, there were many entries that was agreed to tag them as deprecated but that tagging is now lost. > 2) removal of the "Guidance for Designated Experts" section; > [Med] ACK. This one should be reinserted back per a discussion we had in the past. > 3) replacement of the "Contributors" section with "Insert > pcap developers etc. here"; > > 4) replacement of the "Acknowledgments" section with "The > authors wish to thank (many reviewers) and many others for their > invaluable comments.". > > In the Git repository for the pcaplinktypes, pcap, and pcapng > drafts, the initial commit for draft-ietf-opsawg-pcaplinktype.md > is > > commit 94d418970231e887ae24c233f4fc58862abe15d0 > Author: Michael Richardson > Date: Fri Jul 29 17:01:43 2022 -0400 > > create new document pcaplinktype, reference it > > and that has the "fill in this field" versions of "Contributors" > and "Acknowledgments". All subsequent commits have messages that > indicate minor changes. > > Michael, what was the source from which the current I-D at > > https://eur03.safelinks.protection.outlook.com/?url=https%3A > %2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-opsawg- > pcaplinktype&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C13c4 > bd5b00e54c70a86608dc64fcbccd%7C90c7a20af34b40bfbc48b9253b6f5d20%7 > C0%7C0%7C638496283902986361%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wL > jAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7 > C&sdata=PLdjoCp7ZbyGjLBmRrjURWVVpPKW5GN0jaLcIfcZyWk%3D&reserved=0 > > was generated, and should the "Guidance for Designated Experts", > "Contributors", and "Acknowledgments" sections be copied from > that version to the current version in the repository? Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] advancing PCAP drafts
On Apr 25, 2024, at 12:04 AM, mohamed.boucad...@orange.com wrote: > Other than fixing a bug in Table 3.1, I thought that we were close to the > WGLC. > > However, I checked > https://author-tools.ietf.org/api/iddiff?doc_1=draft-ietf-opsawg-pcaplinktype&url_2=https://IETF-OPSAWG-WG.github.io/draft-ietf-opsawg-pcap/draft-ietf-opsawg-pcaplinktype.txt > and I'm afraid that your main copy override many changes agreed in the past. > May be I'm not looking in the right branch? The changes I see from that link are: 1) an unreadable table becomes readable, which is presumably what "fixing a bug in Table 3.1" refers to (although that's Table 1 in *Section* 3.1); 2) removal of the "Guidance for Designated Experts" section; 3) replacement of the "Contributors" section with "Insert pcap developers etc. here"; 4) replacement of the "Acknowledgments" section with "The authors wish to thank (many reviewers) and many others for their invaluable comments.". In the Git repository for the pcaplinktypes, pcap, and pcapng drafts, the initial commit for draft-ietf-opsawg-pcaplinktype.md is commit 94d418970231e887ae24c233f4fc58862abe15d0 Author: Michael Richardson Date: Fri Jul 29 17:01:43 2022 -0400 create new document pcaplinktype, reference it and that has the "fill in this field" versions of "Contributors" and "Acknowledgments". All subsequent commits have messages that indicate minor changes. Michael, what was the source from which the current I-D at https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-pcaplinktype was generated, and should the "Guidance for Designated Experts", "Contributors", and "Acknowledgments" sections be copied from that version to the current version in the repository? ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] advancing PCAP drafts
Hi Michael, Any update about this draft? Other than fixing a bug in Table 3.1, I thought that we were close to the WGLC. However, I checked https://author-tools.ietf.org/api/iddiff?doc_1=draft-ietf-opsawg-pcaplinktype&url_2=https://IETF-OPSAWG-WG.github.io/draft-ietf-opsawg-pcap/draft-ietf-opsawg-pcaplinktype.txt and I'm afraid that your main copy override many changes agreed in the past. May be I'm not looking in the right branch? Cheers, Med > -Message d'origine- > De : BOUCADAIR Mohamed INNOV/NET > Envoyé : lundi 5 février 2024 16:38 > À : 'Michael Richardson' ; opsawg@ietf.org > Objet : RE: [OPSAWG] advancing PCAP drafts > > Hi Michael, > > Thanks for the follow-up. > > Please see inline. > > Cheers, > Med > > > -Message d'origine- > > De : Michael Richardson Envoyé : > mercredi 31 > > janvier 2024 15:10 À : BOUCADAIR Mohamed INNOV/NET > > ; opsawg@ietf.org Objet : Re: > [OPSAWG] > > advancing PCAP drafts > > > > > > mohamed.boucad...@orange.com wrote: > > > Hmm...I remember at least the following candidates > changes from > > that > > > thread, e.g., > > > > > * > > > > > > https://mailarchive.ietf.org/arch/msg/opsawg/u0__66zIpCMHA4syzt8f > Wtyx9 > > 8Y/ > > > * > > > > > > https://mailarchive.ietf.org/arch/msg/opsawg/ExlyBZ9eRP_UHUvCAmtK > u0b28 > > Z4/ > > > > > I trust that you will check that thread and do the right > thing. > > Thanks. > > > > I've been through that thread. > > I think that I've got it all. > > Please check the diff to -02. > > [Med] Thanks. I like the new changes. Please note that there is a > bug with the table in 3.1. > > > > > I don't know if ISE documents can create registries: one ISE > told me > > no. > > The document is in the WG, so let's not religitate that now. > > [Med] hmm, I was not reviving that ISE discussion :-( I was > actually pointing to specific messages with some candidate > changes (e.g. tag deprecated entries), which you adequately > addressed in -02. Thanks. > > > > > > I sent you right now a PR with some minor edits. > > > > I believe that it was https://github.com/IETF-OPSAWG-WG/draft- > ietf- > > opsawg-pcap/pull/134 > > and it was merged nov 9. > > > > > For the specification required range, you may consider adding > some > > guidance for DEs. > > > > Done. You may wish to read the diff, and maybe disagree with > my > > advice. > > > > > The initial table does not mirror the current values in > > > https://www.tcpdump.org/linktypes.html. Also, some > descriptions in > > the > > > table does not match exactly what is in that table. Not sure > if it > > is > > > worth explaining the diff. > > > > I've updated the table with numbers out to 301. > > I'm not sure about putting URLs in. > > > > > You may indicate that the procedure for assigning new codes > as > > > detailed in https://www.tcpdump.org/linktypes.html won't be > followed > > anymore. > > > > That's been updated in git, and may take a bit to go live. > > > > > Some assigned types seem to be used for private use while > these > > types > > > fall now under a specification required range. I don't know > if it is > > > worth to have some consistency here and consider a range for > future > > > specification required type, e.g., 300-32767 that won't be > mixed > > with the historic ones. > > > > It's grandfathered as far as I'm concerned. Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] advancing PCAP drafts
Hi Michael, Thanks for the follow-up. Please see inline. Cheers, Med > -Message d'origine- > De : Michael Richardson > Envoyé : mercredi 31 janvier 2024 15:10 > À : BOUCADAIR Mohamed INNOV/NET ; > opsawg@ietf.org > Objet : Re: [OPSAWG] advancing PCAP drafts > > > mohamed.boucad...@orange.com wrote: > > Hmm...I remember at least the following candidates changes from > that > > thread, e.g., > > > * > > > https://mailarchive.ietf.org/arch/msg/opsawg/u0__66zIpCMHA4syzt8fWtyx9 > 8Y/ > > * > > > https://mailarchive.ietf.org/arch/msg/opsawg/ExlyBZ9eRP_UHUvCAmtKu0b28 > Z4/ > > > I trust that you will check that thread and do the right thing. > Thanks. > > I've been through that thread. > I think that I've got it all. > Please check the diff to -02. [Med] Thanks. I like the new changes. Please note that there is a bug with the table in 3.1. > > I don't know if ISE documents can create registries: one ISE told me > no. > The document is in the WG, so let's not religitate that now. [Med] hmm, I was not reviving that ISE discussion :-( I was actually pointing to specific messages with some candidate changes (e.g. tag deprecated entries), which you adequately addressed in -02. Thanks. > > > I sent you right now a PR with some minor edits. > > I believe that it was https://github.com/IETF-OPSAWG-WG/draft-ietf- > opsawg-pcap/pull/134 > and it was merged nov 9. > > > For the specification required range, you may consider adding some > guidance for DEs. > > Done. You may wish to read the diff, and maybe disagree with my > advice. > > > The initial table does not mirror the current values in > > https://www.tcpdump.org/linktypes.html. Also, some descriptions in > the > > table does not match exactly what is in that table. Not sure if it > is > > worth explaining the diff. > > I've updated the table with numbers out to 301. > I'm not sure about putting URLs in. > > > You may indicate that the procedure for assigning new codes as > > detailed in https://www.tcpdump.org/linktypes.html won't be followed > anymore. > > That's been updated in git, and may take a bit to go live. > > > Some assigned types seem to be used for private use while these > types > > fall now under a specification required range. I don't know if it is > > worth to have some consistency here and consider a range for future > > specification required type, e.g., 300-32767 that won't be mixed > with the historic ones. > > It's grandfathered as far as I'm concerned. Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] advancing PCAP drafts
On 31.01.2024 15:10, Michael Richardson wrote: I don't know if ISE documents can create registries: one ISE told me no. See RFC 8726. &TL;DR not permitted unless it's a required sub-registry tied to a requested allocation. Eliot OpenPGP_0x87B66B46D9D27A33.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] advancing PCAP drafts
mohamed.boucad...@orange.com wrote: > Hmm...I remember at least the following candidates changes from that > thread, e.g., > * > https://mailarchive.ietf.org/arch/msg/opsawg/u0__66zIpCMHA4syzt8fWtyx98Y/ > * > https://mailarchive.ietf.org/arch/msg/opsawg/ExlyBZ9eRP_UHUvCAmtKu0b28Z4/ > I trust that you will check that thread and do the right thing. Thanks. I've been through that thread. I think that I've got it all. Please check the diff to -02. I don't know if ISE documents can create registries: one ISE told me no. The document is in the WG, so let's not religitate that now. > I sent you right now a PR with some minor edits. I believe that it was https://github.com/IETF-OPSAWG-WG/draft-ietf-opsawg-pcap/pull/134 and it was merged nov 9. > For the specification required range, you may consider adding some guidance > for DEs. Done. You may wish to read the diff, and maybe disagree with my advice. > The initial table does not mirror the current values in > https://www.tcpdump.org/linktypes.html. Also, some descriptions in the > table does not match exactly what is in that table. Not sure if it is worth > explaining the diff. I've updated the table with numbers out to 301. I'm not sure about putting URLs in. > You may indicate that the procedure for assigning new codes as detailed in > https://www.tcpdump.org/linktypes.html won't be followed anymore. That's been updated in git, and may take a bit to go live. > Some assigned types seem to be used for private use while these types fall > now under a specification required range. I don't know if it is worth to > have some consistency here and consider a range for future specification > required type, e.g., 300-32767 that won't be mixed with the historic ones. It's grandfathered as far as I'm concerned. -- 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] advancing PCAP drafts
Hi Michael, Hmm...I remember at least the following candidates changes from that thread, e.g., * https://mailarchive.ietf.org/arch/msg/opsawg/u0__66zIpCMHA4syzt8fWtyx98Y/ * https://mailarchive.ietf.org/arch/msg/opsawg/ExlyBZ9eRP_UHUvCAmtKu0b28Z4/ I trust that you will check that thread and do the right thing. Thanks. Cheers, Med > -Message d'origine- > De : Michael Richardson > Envoyé : lundi 20 novembre 2023 14:14 > À : BOUCADAIR Mohamed INNOV/NET ; > opsawg@ietf.org > Objet : Re: [OPSAWG] advancing PCAP drafts > > > mohamed.boucad...@orange.com wrote: > > Noted for the second point. However, I think there is more than > > mirroring the table. I remember that we discussed deprecating > values > > (?) and ensuring some consistency for future assignments vs. the > > historic range. > > In what way is the draft unclear about how things would go forward? > I don't know that we can effectively deprecate anything; but we could > certainly try. > > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- *I*LIKE*TRAINS* > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] advancing PCAP drafts
mohamed.boucad...@orange.com wrote: > Noted for the second point. However, I think there is more than > mirroring the table. I remember that we discussed deprecating values > (?) and ensuring some consistency for future assignments vs. the > historic range. In what way is the draft unclear about how things would go forward? I don't know that we can effectively deprecate anything; but we could certainly try. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- *I*LIKE*TRAINS* signature.asc Description: PGP signature ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] advancing PCAP drafts
Hi Michael, Noted for the second point. However, I think there is more than mirroring the table. I remember that we discussed deprecating values (?) and ensuring some consistency for future assignments vs. the historic range. Thanks. Cheers, Med > -Message d'origine- > De : Michael Richardson > Envoyé : vendredi 17 novembre 2023 14:56 > À : BOUCADAIR Mohamed INNOV/NET ; > opsawg@ietf.org > Objet : Re: [OPSAWG] advancing PCAP drafts > > > mohamed.boucad...@orange.com wrote: > >> draft-ietf-opsawg-pcaplinktype - Standards Track to create > Registry > > > I thought that we agreed that this justification for PS is not > accurate > > (1): "linktypes "highest" level is Specification Required". A > better > > reason should be provided. > > I'd heard that the ISE couldn't create registries of the kind we > wanted, and that WG processing was not too a difficult change. > > > BTW, any update about how you addressed the comments: > > > https://mailarchive.ietf.org/arch/msg/opsawg/7yE7THneT48DBzmGq3e5M_bwO > ok/? > > I would do a final pass to import linktypes.html just before WGLC, and > then update linktypes.html to note that new document exists. > > > > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- *I*LIKE*TRAINS* > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] advancing PCAP drafts
Carsten Bormann wrote: >> Carsten Bormann wrote: I thought that we agreed that this justification for PS is not accurate (1): "linktypes "highest" level is Specification Required". A better reason should be provided. >> >>> The draft doesn’t just register in that registry, it creates a >>> registry. >> >>> Note that I have tried multiple times to find out what the >>> requirements on the document type/stream for creating a registry are, >>> and I haven’t found anything. >> >> I was told by Adrien Farrel, then ISE, that the ISE couldn't create >> registries that potentially required any kind of IETF actions to fill >> them. Now, we've changed the IANA Considerations since then, but >> that's where we were a few years ago. > OK, but these are IETF WG documents, not on the ISE stream. So I don’t > think this information is relevant (if it were, we’d need to advance it > from rumor level to some authoritative reference). It's why they aren't on the ISE stream. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- *I*LIKE*TRAINS* signature.asc Description: PGP signature ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] advancing PCAP drafts
On 2023-11-17, at 14:51, Michael Richardson wrote: > > Signed PGP part > > Guy Harris wrote: >>> draft-ietf-opsawg-pcaplinktype - Standards Track to create Registry > >> Presumably the registry will contain more information than is in that >> I-D, or links to more information, as what's in the I-D is insufficient >> to describe the formats of packets for many LINKTYPE_ values. > > Hi, it's not the goal of the registry to describe all the linktype values. > It's to assign them uniquely. Correct. Still, almost all registries have a “reference” column, that can be used to reference a document that contains a specification (or can be used like one in a pinch). >> For example, LINKTYPE_LINUX_SLL just says "Linux "cooked" capture >> encapsulation", but does not indicate what that is; the entry for it on >> the tcpdump.org link-layer header types page at > >> https://www.tcpdump.org/linktypes.html > >> has a link to a description of the format. > > okay, so let's include that link. That would be in the references column, I’d think. We even can have notes explaining how the reference applies to this specific usage. Grüße, Carsten ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] advancing PCAP drafts
On 2023-11-17, at 14:57, Michael Richardson wrote: > > > Carsten Bormann wrote: >>> I thought that we agreed that this justification for PS is not >>> accurate (1): "linktypes "highest" level is Specification Required". A >>> better reason should be provided. > >> The draft doesn’t just register in that registry, it creates a registry. > >> Note that I have tried multiple times to find out what the requirements >> on the document type/stream for creating a registry are, and I haven’t >> found anything. > > I was told by Adrien Farrel, then ISE, that the ISE couldn't create > registries that potentially required any kind of IETF actions to fill them. > Now, we've changed the IANA Considerations since then, but that's where we > were a few years ago. OK, but these are IETF WG documents, not on the ISE stream. So I don’t think this information is relevant (if it were, we’d need to advance it from rumor level to some authoritative reference). Grüße, Carsten ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] advancing PCAP drafts
Carsten Bormann wrote: >> I thought that we agreed that this justification for PS is not >> accurate (1): "linktypes "highest" level is Specification Required". A >> better reason should be provided. > The draft doesn’t just register in that registry, it creates a registry. > Note that I have tried multiple times to find out what the requirements > on the document type/stream for creating a registry are, and I haven’t > found anything. I was told by Adrien Farrel, then ISE, that the ISE couldn't create registries that potentially required any kind of IETF actions to fill them. Now, we've changed the IANA Considerations since then, but that's where we were a few years ago. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- *I*LIKE*TRAINS* signature.asc Description: PGP signature ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] advancing PCAP drafts
mohamed.boucad...@orange.com wrote: >> draft-ietf-opsawg-pcaplinktype - Standards Track to create Registry > I thought that we agreed that this justification for PS is not accurate > (1): "linktypes "highest" level is Specification Required". A better > reason should be provided. I'd heard that the ISE couldn't create registries of the kind we wanted, and that WG processing was not too a difficult change. > BTW, any update about how you addressed the comments: > https://mailarchive.ietf.org/arch/msg/opsawg/7yE7THneT48DBzmGq3e5M_bwOok/? I would do a final pass to import linktypes.html just before WGLC, and then update linktypes.html to note that new document exists. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- *I*LIKE*TRAINS* signature.asc Description: PGP signature ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] advancing PCAP drafts
Eliot Lear wrote: > I'd like to see these docs advance as well. My only question is whether the > pcapng doc should be a Proposed Standard. I started with that belief. Overtime, people have complained that the format is not what the IETF would do if it started today. And, did we even have change control if we have to compatible with what has been out there? (Probably, we'd do some kind of CBOR container, today). So the plan evolved to publishing as Informational (pcapng "1.0"), and if there was a desire to do something with more IETF change control that a 2.0 could be done. > On 15.11.2023 10:33, Michael Richardson wrote: >> Hi, the three PCAP I-Ds have been stable for sometime now. >> >> draft-ietf-opsawg-pcap-03- going to Historic. >> draft-ietf-opsawg-pcaplinktype - Standards Track to create Registry >> draft-ietf-opsawg-pcapng-01 - going to Informational. >> >> Can we WGLC them, and find shepherds for them? >> >> -- >> Michael Richardson , Sandelman Software Works >> -= IPv6 IoT consulting =- *I*LIKE*TRAINS* >> >> >> >> >> ___ >> OPSAWG mailing list >> OPSAWG@ietf.org >> https://www.ietf.org/mailman/listinfo/opsawg -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- *I*LIKE*TRAINS* signature.asc Description: PGP signature ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] advancing PCAP drafts
Guy Harris wrote: >> draft-ietf-opsawg-pcaplinktype - Standards Track to create Registry > Presumably the registry will contain more information than is in that > I-D, or links to more information, as what's in the I-D is insufficient > to describe the formats of packets for many LINKTYPE_ values. Hi, it's not the goal of the registry to describe all the linktype values. It's to assign them uniquely. > For example, LINKTYPE_LINUX_SLL just says "Linux "cooked" capture > encapsulation", but does not indicate what that is; the entry for it on > the tcpdump.org link-layer header types page at > https://www.tcpdump.org/linktypes.html > has a link to a description of the format. okay, so let's include that link. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- *I*LIKE*TRAINS* signature.asc Description: PGP signature ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] advancing PCAP drafts
Hi Carsten, I already provided examples of Informational RFCs that create IANA registries (please refer to the thread). https://authors.ietf.org/required-content (IANA Considerations) does not mandate in the first bullet the track of the doc. Cheers, Med > -Message d'origine- > De : Carsten Bormann > Envoyé : vendredi 17 novembre 2023 09:43 > À : BOUCADAIR Mohamed INNOV/NET > Cc : Michael Richardson ; opsawg@ietf.org > Objet : Re: [OPSAWG] advancing PCAP drafts > > On 2023-11-17, at 09:30, mohamed.boucad...@orange.com wrote: > > > >> draft-ietf-opsawg-pcaplinktype - Standards Track to create Registry > > > > I thought that we agreed that this justification for PS is not > accurate (1): "linktypes "highest" level is Specification Required". A > better reason should be provided. > > The draft doesn’t just register in that registry, it creates a > registry. > > Note that I have tried multiple times to find out what the > requirements on the document type/stream for creating a registry are, > and I haven’t found anything. > If you know the answer (and can point to an IESG statement or some > other document such as an RFC), please post it here. > > Grüße, Carsten Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] advancing PCAP drafts
On Nov 17, 2023, at 12:30 AM, mohamed.boucad...@orange.com wrote: > Hi Michael, > >> draft-ietf-opsawg-pcaplinktype - Standards Track to create Registry > > I thought that we agreed that this justification for PS is not accurate (1): > "linktypes "highest" level is Specification Required". A better reason should > be provided. I'm not sure that draft-ietf-opsawg-pcaplinktype Proposes a Standard. draft-ietf-opsawg-pcap and draft-ietf-opsawg-pcapng could be viewed as proposing that two already-existing capture file formats, in significant use, be considered standards of some sort, at least to the extent that an RFC documents them. Both of those file formats have fields whose values correspond to linktypes, with the set of linktypes, and the numerical values corresponding to each linktype, being the same for the field in pcap (the per-file linktype) and pcapng (the per-interface linktype). draft-ietf-opsawg-pcaplinktype proposes a large number of linktypes to be assigned particular numerical values, so I'm not sure it proposes *a* standard, any more than, say, RFC 790's "ASSIGNED INTERNET PROTOCOL NUMBERS" section proposes *a* standard. That might be the best analogy here: draft-ietf-opsawg-pcap defines a file format, with a "LinkType and additional information" field in the file header, the low-order 16 bits of which contain a "LinkType", just as RFC 791 defines a protocol, with the protocol header containing a "Protocol" field that contains a protocol number; draft-ietf-opsawg-pcapng defines a file format, with a "LinkType" field in every Interface Description Block in the file that contains a "LinkType", just as RFC 8200 defines a protocol, with the protocol header and extension headers containing a "Next Header" field that contains a protocol number; draft-ietf-opsawg-pcaplinktype defines a bunch of values for "LinkTypes", just as RFC 790's "ASSIGNED INTERNET PROTOCOL NUMBERS" section defines several protocol numbers. The intent is to have a registry for "LinkTypes", just as there's a registry for protocol numbers; neither registry's contents are fully specified by a single document, as additional values have been and, if a registry for "LinkTypes" is established, will in the future be added. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] advancing PCAP drafts
On 2023-11-17, at 09:30, mohamed.boucad...@orange.com wrote: > >> draft-ietf-opsawg-pcaplinktype - Standards Track to create Registry > > I thought that we agreed that this justification for PS is not accurate (1): > "linktypes "highest" level is Specification Required". A better reason should > be provided. The draft doesn’t just register in that registry, it creates a registry. Note that I have tried multiple times to find out what the requirements on the document type/stream for creating a registry are, and I haven’t found anything. If you know the answer (and can point to an IESG statement or some other document such as an RFC), please post it here. Grüße, Carsten ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] advancing PCAP drafts
Hi Michael, > draft-ietf-opsawg-pcaplinktype - Standards Track to create Registry I thought that we agreed that this justification for PS is not accurate (1): "linktypes "highest" level is Specification Required". A better reason should be provided. BTW, any update about how you addressed the comments: https://mailarchive.ietf.org/arch/msg/opsawg/7yE7THneT48DBzmGq3e5M_bwOok/? Thank you. Cheers, Med (1) https://mailarchive.ietf.org/arch/msg/opsawg/HPIQm2CO7YnB2OmdA_RmtotJ43s/ > -Message d'origine- > De : OPSAWG De la part de Michael Richardson > Envoyé : mercredi 15 novembre 2023 10:34 > À : opsawg@ietf.org > Objet : [OPSAWG] advancing PCAP drafts > > > Hi, the three PCAP I-Ds have been stable for sometime now. > > draft-ietf-opsawg-pcap-03- going to Historic. > draft-ietf-opsawg-pcaplinktype - Standards Track to create Registry > draft-ietf-opsawg-pcapng-01 - going to Informational. > > Can we WGLC them, and find shepherds for them? > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- *I*LIKE*TRAINS* > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] advancing PCAP drafts
I'd like to see these docs advance as well. My only question is whether the pcapng doc should be a Proposed Standard. Eliot On 15.11.2023 10:33, Michael Richardson wrote: Hi, the three PCAP I-Ds have been stable for sometime now. draft-ietf-opsawg-pcap-03- going to Historic. draft-ietf-opsawg-pcaplinktype - Standards Track to create Registry draft-ietf-opsawg-pcapng-01 - going to Informational. Can we WGLC them, and find shepherds for them? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- *I*LIKE*TRAINS* ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg OpenPGP_0x87B66B46D9D27A33.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] advancing PCAP drafts
On Nov 15, 2023, at 1:33 AM, Michael Richardson wrote: > Hi, the three PCAP I-Ds have been stable for sometime now. ... > draft-ietf-opsawg-pcaplinktype - Standards Track to create Registry Presumably the registry will contain more information than is in that I-D, or links to more information, as what's in the I-D is insufficient to describe the formats of packets for many LINKTYPE_ values. For example, LINKTYPE_LINUX_SLL just says "Linux "cooked" capture encapsulation", but does not indicate what that is; the entry for it on the tcpdump.org link-layer header types page at https://www.tcpdump.org/linktypes.html has a link to a description of the format. For another example, LINKTYPE_NULL just says "BSD loopback encapsulation", but does not indicate what that is; the entry for it on the tcpdump.org link-layer header types page says 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. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
