Ketan Talaulikar has entered the following ballot position for draft-ietf-opsawg-pcaplinktype-12: Discuss
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-opsawg-pcaplinktype/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks to the authors and the WG for their work on this document. I support it and have a few items that I would like to discuss. 1) The following reference needs to be normative since this is where the PCAP protocol which is the subject matter of this document is specified? [I-D.ietf-opsawg-pcap] Harris, G. and M. Richardson, "PCAP Capture File Format", Work in Progress, Internet-Draft, draft-ietf-opsawg-pcap-06, 3 September 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-pcap-06>. Perhaps the same goes for the following, but this I am not sure about: [I-D.ietf-opsawg-pcapng] Tüxen, M., Risso, F., Bongertz, J., Combs, G., Harris, G., Chaudron, E., and M. Richardson, "PCAP Now Generic (pcapng) Capture File Format", Work in Progress, Internet-Draft, draft-ietf-opsawg-pcapng-04, 30 August 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-pcapng-04>. 2) The registry is missing the Change Controller column and filing that is a bit tricky. I believe none of the initial allocations have the IETF as the change controller since it comes from the tcpdump/pcap open source code. As such, perhaps that open source project (or the lead developer/maintainer(s) for it) should become the Change Controllers? 3) Regarding the reference for each initial entry, there is the following text. But then several entries also have their own references. So, it is not very clear what the text below implies? Is it only for those entries that are without specific individual references? "The initial version of the registry is provided in Section 3.2.1. In each case here, the reference should be set to [TCPDUMP] and the RFC number to be assigned to this document, which is not repeated each time." 4) The DE guidance has the following text but I am not sure that I understand what this means. This needs a reference to some relevant specification that explains the encoding in question. "When the contents of the link type can contain an IPv4 or IPv6 header, then the octets between the beginning of the link type and the IP header needs to be clear." ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Please find below some comments: 1) This comment is for the responsible AD: please set the "consensus boilerplate" to "Yes" for this document in the datatracker. 2) Please expand PCAP - I believe it stands for Packet Capture? 3) Please remove the BCP 14 boilerplate since those keywords are not used (nor applicable) for this document. 4) Should the "LinkType Value" not be the first registry column which is the codepoint to be allocated? This will help organize the registry correctly as the "index"? 5) There should be also a Change Controller column in the registry. This is particularly important since this is largely FCFS and this is where a "requester" from outside the IETF will be identified. An implication arising out of this is that it seems like for most of the initial assignments done in this document, the Change Controller is not really IETF but the tcpdump open source implementation? 6) Perhaps s/values in the ranges 11-49 and 52-97 MUST NOT be assigned./values in the ranges 11-49 and 52-97 are reserved and MUST NOT be assigned. 7) The DE guidance has the following text. Please consider rephrasing it to be more direct - i.e., the DEs are expected to review the specification/reference (when provided) to determine that there is isn't an existing allocation. Also, there is some text that suggests that DEs may use their own judgement or consult with OPSAWG/OPS ADs. Perhaps this can be merged into a paragraph that describes directly what a DE is supposed to do. "There is no requirement for a specification, but often review of the specification allows the Designated Expert to determine if the allocation actually is a duplicate of another specification." _______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
