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@xxxxxxxxxxxxxxxxxx>
>> 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@xxxxxxxxxxxxxxxxxx
> 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@xxxxxxxxxxxxx>
> Archives: http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
>
