Yes. The fact is, we have old fashioned work here where they are coming to us so that there is a clear canonical format. The people on the Front material are developers. If a problem is spotted with the spec that requires changes to the implementation, they can make code changes. But they’re going to be conservative, as should we. There’s running code. That’s a good thing from which we shouldn’t shy away.
And we have to look at why sometimes we don’t want these things to be IETF standards: We think the spec is somehow fundamentally defective. [Nobody thinks that] There is a competitive edge being given to one player. [This is an open spec] We wouldn’t have actual change control. [Nobody is saying that.] I could see the temptation to create an informational spec, but that would be a lie. This is a standard. We should acknowledge that. Eliot > On 12 Nov 2020, at 08:27, Carsten Bormann <[email protected]> wrote: > > 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
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
