Hi Eric, Thanks for the review. See responses below.
On Mon, Sep 11, 2023 at 8:43 AM Eric Vyncke (evyncke) <evyn...@cisco.com> wrote: > Dear authors, dear shepherd, dear WG, > > As the Int-area WG chairs have requested the publication of this IETF draft, > I have done my usual AD review of it. Before processing with the publication > (i.e., the IETF Last Call), I am requesting a reply or an action on all the > points below. > > Special note for Luigi: a very detailed and crystal-clear shepherd write-up! > > Thank you for the work done, such documents are not easy to write. I have > also appreciated that the flow and table of content is really similar to RFC > 7042. > > Regards > -éric > > # Section 1 > > ` Descriptions herein of [http://www.iana.org/] policies and procedures are > authoritative` should s/authoritative/normative/ ? The paragraph including that wording was requested by the IEEE 802.1 WG. > In the same sentence, I also think that the equivalent text in RFC 7042 is > more explanatory about IANA policies (by specifying which registries). Or > move this 2nd paragraph *after* the third one ? I'm OK with moving the paragraph. > # Section 1.2 > > Should this section be removed by the RFC editor upon publication ? Or moved > to an appendix ? I do not think it should be removed. The list of changes from RFC 5342 to RFC 7042 appeared up front in RFC 7042 but I wouldn't have a problem moving this to an appendix for rfc7042bis. > # Section 1.3 > > If there is a stable URL for " IEEE Registration Authority site", should it > be added as a reference ? The reference at the end of the first sentence of 1.3 is to their web site. When I click on it in the HTMLized version, it takes me there. > # Section 2.1 > > I find " 4 1/2 octets (36 bits)" not easy to parse, what about "4.5 octets > (36 bits)" ? Hummm, well, I think "4.5 octets" is just as odd. Would "four and a half octets" be OK (also replacing the subsequent "1 1/2" with "one and a half")? > # Section 2.1.1 > > How can the reader check whether " the IEEE 802 Structured Local Address Plan > (SLAP) is in effect" ? There isn't any automated way, that I am aware of, to determine if or to what extent a local network is configured for and/or operating according to SLAP. If you meant more generally adopted as a standard, it has been in the 802 standards for some years but remains an optional choice and is not mandatory. > # Section 2.1.3 > > s/Currently/In 2023/ ? Sure, How about "As of 2023"? I think "in 2023" has some implication that they were assigned in the year 2023 when some were assigned earlier. > # Section 2.2.1 > > AFAIK, EUI-64 based IPv6 addresses are not officially deprecated (only > recommended not to be used by RFC 8064). I think "recommended not to be used" is exactly the definition of "deprecated". (This change was requested by and the wording OKed by Bob Hinden.) > # Section 2.2.2 > > Rather than using "02 bit" term, why not using the names of those bits? How about "the 0x02 bit (also known as the X or universal/local bit)". > # Section 2.4 and section 5.9 > > I am really puzzled by this section: what is the purpose of it? It seems to > be a CBOR encoding of IEEE OUI/address/identifier so really a CBOR document. I don't understand what's puzzling about this section. Its purpose is to specify a CBOR encoding of some IEEE identifiers. This was discussed on the CBOR WG mailing list. See the thread beginning with https://mailarchive.ietf.org/arch/msg/cbor/I49hlrHka1BUPAq8oCtO77xElvc/ This thread includes the message at https://mailarchive.ietf.org/arch/msg/cbor/I49hlrHka1BUPAq8oCtO77xElvc/ in which a CBOR WG decision to "leave Ethernet tags for Donald's rfc7042bis." was announced. There was also some consultation with Carsten Boreman, who in my opinion is a CBOR expert, on the wording of this section. (More formally, while those knowledgeable about a set of code points should be consulted and may frequently be concentrated in a WG, it is my understanding that in the IETF code points are not owned by WGs. They are owned by IANA which is charged with assigning them according to their assignment policies. And furthermore, such assignment policies cannot require the approval of a WG since WGs are intended to be focused, temporary entities. So, while the CBOR WG should be consulted as long as it is still around, and it was consulted in this case, I do not think that all text assigning CBOR tab values must be in a "CBOR document" adopted by and processed through the CBOR WG.) > Which document specifies the TBD1 and TBD2 in this section ? Just like most "tbd"s in an Internet Draft, they are specified in the IANA Considerations, in this case Section 5.9. > # Section 3 > > I like the added pieces of information as well as the change of the flow. > But, in ` after the MAC destination and source (or after a tag)` the word > "tag" is used *before* its definition ☹ Yes, I think "or after a tag" was added to the draft quite late and didn't take into account that "tag" was defined later. I will try re-wording this to solve the problem. > Is the order of source & destination MAC addresses correct ? I.e., > destination MAC address should be before the source MAC address, isn't it? You are absolutely right. I'm embarrassed by this error. I'll fix this. (Interesting that the 802.1 review didn't catch this.) > # Section 5 > > Does "Informational" need to be capitalized in ` IANA web page has > Informational lists` ? No, should probably be lower case. > # Section 5.1 > > Where are the sizes of small/medium defined (e.g., for "medium-size > assignments") ? There is a defined boundary between small/medium and large in Sections 2.1.5 for 48-bit MACs and 2.2.2 for 64-bit MAC MACs. Just how smallish/mediumish a block of MAC addresses is and just how stringently the expect should judge requests is left up to the judgement of the expert. There is no hard boundary between small and medium nor any need for a hard boundary. I suppose the wording could be changed to try to make it more clear that it is a sliding scale but the current wording is taken from RFC 7042 and has proven to be adequate. > # Section 5.3 > > A previous section states that all reference to RFC 7042 must be replaced and > table 3 contains RFC 7042 Only the references to RFC 7042 on the two IANA pages of IEEE identifiers are changed. Table 3 refers to the AFN table which is a different web page and is not changed, the logic being that these entries should reference the RFC that caused them to be assigned. > Table 4: I think that the vertical bar (the pipe '|') at the left of RRTYPE > Code should be removed. In the .txt output, there are vertical bars before and after RRTYPE in this table to show that it applies to both of the columns below. I believe only those two columns are "RRTYPE Codes" which implies a number. I think the column just before those, with a mnemonic, is an RRTYPE (or RR type), not an "RRTYPE Code". (I notice that in the pdf and the html'ized outputs, there are no vertical bars.) But maybe I'm being too persnickety. > # Section 5.5 > > I find the location of this section in the flow a little weird. Should it be > moved at the end ? The end of Section 5? I guess it could be moved there but I'm not sure that would help much. > Did IANA make a review of this important part ? Yes, at IETF 116 in San Francisco I physically met with IANA during the IANA open office hours and sat with them as they reviewed and OKed this part. > # Section 5.9 > > See above my comments about the usefulness of the CBOR. See my response above. > Also, specify the exact registry name. Sure, it's "Concise Binary Object Representation (CBOR) Tags". Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e...@gmail.com _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
