IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters
draft-ietf-intarea-rfc7042bis-11

Thank you to Kyle Rose for the SECDIR review.

Section 6.  Since specific security concerns around MAC addresses were cite, I would recommend being more comprehensive.

OLD
   See [RFC7043] for security considerations on storing MAC addresses in
   the DNS.


NEW (rough text)

MAC addresses can be used as an identifier for tracking users and devices.  See [draft-ietf-madinas-mac-address-randomization] for related privacy considerations and a discussion of MAC address randomization to partially mitigate this threat.  Additionally, see [RFC7043] for the security and privacy considerations of publishing MAC addresses in DNS.

MAC addresses are an identifier provided by a device to the network.  On certain devices, MAC addresses are not static, and can be configured.  The network should exercise caution when using these addresses to enforce policy (e.g., addresses can be spoofed, and previously seen devices can return to the network with a new address).

Thank you for the work on this document.

I support Warren's DISCUSS. I also wanted to add that, as defined by https://www.rfc-editor.org/rfc/rfc8126.html#section-4.12 policies can be used in combination. So it would be appropriate to replace what now is defined as "IESG Ratification" with "IESG Approval with Expert Review". I believe you can still indicate to IANA that an Expert Review which is not approved by the expert does not need to get to the IESG (as you do now). So in practice you would have the same result using the existing policies. In terms of text, I think the sort of details you already have do not hurt and do not need to be removed, especially since they make it easier for IANA, and are not in contradiction with existing policies (I am thinking of the last paragraph of Section 5.1), once you remove the IESG Ratification term/concept. Hopefully Sabrina (in CC) can correct me if I am wrong, and will be able to give us her opinion during the telechat.

# 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 <iana@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

Although Section 1.1 defines "IAB", that term doesn't appear elsewhere in this document.  Same goes for "MAC-48".

Table 1 in Section 2.1 has a column label "Name>" that should be "Name".

Regarding Section 5.1, should IESG Ratification be invoked also in the case of an Expert Review that gets rejected, and the applicant wishes to appeal?

I support Lars' and Romans comments. In addition to the NEW text Roman offers, I think it might be worth citing RFC9416 as well

Hi,

Thanks for taking the time to update this document - it is quite a dry read!  I have a few minor comments for your consideration:

Minor level comments:

(1) p 4, sec 1.1.  Notations Used in This Document

   "MAC"  Media Access Control, not Message Authentication Code.
   "MAC-48"  A 48-bit MAC address.  This term is obsolete.  If globally
      unique, use EUI-48.

Note, this list doesn't appear to define EUI-48, only EUI.  Perhaps forward reference section 2.1 or add it to the list for completeness?


(2) p 6, sec 2.1.  48-Bit MAC Identifiers, OUIs, and Other Prefixes

                                  Table 1
   The bottom (least significant) four bits of the first octet of the
   3-octet 48-bit MAC have special meaning, as shown in Figure 1, and
   are referred to below as the M, X, Y, and Z bits.

By 3-octet 48-bit MAC, are you referring to MA-L?  Otherwise, I would assume that all 48-bit MACs are 6-octets long ...


(3) p 10, sec 2.1.5.  48-Bit IANA MAC Assignment Considerations

   *  must be documented in an Internet-Draft or RFC.

If they are in an Internet-Draft then is that sufficient for a permanent assignment, or only a temporary one.  Anyone can write an internet-draft ...

Regards,
Rob

Thank you very much for writing this document; it seems useful and important, and is well written to boot!

Much thanks to Patrick Mevzek for the DNS-Dir review (https://datatracker.ietf.org/doc/review-ietf-intarea-rfc7042bis-10-dnsdir-lc-mevzek-2023-10-10/), and for following up when the new version was posted.