Lars Eggert has entered the following ballot position for draft-ietf-intarea-rfc7042bis-10: No Objection
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-intarea-rfc7042bis/ ---------------------------------------------------------------------- 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. ### 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? ### 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. ### 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. ### 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? ### 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` ## 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 #### 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
