On Jul 30, 2025, at 12:11 AM, Luis Contreras via Datatracker <noreply@xxxxxxxx> wrote: > I have reviewed this document as part of the Operational Directorate's ongoing > effort to review all IETF documents being processed by the IESG. These comments > were written to improve the operational aspects of the IETF drafts. Document > editors and WG chairs should treat these comments just like any other last-call > comments. Some of them are comments intended to provide clarification in > certain aspects of the document, while the rest are minor. > > /* Comments */ > - Section 2.2. It is stated that "LinkType values 147 to 162 named > LINKTYPE_RESERVED_xx were originally reserved for Private Use. Their use is > Deprecated in favour of the values in the 65001-65535 range." It is not clear > to me if this implies that LinkType values 147 to 162 are then available for > new allocations or if it is recommended not being used because of their > previous usage as reserved values. In any case, a clarification statement for > this is advisable. Note that if those values are intended to be allocatable, > then it could be convenient to describe any implication in terms of backward > compatibility. They should be treated the same way as the values in the 65001-65535 range, and not allocated, to avoid collisions with internal private use of them. > - No reference is provided for LINKTYPE_ETHERNET even though the > description refers to IEEE 802.3 Ethernet. Should not be added a reference to > the appropriate specification by IEEE? We could, although I'm not inclined to refer to a particular *version* of 802.3. > - For a number of assigned values (e.g., > 5, 7, 99, ...) the description says "Reserved for ...". This gives the > impression of a non definitive allocation, but something to happen in the > future. Since they are allocations for legacy link types, should we either > reconsider the description (i.e., remove "reserved for") or propose some > statement in that respect in terms of assessing if such reservation is > effective or not? Anyway, I acknowledge that the mission of the document is not > auditing the usage of the assigned values but promoting a registry of them. But > similarly to the recommendation about values 147 to 162 I'm not sure if > something can be mentioned in this respect, as well. This apllies also to the > case of Number 208. Those are not available for assignment. > - Link types 11 to 49 are described as "not to be use" > values, but there is not justification for it in the text (Section 2.2 > introduces different cases but not this one). Please provide some information > about why these numbers should not be used. Same for values 52 to 98. The tcpdump.org group somewhat arbitrarily decided to start handing out new link-layer type numbers at 100, in order to avoid any unannounced assignments by other in the range below that. > - No reference is provided for LINKTYPE_RAW even though the description refers to > IPv4 and IPv6. Should not be added a reference to the appropriate specification > by IETF? Yes, we could. > By the way, it seems to be redundant with Number 228 and 229. Or, rather, the latter two are redundant with LINKTYPE_RAW, which existed long before LINKTYPE_IPV4 and LINKTYPE_IPV6 were assigned. They were requested in https://seclists.org/tcpdump/2009/q1/193. I asked the same question in https://seclists.org/tcpdump/2009/q1/194 - "What does the link-layer header on those packets look like? Are they just raw IPv4 packets with no link-layer header? If so, that's DLT_RAW." He responded in https://seclists.org/tcpdump/2009/q1/195 - "And it sounds like DLT_RAW is what to use here - ok." So I'm not sure why I added them in 2010, but here we are. -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
