Re: [OPSAWG] Can we please adopt draft-tuexen-opsawg-pcapng?

["Joe Clarke (jclarke)" <[e-mail]>]

> On Nov 12, 2020, at 02:46, [e-mail] 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:[e-mail]]
>> Envoyé : jeudi 12 novembre 2020 08:27
>> À : BOUCADAIR Mohamed TGI/OLN <[e-mail]>
>> Cc : Brian E Carpenter <[e-mail]>; opsawg
>> <[e-mail]>
>> 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, <[e-mail]>
>> <[e-mail]> 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:[e-mail]] De la part de Brian
>> E
>>>> Carpenter Envoyé : mercredi 11 novembre 2020 21:15 À : Toerless
>>>> Eckert <[e-mail]>; Eliot Lear <[e-mail]> Cc : opsawg
>>>> <[e-mail]> 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
>>> [e-mail]
>>> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/opsawg