Re: IETF standard? [was Re: pcapng options]

[Michael Tuexen <Michael.Tuexen () lurchi franken de>]

On Nov 2, 2012, at 7:19 PM, Marc Petit-Huguenin wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On 11/02/2012 12:03 PM, Guy Harris wrote:
> > On Nov 2, 2012, at 6:47 AM, Marc Petit-Huguenin <marc () petit-huguenin org> 
> > wrote:
> >
> > > But I think that this kind of redundancy, that can only create 
> > > interoperability issues or security vulnerabilities, should not appear
> > > in a newly designed file format.
> >
> > It's not exactly "newly-designed" - I have a mail message from 2005 
> > discussing a pcap-ng draft, so it's over 7 years old (it's from February 
> > 2005).
> >
> > > Is there a process existing to evolve this format?
> >
> > Discussions are held on the pcap-ng-format mailing list:
> >
> > https://www.winpcap.org/mailman/listinfo/pcap-ng-format
> >
> > (and that's where the discussion of opt_endofopt should probably move -
> > it's already been discussed there).
>
> Thanks, I was not aware of this list - I'll continue the discussion there.
>
> > > The spec has been written with IETF tools, but I cannot find a
> > > submission for it.
> >
> > It hasn't been submitted; I presume the intent was to do so when it was 
> > considered "ready".
> >
> > > I can help navigate the IETF process if there is an interest in pushing 
> > > this spec as a standard.  I think that this is typically the kind of
> > > thing that can be improved by the reviews from IETF members,
> >
> > Yes, but...
> >
> > > and IANA is a good place for the various registries required.
> >
> > ...I'm less sure of that.  One of the registries is the LINKTYPE_ registry 
> > (the current version of the spec enumerates LINKTYPE_ values, but that
> > should be replaced with "see http://www.tcpdump.org/linktypes.html), and
> > I'm not sure whether the IETF should own that registry or not
>
> The spec was looking as it was not up to date, that's why I proposed that
> (e.g. I could not find link type 220).
>
> > - what would the process for getting new LINKTYPE_ values be if it were to
> > be owned by the IETF?
>
> There is various possibilities, from defined in a Standard Track RFC, to FCFS,
> with the possibility to even have different assignment constraints, e.g. a
> range Standard Track, a range FCFS, and another range for experimental and
> private assignment).  See RFC 5226 for details.
Not sure if there is a WG for it... But one could try an Informational
RFC... I'm not sure if the authors want to go through the IETF process,
at least they were not a couple of years ago, when I suggested the
same.

If there is some interest in bringing this to the IETF, I would be
more than happy to help.

Best regards
Michael
> - -- 
> Marc Petit-Huguenin
> Email: marc () petit-huguenin org
> Blog: http://blog.marc.petit-huguenin.org
> Profile: http://www.linkedin.com/in/petithug
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (GNU/Linux)
>
> iQIcBAEBCAAGBQJQlFUUAAoJECnERZXWan7EOJwP/3bbG6oHXHLg9ax51N+zHckE
> ZLK88X5PUYVUxFeIVHwYtcPUybxHAvApd+/Ue0QkBTcglRMrAD7H/B5nrUkb0ZMS
> vKI+W6iFOyGMyeh6fIg71zoZOSEB/NyVIPngXGidzJQJg5t5RjG65cw0GFiaxxQv
> LXCcDX+pm/rsRgobsrf5XnIDd5ZgU4rNWdaFuveBUs9uF2xcXmT2N5f05QOCgP6C
> dENO7Xykn/dKzALiCZp9to21Uo1dccJy4SyL3UcRtHBXlLrfkotm4Ug8Iouyfv+A
> gEsfLbVHqrPXlhAFBNuvP4f5N8b9XonYKbAky5QCkOY6uTjiOz3ysKosfi8NJHMr
> ZATr9l+5DoNi6hv6LMqXmk+VI4sKb5Cvq4vjrLpQm8/3sVrlNhbrOXS6ni+K8Y6v
> R12L2wYLeByvvldxYtwckpUfywZPnBDRUunvYPdL2fecKbcpr7Sa4Mu6xIXOl8V9
> 3TPXEF/UCLcs9eXxJ07oDs7TIfzhhMVFdEWbgjpSJ8257brlIs5QTXsAQgEqN2Gl
> lKw7Mi1HE6xDnfb0eRvgqTUbUQzpmfA15EMDNb0FWp85VLyAZiQh6udgrqeCCtMh
> yX5BkQLM3YwFY/QzTI7LHTq1Pkyc6Omr7khYKt3Y8P1ZeBvQ6KV1K5265j1Vkdml
> dYklFi220luGS5uV6HXP
> =BG5v
> -----END PGP SIGNATURE-----
> ___________________________________________________________________________
> Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
> Archives:    http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe