On Oct 10, 2025, at 12:42 AM, Éric Vyncke via Datatracker <[email protected]> wrote:
> ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > # Éric Vyncke, INT AD, comments draft-ietf-opsawg-pcaplinktype-12 > CC @evyncke > > Thank you for the work put into this document. > > Please find below some non-blocking COMMENT points/nits (replies would be > appreciated even if only for my own education). > > Special thanks to Joe Clarke for the shepherd's detailed write-up including > the > WG consensus _but it lacks_ the justification of the intended status, see > below. > > Other thanks to Carlos Bernardos, the Internet directorate reviewer (at OPSAWG > WG chair's request), please consider this int-dir last call review as I was > unable to find any reply by the authors even if -12 appears to address most > (if > not all) of Carlos' comments: > https://datatracker.ietf.org/doc/review-ietf-opsawg-pcaplinktype-05-intdir-lc-bernardos-2024-08-22/ I thought I'd sent a reply email to that, but I can't seem to find it. In any case: > - “Wireshark” and “wireshark” is used in the document. Please choose one > capitalization and be consistent throughout the document. Fixed; its official name is capital-W "Wireshark", and it's now capitalized that way throughout the document. > - “ Reference: Indicates an authoritative the document reference for the > LinkType or a requester reference.” —> this sentence does not parse well. I > guess the “the” between “authoritative” and “document” should be removed. Fixed; "the" was removed, so it now says Reference: Indicates an authoritative document reference for the LinkType or a requester reference. > - “DLT” should be expanded. Fixed; it now says There is often an associated Data Link Type (DLT) value which is often identical in value, but not universally so. ... (The associated DLT values are part of the libpcap library's API, not part of this specification. DLT values, and their occasional differences from the corresponding LinkType values, exist for historical reasons.) > - “ maintain URLs over a long period of time, and a documented in a > "wp-uploaded" section is highly likely to disappear.” —> does not parse well. > I > guess “a” in “a document” should be removed. Fixed; that text is gone - it now says When processing a request for an allocation, the Designated Experts will encourage the requester to provide a specification at a stable URL. 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. ... > - “ In addition Specifications that require a reader to click ” —> I think a > comma is missing after “addition”. Fixed; that text is also gone. > - “(This is the opinion of other corporate lawyers, who worry about what their > employees might have agreed to)” —> is this really needed? Fixed; that text is also gone; > - “Linktypes may be allocated for specifications not publically available may > be made within the First-Come/First-Served area. This includes specifications > that might be classified. The minimal requirement is for a contact person for > that link type.” —> I think this needs to be rewritten. Fixed; it has been rewritten - it now says LinkTypes for which specifications are not publicly available may have values allocated within the FCFS range. This includes specifications that might be subject to a security classification. The minimal requirement is to provide a contact person for that link type. > - “Linktypes” and LINKTYPE” are used sometimes with the same meaning (I > guess). Fixed; we now refer to LinkType(s), as both the PCAP and PCAP Now Generic specifications refer to the field with files that contain those values as the LinkType field. > ## COMMENTS (non-blocking) > > ### Why informational ? > > The shepherd write-up is rather silent on the intended status of informational > as it seems to me that proposed standard would be a better fit. The existing registry that's most like the LinkType registry's the Snoop Datalink Types registry: https://www.iana.org/assignments/snoop-datalink-types/snoop-datalink-types.xhtml#snoop-datalink-types-2 which was created by RFC 1761: https://www.rfc-editor.org/rfc/rfc1761.html and further extended by RFC 3827: https://www.rfc-editor.org/rfc/rfc3827.html RFC 1761 and RFC 3827 are in the Informational category. > Moreover, draft-ietf-opsawg-pcapng has, rightfully, a normative reference to a > previous version (draft-richardson-opsawg-pcaplinktype) of this I-D, i.e., > this > creates a downref. The current version of draft-ietf-opsawg-pcapng in the Git repository has, instead, a normative reference to ietf-opsawg-pcaplinktype, so draft-ietf-opsawg-pcaplinktype-05, when it's published, will fix that. draft-ietf-opsawg-pcap-06 already refers to ietf-opsawg-pcaplinktype, so it needs no such change. > ### Section 2 > > As I spotted only one use of BCP14 (moreover in an informational I-D) in > section 3.2 (IANA considerations), please remove this section. See also > https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/ > about the use of BCP14 terms in IANA considerations. THe use of MUST NOT is in The policy allocation for the LinkType values is as follows: • Values from 0 to 65000 are allocated following a First-Come First-Served policy (Section 4.4 of [RFC8126]). Values in the ranges 0-10, 50-51, and 98-301 are already assigned; values in the ranges 11-49 and 52-97 MUST NOT be assigned. The Snoop Datalink Types registry, mentioned above, has: Range Registration Procedures --------------------------------------- 0-26 Reserved 27-4294967295 First Come First Served In the registry, 0-26 are already either assigned values (for example, 4 is Ethernet) or are Reserved (10-15 and 19-25 are marked as Reserved rather than Unassigned). Should the "PCAP-related LinkType List" registry established by ietf-opsawg-pcaplinktype have a similar table, as per ... Values in the ranges 0-10, 50-51, and 98-301 are already assigned; values in the ranges 11-49 and 52-97 MUST NOT be assigned. in the current version - and should that sentence say, instead ... Values in the ranges 0-10, 50-51, and 98-301 are already assigned; values in the ranges 11-49 and 52-97 will not be assigned. (i.e., replace "MUST NOT" with "will not"), so that the table will be Range Registration Procedures --------------------------------------- 0-10 Already assigned 11-49 Will not be assigned 50-51 Already assigned 52-97 Will not be assigned 98-301 Already assigned 302-65000 First Come First Served (or Expert Review) 65001-65535 Reserved for Experimental Use _______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
