Hi Michael, Thanks for the follow-up.
Please see inline. Cheers, Med > -----Message d'origine----- > De : Michael Richardson <mcr+i...@sandelman.ca> > Envoyé : mercredi 31 janvier 2024 15:10 > À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com>; > 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
