Carsten, That would be perfectly fine if the WG identifies and plans to document the deviations and enhancements vs. current implements without being told this is "frozen". Toerless has a valid point here.
Even with that option, what we have done in the past is to: * document an existing implementation in an RFC published in the ISE track: e.g., RFC6886 * publish a standard track document with the IETF design: e.g., RFC6887 Cheers, Med > -----Message d'origine----- > De : Carsten Bormann [mailto:[email protected]] > Envoyé : jeudi 12 novembre 2020 08:27 > À : BOUCADAIR Mohamed TGI/OLN <[email protected]> > Cc : Brian E Carpenter <[email protected]>; opsawg > <[email protected]> > Objet : Re: [OPSAWG] Can we please adopt draft-tuexen-opsawg-pcapng? > > 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 _________________________________________________________________________________________________________________________ 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
