From: Michael Tuexen <michael.tue...@lurchi.franken.de>
Sent: 31 December 2022 18:19
> On 31. Dec 2022, at 13:09, tom petch <ie...@btconnect.com> wrote:
>
> From: Michael Tuexen <michael.tue...@lurchi.franken.de>
> Sent: 30 December 2022 14:48
>> On 30. Dec 2022, at 12:41, tom petch <ie...@btconnect.com> wrote:
>> From: Michael Tuexen <michael.tue...@lurchi.franken.de>
>> Sent: 29 December 2022 17:13
>> <tp2>
>>
>> Yes, that is clear; I do not see any such statement in the I-D.
> OK. That can be addressed...
>
> But let us separate two questions:
> (1) Should this document be adopted as a WG document?
> (2) How could this document be improved?
> I think these questions are independent. This document can be improved during
> the
> time after the WG adoption and the end of the WGLC. Most of the times the
> documents
> improve even further during IESG last call.
>>
>> It also seems to be a giant leap backwards. The tcpdump website has a mass
>> of useful information, 150 or so links to the reference documents for the
>> link protocols that it references which could be useful outside the context
>> of tcpdump, while the I-D, and I assume the IANA registry, has not one, not
>> single reference - to me that is, well, a giant leap backwards.
> The IANA registry will have a reference to the web page for each old entry.
> But if you suggest that
> the links should be integrated, this can be discussed.
>
> So the question which still needs to be answered is (1). Any opinion?
>
> <tp3>
>
> Oppose adoption.
>
> The I-D lacks much useful information compared with the tcpdump website which
> you say this replaces, notably the references that the website links to for
> the various llnk specifications.. Given the inadequacy of the references in
> the I-D (setting aside those related to the linktype), then I cannot be
> confident that the authors will do anything to address this deficiency.
I do not understand that point for two reasons:
(1) I promised that constructive feedback will be integrated. The authors want
to get such feedback.
(2) Once the ID is a WG document, the editors of the document have to change
the document based on
the consensus of the WG, not based on the preference of the editors. At
least this us my
understanding of the IETF process (at least in other WGs).
<tp>
Michael
That is the theory and in some WG it happens; in others it does not and an I-D
seems to become the personal plaything of the author(s). I am aware of the
work you have done in the IETF and have no concerns about that where you are
concerned nor have I had any such concerns with the work of WGs such as TSVWG.
As to whether or not the I-D addresses a problem that is worth addressing, I do
not know. I am not privy to the information you give below but that
information, which is new to me, does suggest that there is a problem that is
worth resolving, a statement of requirements of a problem if you will. In a
sense, the linktype I-D says here is a solution but we are not telling you what
the problem that it is addressing is. That may or may not be worth adding to
the I-D.
At the same time, I am aware that in engineering, in all its forms, a project
that starts off in the wrong direction is costly to fix at a later date so I do
look ahead as to where a project might lead and seek to steer it in what I
think will be the best direction.
HTH
Tom Petch
When I think about the question whether a document should be adopted or not,
I'm not so much
(actually not at all) focussing on technical / editorial details, but more
whether the document
addresses a problem which should be addressed or not.
Please note that the tcpdump website is currently providing information you
like and that
some people run the registry on their spare time. But this registry is used by
more applications
than tcpdump and the pcap and pcapng file format has some substantial
deployment (In my view).
So it would be good to ensure that the registry and file formats are usable
also in the future.
You can't guarantee the the website will continue to exist or the people will
still run the
registry in their spare time.
Having a specification, for example, for pcapng seems to be very useful. I got
a couple of
questions in the past due to the fact that my name is on it and the document
being available
at github. But, I would pretty much prefer to have a cleaned-up version
available at the
IETF website and not hoping that some people keep it up some where.
Best regards
Michael
>
> Tom Petch
>
>
> Best regards
> Michael
>>
>> Tom Petch
>>
>> Best regards
>> Michael
>>>
>>> I do not know. Hence oppose adoption.
>>>
>>> Tom Petch
>>>
>>> All this editorial work can be done after adoption by the working group.
>>>
>>> Re the pcapng document itself, Iβm not sure that Figure 3 to 6 should
>>> really use bit tick marks (+-+-+), as these seem to be multi-byte passages
>>> shown as if they were three (or four to six) bits each. It has been a
>>> couple of years since I reviewed a version of this document, and Iβd rather
>>> have the iddiff bugs fixed before I re-review the current version, but Iβm
>>> quite confident that we can fix the remaining problems in normal WG work
>>> (of which there will be some β no, Iβm not responding to a WGLC here).
>>>
>>> So, repeating and updating my affirmative response from 2021-10-20 [1]:
>>> +1 from me for adopting both documents.
>>>
>>> GrΓΌΓe, Carsten
>>>
>>> [1]:
>>> https://mailarchive.ietf.org/arch/msg/opsawg/8BEuzv9VaDs_RIantEPKRGtK-KE
>>>
>>> _______________________________________________
>>> 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
