[OPSAWG] Red: RFC8907 (was: Re: Can we please adopt draft-tuexen-opsawg-pcapng?)

Interesting document (RFC8907).

Several problems i see that would be good to avoid (althoigh not all are applicable to subject draft):

- The RFC It does not mention who developed the protocol. It may be clear to the ones in the know
  (or who read THEDRAFT), but i remember older RFCs that clearly state when a protocol
  is a proprietary vendor protocol not developed by the IETF. I think this RFC should
  have done it too for clarity. BY not writing it clearly, it looks like a particular
  vendor endorsement by IETF in an inappropriate fashion.

- This RFC does not not explain who has change control over the protocol. I would guess
  that Cisco wants to maintain change control, but the fact alone that i have to guess
  and that this is not written out makes this a problematic IETF product.

- This RFC does seem to mix the solely vendor defined and controlled protocol with
  a profile subset of what the IETF WG deemed to be important enough for todays use,
  but it merges both into a single document.  It would have IMHO be a lot better to
  have had a separate document just for the proprietary protocol (in whatever form,
  independent submissions seems good), and then a small RFC solely with the profile.
  That profile RFC could then even have been a BCP.

- Of course, if change control would have been given up by Cisco and passed to IETF
  and this was written into the document, then merging the proprietary protocol with
  the IETF WG defined profile would be ok. Still not my preference.

- I don't understand how that RFC can have BCP14 language. I thought that was reserved to
  standards track IETF documents ?

- I am worried about the shepherd writeup:

   (8) Has an IPR disclosure been filed that references this document?
   If so, summarize any WG discussion and conclusion regarding the IPR
   disclosures.

   N/A

  Does that mean not even the authors where asked about IPR against the protocol ?
  I thought this is done also for any WG document.

  I searched IPR disclosures and could not find any about TACACS. I could not find any.
  I would be quite surprised if there where no patents for TACACS+. Of course, not
  saying that the authors would be aware of any, but an exlicit IPR disclosure from
  the relevant vendors would have been cool.

Cheers
    Toerless

On Thu, Nov 12, 2020 at 08:48:23PM +0000, Joe Clarke (jclarke) wrote:
> 
> 
> > On Nov 12, 2020, at 02:46, mohamed.boucadair@orange.com 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:cabo@tzi.org]
> >> Envoyé : jeudi 12 novembre 2020 08:27
> >> À : BOUCADAIR Mohamed TGI/OLN <mohamed.boucadair@orange.com>
> >> Cc : Brian E Carpenter <brian.e.carpenter@gmail.com>; opsawg
> >> <opsawg@ietf.org>
> >> 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, <mohamed.boucadair@orange.com>
> >> <mohamed.boucadair@orange.com> 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:opsawg-bounces@ietf.org] De la part de Brian
> >> E
> >>>> Carpenter Envoyé : mercredi 11 novembre 2020 21:15 À : Toerless
> >>>> Eckert <tte@cs.fau.de>; Eliot Lear <lear@cisco.com> Cc : opsawg
> >>>> <opsawg@ietf.org> 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
> >>> OPSAWG@ietf.org
> >>> 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
> > OPSAWG@ietf.org
> > https://www.ietf.org/mailman/listinfo/opsawg
> 
> _______________________________________________
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg

-- 
---
tte@cs.fau.de