On Wed, Sep 13, 2023 at 12:54 AM Donald Eastlake <d3e...@gmail.com> wrote: > > 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.
Sorry, that was IETF 117 in San Francisco. (Also, I might mention that some of the recent focus on Ethertype assignment was due to the activity around draft-raviolli-intarea-trusted-domain-srv6) Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e...@gmail.com > > # 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
