I think IAX2 is a nice example for a protocol that would not have been designed that way in the IETF. So independent stream was appropriate.
Pcapng was not designed in the IETF, but I think if we had had a WG for this in 2010, the result would not have looked much different. So I can very much imagine IETF consensus on pcapng (with description bugs fixed and proper use of IANA), or more specifically: IETF consensus that pcapng is the right way to do packet captures from an IETF point of view. So this is indeed more like JSON than like IAX2. (In an alternate universe, the IETF would have consensus to discard pcapng and do a modern, 2020-based design from scratch. I don’t live in that alternate universe. But hey, maybe over there I would get to fix JSON as well.) Oh, on the naming: Let’s not pull a TLS. After 21 years, that name change still mostly hasn’t stuck in the real world. (See also https://tools.ietf.org/html/draft-tuexen-opsawg-pcapng-02#section-7 for why an acronym change is a non-starter. Retronym, yes.) Grüße, Carsten > On 2020-11-12, at 07:55, <[email protected]> > <[email protected]> wrote: > > Hi all, > > I echo what Brian said. > > The authors may look at RFC5456 and RFC5457 (IANA Considerations for IAX: > Inter-Asterisk eXchange Version 2) to see how this was handled in other > contexts but with similar goals. > > Cheers, > Med > >> -----Message d'origine----- >> De : OPSAWG [mailto:[email protected]] De la part de Brian E >> Carpenter >> Envoyé : mercredi 11 novembre 2020 21:15 >> À : Toerless Eckert <[email protected]>; Eliot Lear <[email protected]> >> Cc : opsawg <[email protected]> >> Objet : Re: [OPSAWG] Can we please adopt draft-tuexen-opsawg-pcapng? >> > >> It doesn't, as long as the Independent Stream Editor and IANA agree >> to it. The Independent Stream explicitly allows for documenting >> widely used solutions that are *not* the result of IETF consensus. >> >> It's fine for the pcapng community to decide to cede change control >> to the IETF, but if they want to document the *existing* protocol as >> is, before handing over change control, IMHO the Independent Stream >> is exactly the right way to go. It would also probably be quicker, >> too. >> >> Then develop PCAPNGbis in opsawg, by all means. >> >> Brian > > > _________________________________________________________________________________________________________________________ > > 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 _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
