Hi Lars, See responses below.
On Fri, Oct 13, 2023 at 6:57 AM Lars Eggert via Datatracker < nore...@ietf.org> wrote: > > Lars Eggert has entered the following ballot position for > draft-ietf-intarea-rfc7042bis-10: No Objection > > ... > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > # GEN AD review of draft-ietf-intarea-rfc7042bis-10 > > CC @larseggert > > Thanks to Dale Worley for the General Area Review Team (Gen-ART) review > (https://mailarchive.ietf.org/arch/msg/gen-art/_mDDh3vMSfiiuA_c9CjQ1H9CZss ). > > ## Comments > > ### Section 5.1, paragraph 0 > ``` > 5.1. Expert Review and IESG Ratification > ``` > The RFC8126 term is "IESG Approval", not "IESG Ratification". Please > change this throughout. MAC addresses are unique in that assignments of one or two are reasonable for many purposes but it is also reasonable to assign huge blocks of MAC addresses, as has been done in several cases. I cannot off hand think of another IANA registry for which allocation of a large number of values, say 20% of all unassigned values, is sometimes reasonable. For small numbers of addresses, the draft uses Expert Review as specified in RFC 8126. For large blocks of addresses, it does NOT use IESG Approval as specified in RFC 8126 -- instead it uses a different process involving elements of expert review and elements of IESG approval as specified in this document and consistently called IESG Ratification throughout this document. It has been called IESG Ratification for 15 years under predecessor documents back to RFC 5342 despite RFC 8126 predecessor documents to RFC 8126. I believe that if the IESG Ratification process in this document were called IESG Approval it would create confusion and mislead some people into thinking it was the same as RFC 8126 IESG Approval. It is particularly important that the "Registration Procedures" in the IANA Registry ( https://www.iana.org/assignments/ethernet-numbers/ethernet-numbers.xhtml) not say IESG Approval as that would be misleading. > ### Section 5.1, paragraph 3 > ``` > multicast code point space.) In those cases, and in cases of the > assignment of "reserved" values, IESG Ratification of an Expert > Review approval recommendation is required as described below. The > procedure is as follows: > ``` > "required" here should be REQUIRED? I don't really care whether this is uppercased or not but there are no RFC 2119 keywords in this document currently and no reference to RFC 2119 and REQUIRED is not an RFC 2119 keyword... I think it is not customary to use interoperability style all caps words when talking about approval processes for IANA assignments. > ### Section 5.1, paragraph 9 > ``` > The applicant always completes the appropriate template from > Appendix A below and sends it to IANA <i...@iana.org>. > > IANA always sends the template to an appointed Expert. If the > Expert recuses themselves or is non-responsive, IANA may choose an > alternative appointed Expert or, if none is available, will > contact the IESG. > > In all cases, if IANA receives a disapproval from an Expert > selected to review an application template, the application will > be denied. The Expert should provide a reason for refusal which > IANA will communicate back to the applicant. > > If the assignment is based on Expert Review: > > If IANA receives approval and code points are available, > IANA will make the requested assignment. > > If the assignment is based on IESG Ratification: > > The procedure starts with the first steps above for Expert > Review. If the Expert disapproves the application, they > simply inform IANA who in turn informs the applicant that > their request is denied; however, if the Expert believes the > application should be approved, or is uncertain and believes > that the circumstances warrant the attention of the IESG, > the Expert will inform IANA about their advice, and IANA > will forward the application, together with the reasons > provided by the Expert for approval or uncertainty, to the > IESG. The IESG must decide whether the assignment will be > granted. This can be accomplished by a management item in > an IESG telechat as is done for other types of requests. If > the IESG decides not to ratify a favorable opinion by the > Expert or decides against an application where the Expert is > uncertain, the application is denied; otherwise, it is > granted. The IESG will communicate its decision to the > Expert and to IANA. In case of refusal, the IESG should > provide a reason which IANA will communicate to the > applicant. > ``` > Is there any reason for this level of operational detail in this > document? Some of this is redundant with RFC8126, others parts seem > to needlessly constrain operations. Questions keep coming up and people ask for clarifications. It is my impression that IANA and others have been happy to have a clear process flow so everyone will understand what should happen. As I recall the sentence about IESG approval being accomplished by a management item in an IESG telechat was specifically added to RFC 5342 during either AD or IESG review of the draft that became RFC 5342. > ### Section 5.4, paragraph 1 > ``` > 5.4. Informational IANA Web Page Material > > IANA maintains an informational listing on its web site concerning > EtherTypes, OUIs, and multicast addresses assigned under OUIs other > than the IANA OUI. The title of this informational registry is "IEEE > 802 Numbers". IANA will update that informational registry when > changes are provided by or approved by the Expert(s). > ``` > Ditto. How IANA operationally manages their web page seems really out > of scope. References to "web page" should be changed to the current IANA term "registry group", which is more flexible. However, these are registries, even if they are informational. The whole idea of IANA operations is that additions/deletions/modifications to registry entries should require only minimal judgement on the part of IANA. IANA occasionally receives requests to add or modify entries in these registries and the judgement as to whether to accommodate such requests should be the Expert's, not IANA's. > ### Section 5.6, paragraph 1 > ``` > 5.6. OUI Exhaustion > > When the available space for either multicast or unicast EUI-48 > identifiers under OUI 00-00-5E has been 90% or more exhausted, IANA > should request an additional OUI from the IEEE Registration Authority > for further IANA assignment. The appointed Expert(s) should monitor > for this condition and notify IANA. > ``` > Can IANA really make this request or does it need to come from the > IETF/IESG? Sure. The registries are IANA's even if the IETF gets to specify the assignment policy. It does not seem likely that this exhaustion criterion will be met anytime soon and when it is, this document would probably require revisions, but that seems to happen periodically anyway (RFC5342 -> RFC7042 -> rfc7042bis) 😊. > ### Inclusive language > > Found terminology that should be reviewed for inclusivity; see > https://www.rfc-editor.org/part2/#inclusive_language for background and more > guidance: > > * Term `traditionally`; alternatives might be `classic`, `classical`, > `common`, `conventional`, `customary`, `fixed`, `habitual`, `historic`, > `long-established`, `popular`, `prescribed`, `regular`, `rooted`, > `time-honored`, `universal`, `widely used`, `widespread` OK. > ## Nits > > All comments below are about very minor potential issues that you may choose to > address in some way - or ignore - as you see fit. Some were flagged by > automated tools (via https://github.com/larseggert/ietf-reviewtool), so there > will likely be some false positives. There is no need to let me know what you > did with these suggestions. > > ### Typos Thanks for the items below. Will fix except that the reference to obsoleted RFC 5342 is intended. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e...@gmail.com > #### Section 1, paragraph 2 > ``` > - organanizationally unique code points based on that OUI. This > - -- > ``` > > #### Section 3, paragraph 1 > ``` > - begining of a frame, the contents of that frame -- for example, that > + beginning of a frame, the contents of that frame -- for example, that > + + > ``` > > #### Section 3, paragraph 3 > ``` > - MAC addreses. [IEEE802_OandA] specifies two EtherTypes for local, > + MAC addresses. [IEEE802_OandA] specifies two EtherTypes for local, > + + > ``` > > #### Section 3, paragraph 4 > ``` > - MAC addreses. In that figure, the CTL (control) field value of 3 > + MAC addresses. In that figure, the CTL (control) field value of 3 > + + > ``` > > ### Outdated references > > Reference `[RFC5342]` to `RFC5342`, which was obsoleted by `RFC7042` (this may > be on purpose). > > ### URLs > > These URLs in the document can probably be converted to HTTPS: > > * http://ieeexplore.ieee.org/servlet/opac?punumber=6419733 > * http://www.ieee802.org > * http://ieeexplore.ieee.org/servlet/opac?punumber=6178209 > * http://standards.ieee.org/regauth/ethertype/eth.txt > * http://www.iana.org/assignments/ppp-numbers > * http://www.iana.org > * http://standards.ieee.org/products-programs/regauth/ > * http://www.iana.org/assignments/ethernet-numbers > * http://ieeexplore.ieee.org/servlet/opac?punumber=6991460 > > ### Grammar/style > > #### Section 2.3.2, paragraph 1 > ``` > dentifier. The enclosed data item is a octet string of length 3 to hold the > ^ > ``` > Use "an" instead of "a" if the following word starts with a vowel sound, e.g. > "an article", "an hour". > > #### Section 5.1, paragraph 11 > ``` > s an informational listing on its web site concerning EtherTypes, OUIs, and > ^^^^^^^^ > ``` > Nowadays, it's more common to write this as one word. > > #### Section 8, paragraph 25 > ``` > an informational list on the IANA web site of some important EtherTypes spec > ^^^^^^^^ > ``` > Nowadays, it's more common to write this as one word. > > ## Notes > > This review is in the ["IETF Comments" Markdown format][ICMF], You can use the > [`ietf-comments` tool][ICT] to automatically convert this review into > individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT]. > > [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md > [ICT]: https://github.com/mnot/ietf-comments > [IRT]: https://github.com/larseggert/ietf-reviewtool
_______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
