> On Nov 12, 2020, at 02:46, [email protected] wrote: > > 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.
To some extent, this is what happened when the WG adopted TACACS+. We were careful not to document enhancements, but rather focus on clarity, limitations, and known deviations. It’s not clear if there is enough similar work required/possible for PCAPNG. Joe > > 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 _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
