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 >> On 29. Dec 2022, at 17:45, tom petch <ie...@btconnect.com> wrote: >> From: Carsten Bormann <c...@tzi.org> >> Sent: 29 December 2022 13:20 >> On 2022-12-29, at 12:55, tom petch <ie...@btconnect.com> wrote: >>> >>> The linktype I-D is defective with its documentary references so the >>> website is going to be as well. The number of references for links is >>> considerable in the I-D although none appear as references of the I-D as >>> anyone familiar with the work of the IETF would expect. >> >> Hmm. The registry has four columns, of which the fourth is the >> "document/requestor reference" column. >> >> The draft does not say, but to me implies, that this column will be >> populated with a reference to the linktypes RFC for all rows in the initial >> set. >> >> Iβm no quite sure what Tom is trying to say with βThe numberβ¦β but it would >> be good to have references to the documents that supply further information >> (say, what βIEEE 802.3 Ethernetβ really is). >> Having these listed at "http://www.tcpdump.org/linktypes.htmlβ is fine with >> me; this will allow updates to the document references as these tend to >> shift over time. Having them added in the fourth column of the IANA >> registry is also fine, but sounds a bit like busywork to me. >> >> <tp> >> The underlying question is what is the point of this IANA registry? >> >> 1) Duplicate the contents of the tcpdump website so that there are two >> sources of information which differ slightly and so make it unclear as to >> which is right? >> >> 2) Replace the tcpdump website with one that does not include any of the >> many URLs that the tcpdump website and so is not so useful? >> >> 3) Augment the tcpdump website with some additional linktypes but without >> indicating where the tcpdump website is the authoritative source? > The plan is to move the registry from the tcpdump website to IANA and use the > currently defined values > at the tcpdump website as the initial value for the IANA table. > > Once this is done, the table hosted at the IANA website will be the only > source of truth for this > registry. > > Does this make the intention clearer? > > <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. 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
