Re-, Please see inline.
Cheers, Med > -----Message d'origine----- > De : Michael Richardson <[email protected]> > Envoyé : mercredi 26 juillet 2023 10:41 > À : BOUCADAIR Mohamed INNOV/NET <[email protected]>; > [email protected] > Objet : Re: [OPSAWG] PCAP documents (was Re: I-D Action: draft- > ietf-opsawg-pcap-03.txt) > > > [email protected] wrote: > > For the specification required range, you may consider > adding some > > guidance for DEs. > > Yeah. > Do we need DE for FCFS? [Med] No. > > > 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. > > We did do some editorial stuff when we produced the document, but > also the page does get updated monthly... [Med] Yeah. I just wanted to check that these types are not left out on purpose. > > > You may indicate that the procedure for assigning new codes > as detailed > > in https://www.tcpdump.org/linktypes.html won't be followed > anymore. > > Yes, I guess we should suspend allocation of new codes from some > point until IANA is ready. I suggest that I'll suspend allocation > at WGLC? > Or would the WG like us to stop *NOW*? [Med] I don't think it should happen now as this may in theory block new requests. I would at least wait till IESG review. > > > 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. > > We allocated a few chunks for private use years ago, and they > could be in use internally somewhere, so we don't want to change > that. [Med] I was not asking to change that, but excluding the historic range for the specification required range... But, maybe we should mark them as deprecated? > [Med] That would be cleaner if the full range is maintained as specification required. > -- > Michael Richardson <[email protected]> . o O ( IPv6 IøT > consulting ) > Sandelman Software Works Inc, Ottawa and Worldwide > > > ____________________________________________________________________________________________________________ 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 [email protected] https://www.ietf.org/mailman/listinfo/opsawg
