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

Received changes through RFC Editor sync (changed state to RFC, created became rfc relationship between draft-ietf-intarea-rfc7042bis and RFC 9542, changed IESG state to RFC Published)

[Ballot comment]
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?

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

[Ballot comment]
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.

[Ballot discuss]
Be ye not afraid by this discuss; it's simply a request to have a discussion - https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/

I had initially started writing this as NoObjection ballot, but while doing so I realized that I was sufficiently concerned that a discuss DISCUSS seemed appropriate.

I am uncomfortable about the creation of the "IESG Ratification" type and process; it feels like lots of additional complexity and over-specification, and like it is leading the IETF towards much more of a "process driven" (vs "Do the Right Thing") type organization.

Section 1 says: "[RFC8126] is incorporated herein except where there are contrary provisions in this document.  In this document, "IESG Ratification" is used in some cases.  "IESG Ratification" is specified in Section 5.1.  It is NOT the same as "IESG Approval" in [RFC8126].", and Section 5.1 has a long section on "If the assignment is based on IESG Ratification:".

I'm unclear why there are not just 2 assignment ranges / types -- 1: Expert Review and 2: IESG Approval. The "based on IESG Ratification" section sounds very similar to the regular "IESG Approval". [RFC5771 - "IANA Guidelines for IPv4 Multicast Address Assignments"](https://datatracker.ietf.org/doc/rfc5771/) does something quite similar to this document, but uses the existing RFC8126 process. It seems like asking the IANA to first pass requests through the Experts, and, if the range is one of the "large" ones, it gets IESG approval after that -- this is almost exactly the same thing as this document describes, but without creating a new name/type of process.

I'm more than happy to be schooled as to why I'm wrong....

[Ballot comment]
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.

[Ballot comment]
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).

[Ballot comment]
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

[Ballot 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 .

        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

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-intarea-rfc7042bis-10. If any part of this review is inaccurate, please let us know.

IANA has questions about the first, second, third and fourth actions requested in the IANA Considerations section of this document.

IANA understands that, upon approval of this document, there are eight actions which we must complete.

First, the Ethernet Numbers registry group will be renamed to the IANA OUI Ethernet Numbers registry group. The registry group is currently located at:

https://www.iana.org/assignments/ethernet-numbers/

In this registry group, any references to [RFC7042] will be changed to [ RFC-to-be ]. References in other IANA registries to [RFC7042] are not changed.

IANA Question --> Should we change the URL to this registry group? If you would like us to change the URL, we will have the old URL redirect to the new one.

Second, in Section 5.3 of the current draft, the authors document existing assignments for Address Family Numbers and DNS RRTYPEs.

IANA Question --> Is there any IANA action required for the material in Section 5.3, or is it placed there to document previous IANA actions?

Third, Section 5.4 of the current draft states that the experts for the IEEE 802 Numbers registry will provide new notes and information for this registry group at a later date.

IANA Question --> Is this the registry group to which Section 5.4 refers?

https://www.iana.org/assignments/ieee-802-numbers/

Fourth, Section 5.5 describes the EtherType assignment process and provides an example of how to include both IANA and IEEE assignments in an Internet-Draft.

IANA Question --> Is there any IANA action required for the material in Section 5.5, or is it placed there to document the process for future registrations?

Fifth, in the Ethernet Numbers registry group located at:

https://www.iana.org/assignments/ethernet-numbers/

The Notes for the IANA Unicast 48-bit MAC Addresses registry and for the IANA Multicast 48-bit MAC Addresses registry are changed to the following:

"These values are prefixed with 00-00-5E. See Section 2.1.5 of [ RFC-to-be ]."

The Note for the IANA 64-bit MAC Addresses registry is changed to the following:

"These values are prefixed with 00-00-5E to form unicast MAC addresses, with 01-00-5E to form multicast MAC addresses, with 02-00-5E to form unicast modified EUI-64 addresses, and with 03-00-5E to form multicast modified EUI-64 addresses. See [ RFC-to-be ], particularly Section 2.2.2, for more details."

Sixth, the "IANA Link Layer Discovery Protocol (LLDP) TLV Subtypes" registry from the IANA IEEE 802 Numbers registry group located at:

https://www.iana.org/assignments/ieee-802-numbers/

will be moved to the newly renamed IANA OUI Ethernet Numbers registry group located at:

https://www.iana.org/assignments/ethernet-numbers/

and [ RFC-to-be ] will be added as a reference for the "IANA Link Layer Discovery Protocol (LLDP) TLV Subtypes" registry.

Seventh, in the "IANA Link Layer Discovery Protocol (LLDP) TLV Subtypes" registry now moved to the newly renamed IANA OUI Ethernet Numbers registry group located at:

https://www.iana.org/assignments/ethernet-numbers/

three existing registrations have their references changed to [ RFC-to-be ]:

Value: 0
Description: Reserved
Reference: [ RFC-to-be ]

Value: 42
Description: Example for use in documentation
Reference: [ RFC-to-be ]

Value: 255
Description: Reserved
Reference: [ RFC-to-be ]

Eighth, in the Concise Binary Object Representation (CBOR) Tags registry located at:

https://www.iana.org/assignments/cbor-tags/

two new registrations will be made as follows:

Tag: [ TBD-at-Registration ]
Data Item: byte string
Semantics: IEEE MAC Address
Reference: [ RFC-to-be ]
Template:

Tag: [ TBD-at-Registration ]
Data Item: byte string
Semantics: IEEE OUI/CID
Reference: [ RFC-to-be ]
Template:

We understand that the authors have requested values 48 and 49 for these registrations.

We understand that these are the only actions required to be completed upon approval of this document.

NOTE: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

# Document History

Title: IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters

Revision: draft-ietf-intarea-rfc7042bis-09

Shepherd: Luigi Iannone (ggx@gigix.net)

Writeup Template: https://datatracker.ietf.org/doc/shepherdwriteup-template/workinggroup



1. Does the working group (WG) consensus represent the strong concurrence of a few individuals, with others being silent, or did it reach broad agreement?

    The mailing list archives shows that even if the number of emails in support of the last call is not huge there were no objections in moving this document forward. During the meetings there was a general support for this document and the need to update RFC 7042 (which this document actually obsoletes). 

2. Was there controversy about particular points, or were there decisions where the consensus was particularly rough?

    No.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

    No one showed any form of discontent.

4. For protocol documents, are there existing implementations of the contents of the document? Have a significant number of potential implementers indicated plans to implement? Are any existing implementations reported somewhere, either in the document itself (as RFC 7942 recommends) or elsewhere (where)?

    The document does not specify a protocol.

# Additional Reviews

5. Do the contents of this document closely interact with technologies in other IETF working groups or external organizations, and would it therefore benefit from their review? Have those reviews occurred? If yes, describe which reviews took place.

    The content of the document interact with technologies developed by IEEE. The latter already reviewed the document and the related statement can be found at: https://datatracker.ietf.org/liaison/1823/

    Section 2.4 of the document is about Concise Binary Object Representation (CBOR) tags used to indicate MAC addresses and organizational idetifiers (OUI, CID, or CF). Discussion has taken place in the CBOR WG, on wheter the content of such section belongs elsewhere. Please refer to the thread https://mailarchive.ietf.org/arch/msg/cbor/I49hlrHka1BUPAq8oCtO77xElvc/ and the message https://mailarchive.ietf.org/arch/msg/cbor/h2FGrQ7Uw0PX4NdHO7Rn07rCbtI/ . The latter clearly indicating that the issue has been discussed in the a CBOR WG meeting and agreed "to leave Ethernet tags for Donald's rfc7042bis. (despite that being informational and a possible downref issue)". Minutes of the CBORWG interim meeting can be found at: https://datatracker.ietf.org/meeting/interim-2021-cbor-18/materials/minutes-interim-2021-cbor-18-202110061600-00.pdf


6. Describe how the document meets any required formal expert review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

    No formal review is required.

7. If the document contains a YANG module, has the final version of the module been checked with any of the recommended validation tools for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC 8342?

    This document does not contain a YANG Module.


8. Describe reviews and automated checks performed to validate sections of the final version of the document written in a formal language, such as XML code, BNF rules, MIB definitions, CBOR's CDDL, etc.

    The document does not contain anything written in a formal language, hence, no validation and/or check has been performed.

# Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this document is needed, clearly written, complete, correctly designed, and ready to be handed off to the responsible Area Director?

    The document is clearly written, needed, and ready to be handed off to the responsible AD.

10. Several IETF Areas have assembled lists of common issues that their reviewers encounter. For which areas have such issues been identified and addressed? For which does this still need to happen in subsequent reviews?

    The document does not touch any issue listed at: https://wiki.ietf.org/group/iesg/ExpertTopics

11. What type of RFC publication is being requested on the IETF stream (Best Current Practice, Proposed Standard, Internet Standard, Informational, Experimental or Historic)? Why is this the proper type of RFC? Do all Datatracker state attributes correctly reflect this intent?

    This document request to be published as Best Current Practice, also shown in the datatracker. It is because of its content and because it replaces RFC 7042 which is also Best Current Practice. 

12. Have reasonable efforts been made to remind all authors of the intellectual property rights (IPR) disclosure obligations described in BCP 79? To the best of your knowledge, have all required disclosures been filed? If not, explain why. If yes, summarize any relevant discussion, including links to publicly-available messages when applicable.

    All the co-authors, during WG last call, did state explicitly that they are not aware of any IPR related to this document. No one else did any IPR disclosure. 

13. Has each author, editor, and contributor shown their willingness to be listed as such? If the total number of authors and editors on the front page is greater than five, please provide a justification.

    Each co-author is clearly willing to be listed as such.

14. Document any remaining I-D nits in this document. Simply running the idnits tool is not enough; please review the "Content Guidelines" on authors.ietf.org. (Also note that the current idnits tool generates some incorrect warnings; a rewrite is underway.)

    The idnits shows 3 comments:
   
    - A reference misinterpretation in Appendix B.1. The text is actually correct, no changes needed.
    - A non-existing downref. Reference [IEEE802.1AB] is considered a downref by the tool because is a non-RFC normative reference, but normative is actually the right type of reference.
    - Obsolete informational reference to RFC 5342 (obsoleted by RFC 7042). This reference is intentional and does not need to be fixed.
   
    While reviewing this document I did not spot any other issue.


15. Should any informative references be normative or vice-versa? See the IESG Statement on Normative and Informative References.

    No reference should change type.

16. List any normative references that are not freely available to anyone. Did the community have sufficient access to review any such normative references?

    Normative references [IEEE802_OandA], [IEEE802.1AB], and [IEEE.802.1Q_2014] are not freely available. They can be either purchased individually or a subscription to ieeexplore. However, IEEE 802 standards are available for free download for personal use starting 6-months after their publication under the "Get 802" program. As such the community has sufficient access to review these documents. 

17. Are there any normative downward references (see RFC 3967 and BCP 97) that are not already listed in the DOWNREF registry? If so, list them.

    No normative downward references.
s
18. Are there normative references to documents that are not ready to be submitted to the IESG for publication or are otherwise in an unclear state? If so, what is the plan for their completion?

    No normative references are in unclear state or not ready.

19. Will publication of this document change the status of any existing RFCs? If so, does the Datatracker metadata correctly reflect this and are those RFCs listed on the title page, in the abstract, and discussed in the introduction? If not, explain why and point to the part of the document where the relationship of this document to these other RFCs is discussed.

    This document will obsolete RFC 7042, as stated in the relevant parts of the document. In particular, changes from RFC 7042 are discussed in section 1.2 of the document. The datatracker meta-data is not yet updated (this can be done during AD Review). 

20. Describe the document shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all aspects of the document requiring IANA assignments are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that each newly created IANA registry specifies its initial contents, allocations procedures, and a reasonable name (see RFC 8126).

    The whole document is an IANA Consideration. The content is consistent. The document does not request the creation of new registries neither any new assignment. However, a few updates are requested to IANA, namely:
    - The IANA "Ethernet Numbers" web page is re-named the "IANA OUI Ethernet Numbers" web page.
    - References to [RFC7042] in IANA registries on both the IANA IEEE 802 Numbers web page and the IANA IETF OUI Ethernet Numbers web pages will be replaced by references to this document.
    - IANA is requested to move the "IANA Link Layer Discovery Protocol (LLDP) TLV Subtypes" Registry from the IANA IEEE 802 Numbers web page to the IANA OUI Ethernet Numbers web page, and to add this document as an additional reference for that registry. IANA is requested to update three entries in that Registry as follows:

        | Value | Description                      | Reference      |
        |-------|----------------------------------|-----------------|
        |    0 | Reserved                        | [this document] |
        |    42 | Example for use in documentation | [this document] |
        |  255 | Reserved                        | [this document] |

    - IANA is requested to assign two CBOR Tags:
   
        | Tag  | Data Item  | Semantics        | Reference      |
        |------|-------------|------------------|-----------------|
        | TBD1 | byte string | IEEE MAC Address | [this document] |
        | TBD2 | byte string | IEEE OUI/CID    | [this document] |


21. List any new IANA registries that require Designated Expert Review for future allocations. Are the instructions to the Designated Expert clear? Please include suggestions of designated experts, if appropriate.

    No new registries are created. Section 5 contains clarifications for the Expert Review for existing registries.

The following Last Call announcement was sent out (ends 2023-10-12):

From: The IESG
To: IETF-Announce
CC: draft-ietf-intarea-rfc7042bis@ietf.org, evyncke@cisco.com, ggx@gigix.net, int-area@ietf.org, intarea-chairs@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters) to Best Current Practice


The IESG has received a request from the Internet Area Working Group WG
(intarea) to consider the following document: - 'IANA Considerations and IETF
Protocol and Documentation Usage for IEEE
  802 Parameters'
  as Best Current Practice

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2023-10-12. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  Some IETF protocols make use of Ethernet frame formats and IEEE 802
  parameters.  This document discusses several aspects of such
  parameters and their use in IETF protocols, specifies IANA
  considerations for assignment of points under the IANA OUI
  (Organizationally Unique Identifier), and provides some values for
  use in documentation.  This document obsoletes RFC 7042.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-intarea-rfc7042bis/

The IESG will also welcome feedback on one specific topic raised by the responsible AD:
https://mailarchive.ietf.org/arch/msg/int-area/uf7MZFktoQKohLXlhkCBK01-tGM/

No IPR declarations have been submitted directly on this I-D.

# Document History

Title: IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters

Revision: draft-ietf-intarea-rfc7042bis-05

Shepherd: Luigi Iannone (ggx@gigix.net)

Writeup Template: https://datatracker.ietf.org/doc/shepherdwriteup-template/workinggroup



1. Does the working group (WG) consensus represent the strong concurrence of a few individuals, with others being silent, or did it reach broad agreement?

    The mailing list archives shows that even if the number of emails in support of the last call is not huge there were no objections in moving this document forward. During the meetings there was a general support for this document and the need to update RFC 7042 (which this document actually obsoletes). 

2. Was there controversy about particular points, or were there decisions where the consensus was particularly rough?

    No.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

    No one showed any form of discontent.

4. For protocol documents, are there existing implementations of the contents of the document? Have a significant number of potential implementers indicated plans to implement? Are any existing implementations reported somewhere, either in the document itself (as RFC 7942 recommends) or elsewhere (where)?

    The document does not specify a protocol.

# Additional Reviews

5. Do the contents of this document closely interact with technologies in other IETF working groups or external organizations, and would it therefore benefit from their review? Have those reviews occurred? If yes, describe which reviews took place.

    The content of the document interact with technologies developed by IEEE. The latter already reviewed the document and the related statement can be found at: https://datatracker.ietf.org/liaison/1823/

6. Describe how the document meets any required formal expert review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

    No formal review is required.

7. If the document contains a YANG module, has the final version of the module been checked with any of the recommended validation tools for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC 8342?

    This document does not contain a YANG Module.


8. Describe reviews and automated checks performed to validate sections of the final version of the document written in a formal language, such as XML code, BNF rules, MIB definitions, CBOR's CDDL, etc.

    The document does not contain anything written in a formal language, hence, no validation and/or check has been performed.

# Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this document is needed, clearly written, complete, correctly designed, and ready to be handed off to the responsible Area Director?

    The document is clearly written, needed, and ready to be handed off to the responsible AD.

10. Several IETF Areas have assembled lists of common issues that their reviewers encounter. For which areas have such issues been identified and addressed? For which does this still need to happen in subsequent reviews?

    The document does not touch any issue listed at: https://wiki.ietf.org/group/iesg/ExpertTopics

11. What type of RFC publication is being requested on the IETF stream (Best Current Practice, Proposed Standard, Internet Standard, Informational, Experimental or Historic)? Why is this the proper type of RFC? Do all Datatracker state attributes correctly reflect this intent?

    This document request to be published as Best Current Practice, also shown in the datatracker. It is because of its content and because it replaces RFC 7042 which is also Best Current Practice. 

12. Have reasonable efforts been made to remind all authors of the intellectual property rights (IPR) disclosure obligations described in BCP 79? To the best of your knowledge, have all required disclosures been filed? If not, explain why. If yes, summarize any relevant discussion, including links to publicly-available messages when applicable.

    All the co-authors, during WG last call, did state explicitly that they are not aware of any IPR related to this document. No one else did any IPR disclosure. 

13. Has each author, editor, and contributor shown their willingness to be listed as such? If the total number of authors and editors on the front page is greater than five, please provide a justification.

    Each co-author is clearly willing to be listed as such.

14. Document any remaining I-D nits in this document. Simply running the idnits tool is not enough; please review the "Content Guidelines" on authors.ietf.org. (Also note that the current idnits tool generates some incorrect warnings; a rewrite is underway.)

    The idnits shows 3 comments:
   
    - A reference misinterpretation in Appendix B.1. The text is actually correct, no changes needed.
    - A non-existing downref. Reference [IEEE802.1AB] is considered a downref by the tool because is a non-RFC normative reference, but normative is actually the right type of reference.
    - Obsolete informational reference to RFC 5342 (obsoleted by RFC 7042). This reference is intentional and does not need to be fixed.
   
    While reviewing this document I did not spot any other issue.


15. Should any informative references be normative or vice-versa? See the IESG Statement on Normative and Informative References.

    No reference should change type.

16. List any normative references that are not freely available to anyone. Did the community have sufficient access to review any such normative references?

    Normative references [IEEE802_OandA], [IEEE802.1AB], and [IEEE.802.1Q_2014] are not freely available. They can be either purchased individually or a subscription to ieeexplore. However, IEEE 802 standards are available for free download for personal use starting 6-months after their publication under the "Get 802" program. As such the community has sufficient access to review these documents. 

17. Are there any normative downward references (see RFC 3967 and BCP 97) that are not already listed in the DOWNREF registry? If so, list them.

    No normative downward references.
s
18. Are there normative references to documents that are not ready to be submitted to the IESG for publication or are otherwise in an unclear state? If so, what is the plan for their completion?

    No normative references are in unclear state or not ready.

19. Will publication of this document change the status of any existing RFCs? If so, does the Datatracker metadata correctly reflect this and are those RFCs listed on the title page, in the abstract, and discussed in the introduction? If not, explain why and point to the part of the document where the relationship of this document to these other RFCs is discussed.

    This document will obsolete RFC 7042, as stated in the relevant parts of the document. In particular, changes from RFC 7042 are discussed in section 1.2 of the document. The datatracker meta-data is not yet updated (this can be done during AD Review). 

20. Describe the document shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all aspects of the document requiring IANA assignments are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that each newly created IANA registry specifies its initial contents, allocations procedures, and a reasonable name (see RFC 8126).

    The whole document is an IANA Consideration. The content is consistent. The document does not request the creation of new registries neither any new assignment. However, a few updates are requested to IANA, namely:
    - The IANA "Ethernet Numbers" web page is re-named the "IANA OUI Ethernet Numbers" web page.
    - References to [RFC7042] in IANA registries on both the IANA IEEE 802 Numbers web page and the IANA IETF OUI Ethernet Numbers web pages will be replaced by references to this document.
    - IANA is requested to move the "IANA Link Layer Discovery Protocol (LLDP) TLV Subtypes" Registry from the IANA IEEE 802 Numbers web page to the IANA OUI Ethernet Numbers web page, and to add this document as an additional reference for that registry. IANA is requested to update three entries in that Registry as follows:

        | Value | Description                      | Reference      |
        |-------|----------------------------------|-----------------|
        |    0 | Reserved                        | [this document] |
        |    42 | Example for use in documentation | [this document] |
        |  255 | Reserved                        | [this document] |

    - IANA is requested to assign two CBOR Tags:
   
        | Tag  | Data Item  | Semantics        | Reference      |
        |------|-------------|------------------|-----------------|
        | TBD1 | byte string | IEEE MAC Address | [this document] |
        | TBD2 | byte string | IEEE OUI/CID    | [this document] |


21. List any new IANA registries that require Designated Expert Review for future allocations. Are the instructions to the Designated Expert clear? Please include suggestions of designated experts, if appropriate.

    No new registries are created. Section 5 contains clarifications for the Expert Review for existing registries.

# Document History

Title: IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters

Revision: draft-ietf-intarea-rfc7042bis-05

Shepherd: Luigi Iannone (ggx@gigix.net)

Writeup Template: https://datatracker.ietf.org/doc/shepherdwriteup-template/workinggroup



1. Does the working group (WG) consensus represent the strong concurrence of a few individuals, with others being silent, or did it reach broad agreement?

    The mailing list archives shows that even if the number of emails in support of the last call is not huge there were no objections in moving this document forward. During the meetings there was a general support for this document and the need to update RFC 7042 (which this document actually obsoletes). 

2. Was there controversy about particular points, or were there decisions where the consensus was particularly rough?

    No.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

    No one showed any form of discontent.

4. For protocol documents, are there existing implementations of the contents of the document? Have a significant number of potential implementers indicated plans to implement? Are any existing implementations reported somewhere, either in the document itself (as RFC 7942 recommends) or elsewhere (where)?

    The document does not specify a protocol.

# Additional Reviews

5. Do the contents of this document closely interact with technologies in other IETF working groups or external organizations, and would it therefore benefit from their review? Have those reviews occurred? If yes, describe which reviews took place.

    The content of the document interact with technologies developed by IEEE. The latter already reviewed the document and the related statement can be found at: https://datatracker.ietf.org/liaison/1823/

6. Describe how the document meets any required formal expert review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

    No formal review is required.

7. If the document contains a YANG module, has the final version of the module been checked with any of the recommended validation tools for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC 8342?

    This document does not contain a YANG Module.


8. Describe reviews and automated checks performed to validate sections of the final version of the document written in a formal language, such as XML code, BNF rules, MIB definitions, CBOR's CDDL, etc.

    The document does not contain anything written in a formal language, hence, no validation and/or check has been performed.

# Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this document is needed, clearly written, complete, correctly designed, and ready to be handed off to the responsible Area Director?

    The document is clearly written, needed, and ready to be handed off to the responsible AD.

10. Several IETF Areas have assembled lists of common issues that their reviewers encounter. For which areas have such issues been identified and addressed? For which does this still need to happen in subsequent reviews?

    The document does not touch any issue listed at: https://wiki.ietf.org/group/iesg/ExpertTopics

11. What type of RFC publication is being requested on the IETF stream (Best Current Practice, Proposed Standard, Internet Standard, Informational, Experimental or Historic)? Why is this the proper type of RFC? Do all Datatracker state attributes correctly reflect this intent?

    This document request to be published as Best Current Practice, also shown in the datatracker. It is because of its content and because it replaces RFC 7042 which is also Best Current Practice. 

12. Have reasonable efforts been made to remind all authors of the intellectual property rights (IPR) disclosure obligations described in BCP 79? To the best of your knowledge, have all required disclosures been filed? If not, explain why. If yes, summarize any relevant discussion, including links to publicly-available messages when applicable.

    All the co-authors, during WG last call, did state explicitly that they are not aware of any IPR related to this document. No one else did any IPR disclosure. 

13. Has each author, editor, and contributor shown their willingness to be listed as such? If the total number of authors and editors on the front page is greater than five, please provide a justification.

    Each co-author is clearly willing to be listed as such.

14. Document any remaining I-D nits in this document. Simply running the idnits tool is not enough; please review the "Content Guidelines" on authors.ietf.org. (Also note that the current idnits tool generates some incorrect warnings; a rewrite is underway.)

    The idnits shows 3 comments:
   
    - A reference misinterpretation in Appendix B.1. The text is actually correct, no changes needed.
    - A non-existing downref. Reference [IEEE802.1AB] is considered a downref by the tool because is a non-RFC normative reference, but normative is actually the right type of reference.
    - Obsolete informational reference to RFC 5342 (obsoleted by RFC 7042). This reference is intentional and does not need to be fixed.
   
    While reviewing this document I did not spot any other issue.


15. Should any informative references be normative or vice-versa? See the IESG Statement on Normative and Informative References.

    No reference should change type.

16. List any normative references that are not freely available to anyone. Did the community have sufficient access to review any such normative references?

    Normative references [IEEE802_OandA], [IEEE802.1AB], and [IEEE.802.1Q_2014] are not freely available. They can be either purchased individually or a subscription to ieeexplore. However, IEEE 802 standards are available for free download for personal use starting 6-months after their publication under the "Get 802" program. As such the community has sufficient access to review these documents. 

17. Are there any normative downward references (see RFC 3967 and BCP 97) that are not already listed in the DOWNREF registry? If so, list them.

    No normative downward references.
s
18. Are there normative references to documents that are not ready to be submitted to the IESG for publication or are otherwise in an unclear state? If so, what is the plan for their completion?

    No normative references are in unclear state or not ready.

19. Will publication of this document change the status of any existing RFCs? If so, does the Datatracker metadata correctly reflect this and are those RFCs listed on the title page, in the abstract, and discussed in the introduction? If not, explain why and point to the part of the document where the relationship of this document to these other RFCs is discussed.

    This document will obsolete RFC 7042, as stated in the relevant parts of the document. In particular, changes from RFC 7042 are discussed in section 1.2 of the document. The datatracker meta-data is not yet updated (this can be done during AD Review). 

20. Describe the document shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all aspects of the document requiring IANA assignments are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that each newly created IANA registry specifies its initial contents, allocations procedures, and a reasonable name (see RFC 8126).

    The whole document is an IANA Consideration. The content is consistent. The document does not request the creation of new registries neither any new assignment. However, a few updates are requested to IANA, namely:
    - The IANA "Ethernet Numbers" web page is re-named the "IANA OUI Ethernet Numbers" web page.
    - References to [RFC7042] in IANA registries on both the IANA IEEE 802 Numbers web page and the IANA IETF OUI Ethernet Numbers web pages will be replaced by references to this document.
    - IANA is requested to move the "IANA Link Layer Discovery Protocol (LLDP) TLV Subtypes" Registry from the IANA IEEE 802 Numbers web page to the IANA OUI Ethernet Numbers web page, and to add this document as an additional reference for that registry. IANA is requested to update three entries in that Registry as follows:

        | Value | Description                      | Reference      |
        |-------|----------------------------------|-----------------|
        |    0 | Reserved                        | [this document] |
        |    42 | Example for use in documentation | [this document] |
        |  255 | Reserved                        | [this document] |

    - IANA is requested to assign two CBOR Tags:
   
        | Tag  | Data Item  | Semantics        | Reference      |
        |------|-------------|------------------|-----------------|
        | TBD1 | byte string | IEEE MAC Address | [this document] |
        | TBD2 | byte string | IEEE OUI/CID    | [this document] |


21. List any new IANA registries that require Designated Expert Review for future allocations. Are the instructions to the Designated Expert clear? Please include suggestions of designated experts, if appropriate.

    No new registries are created. Section 5 contains clarifications for the Expert Review for existing registries.

# Document History

Title: IANA Considerations and IETF Protocol and DOcumentation Usage for IEEE 802 Parameters

Revision: draft-ietf-intarea-rfc7042bis-05

Shepherd: Luigi Iannone (ggx@gigix.net)

Writeup Template: https://datatracker.ietf.org/doc/shepherdwriteup-template/workinggroup



1. Does the working group (WG) consensus represent the strong concurrence of a few individuals, with others being silent, or did it reach broad agreement?

    The mailing list archives shows that even if the number of emails in support of the last call is not huge there were no objections in moving this document forward. During the meetings there was a general support for this document and the need to update RFC 7042 (which this document actually obsoletes). 

2. Was there controversy about particular points, or were there decisions where the consensus was particularly rough?

    No.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

    No one showed any form of discontent.

4. For protocol documents, are there existing implementations of the contents of the document? Have a significant number of potential implementers indicated plans to implement? Are any existing implementations reported somewhere, either in the document itself (as RFC 7942 recommends) or elsewhere (where)?

    The document does not specify a protocol.

# Additional Reviews

5. Do the contents of this document closely interact with technologies in other IETF working groups or external organizations, and would it therefore benefit from their review? Have those reviews occurred? If yes, describe which reviews took place.

    The content of the document interact with technologies developed by IEEE. The latter already reviewed the document and the related statement can be found at: https://datatracker.ietf.org/liaison/1823/

6. Describe how the document meets any required formal expert review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

    No formal review is required.

7. If the document contains a YANG module, has the final version of the module been checked with any of the recommended validation tools for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC 8342?

    This document does not contain a YANG Module.


8. Describe reviews and automated checks performed to validate sections of the final version of the document written in a formal language, such as XML code, BNF rules, MIB definitions, CBOR's CDDL, etc.

    The document does not contain anything written in a formal language, hence, no validation and/or check has been performed.

# Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this document is needed, clearly written, complete, correctly designed, and ready to be handed off to the responsible Area Director?

    The document is clearly written, needed, and ready to be handed off to the responsible AD.

10. Several IETF Areas have assembled lists of common issues that their reviewers encounter. For which areas have such issues been identified and addressed? For which does this still need to happen in subsequent reviews?

    The document does not touch any issue listed at: https://wiki.ietf.org/group/iesg/ExpertTopics

11. What type of RFC publication is being requested on the IETF stream (Best Current Practice, Proposed Standard, Internet Standard, Informational, Experimental or Historic)? Why is this the proper type of RFC? Do all Datatracker state attributes correctly reflect this intent?

    This document request to be published as Best Current Practice, also shown in the datatracker. It is because of its content and because it replaces RFC 7042 which is also Best Current Practice. 

12. Have reasonable efforts been made to remind all authors of the intellectual property rights (IPR) disclosure obligations described in BCP 79? To the best of your knowledge, have all required disclosures been filed? If not, explain why. If yes, summarize any relevant discussion, including links to publicly-available messages when applicable.

    All the co-authors, during WG last call, did state explicitly that they are not aware of any IPR related to this document. No one else did any IPR disclosure. 

13. Has each author, editor, and contributor shown their willingness to be listed as such? If the total number of authors and editors on the front page is greater than five, please provide a justification.

    Each co-author is clearly willing to be listed as such.

14. Document any remaining I-D nits in this document. Simply running the idnits tool is not enough; please review the "Content Guidelines" on authors.ietf.org. (Also note that the current idnits tool generates some incorrect warnings; a rewrite is underway.)

    The idnits shows 3 comments:
   
    - A reference misinterpretation in Appendix B.1. The text is actually correct, no changes needed.
    - A non-existing downref. Reference [IEEE802.1AB] is considered a downref by the tool because is a non-RFC normative reference, but normative is actually the right type of reference.
    - Obsolete informational reference to RFC 5342 (obsoleted by RFC 7042). This reference is intentional and does not need to be fixed.
   
    While reviewing this document I did not spot any other issue.


15. Should any informative references be normative or vice-versa? See the IESG Statement on Normative and Informative References.

    No reference should change type.

16. List any normative references that are not freely available to anyone. Did the community have sufficient access to review any such normative references?

    Normative references [IEEE802_OandA], [IEEE802.1AB], and [IEEE.802.1Q_2014] are not freely available. They must be either purchased individually or a subscription to ieeexplore is necessary. However, access to ieeexplore is common, and the community should have sufficient access to review these documents. 

17. Are there any normative downward references (see RFC 3967 and BCP 97) that are not already listed in the DOWNREF registry? If so, list them.

    No normative downward references.
s
18. Are there normative references to documents that are not ready to be submitted to the IESG for publication or are otherwise in an unclear state? If so, what is the plan for their completion?

    No normative references are in unclear state or not ready.

19. Will publication of this document change the status of any existing RFCs? If so, does the Datatracker metadata correctly reflect this and are those RFCs listed on the title page, in the abstract, and discussed in the introduction? If not, explain why and point to the part of the document where the relationship of this document to these other RFCs is discussed.

    This document will obsolete RFC 7042, as stated in the relevant parts of the document. In particular, changes from RFC 7042 are discussed in section 1.2 of the document. The datatracker meta-data is not yet updated (this can be done during AD Review). 

20. Describe the document shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all aspects of the document requiring IANA assignments are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that each newly created IANA registry specifies its initial contents, allocations procedures, and a reasonable name (see RFC 8126).

    The whole document is an IANA Consideration. The content is consistent. The document does not request the creation of new registries neither any new assignment. However, a few updates are requested to IANA, namely:
    - The IANA "Ethernet Numbers" web page is re-named the "IANA OUI Ethernet Numbers" web page.
    - References to [RFC7042] in IANA registries on both the IANA IEEE 802 Numbers web page and the IANA IETF OUI Ethernet Numbers web pages will be replaced by references to this document.
    - IANA is requested to move the "IANA Link Layer Discovery Protocol (LLDP) TLV Subtypes" Registry from the IANA IEEE 802 Numbers web page to the IANA OUI Ethernet Numbers web page, and to add this document as an additional reference for that registry. IANA is requested to update three entries in that Registry as follows:

| Value | Description                      | Reference      |
|-------|----------------------------------|-----------------|
|    0 | Reserved                        | [this document] |
|    42 | Example for use in documentation | [this document] |
|  255 | Reserved                        | [this document] |


- IANA is requested to assign two CBOR Tags:
   
| Tag  | Data Item  | Semantics        | Reference      |
|------|-------------|------------------|-----------------|
| TBD1 | byte string | IEEE MAC Address | [this document] |
| TBD2 | byte string | IEEE OUI/CID    | [this document] |

21. List any new IANA registries that require Designated Expert Review for future allocations. Are the instructions to the Designated Expert clear? Please include suggestions of designated experts, if appropriate.

    No new registries are created. Section 5 contains clarifications for the Expert Review for existing registries.

# Document History

Title: IANA Considerations and IETF Protocol and DOcumentation Usage for IEEE 802 Parameters

Revision: draft-ietf-intarea-rfc7042bis-05

Shepherd: Luigi Iannone (ggx@gigix.net)

Writeup Template: https://datatracker.ietf.org/doc/shepherdwriteup-template/workinggroup



1. Does the working group (WG) consensus represent the strong concurrence of a few individuals, with others being silent, or did it reach broad agreement?

    The mailing list archives shows that even if the number of emails in support of the last call is not huge there were no objections in moving this document forward. During the meetings there was a general support for this document and the need to update RFC 7042 (which this document actually obsoletes). 

2. Was there controversy about particular points, or were there decisions where the consensus was particularly rough?

    No.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

    No one showed any form of discontent.

4. For protocol documents, are there existing implementations of the contents of the document? Have a significant number of potential implementers indicated plans to implement? Are any existing implementations reported somewhere, either in the document itself (as RFC 7942 recommends) or elsewhere (where)?

    The document does not specify a protocol.

# Additional Reviews

5. Do the contents of this document closely interact with technologies in other IETF working groups or external organizations, and would it therefore benefit from their review? Have those reviews occurred? If yes, describe which reviews took place.

    The content of the document interact with technologies developed by IEEE. The latter already reviewed the document and the related statement can be found at: https://datatracker.ietf.org/liaison/1823/

6. Describe how the document meets any required formal expert review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

    No formal review is required.

7. If the document contains a YANG module, has the final version of the module been checked with any of the recommended validation tools for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC 8342?

    This document does not contain a YANG Module.


8. Describe reviews and automated checks performed to validate sections of the final version of the document written in a formal language, such as XML code, BNF rules, MIB definitions, CBOR's CDDL, etc.

    The document does not contain anything written in a formal language, hence, no validation and/or check has been performed.

# Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this document is needed, clearly written, complete, correctly designed, and ready to be handed off to the responsible Area Director?

    The document is clearly written, needed, and ready to be handed off to the responsible AD.

10. Several IETF Areas have assembled lists of common issues that their reviewers encounter. For which areas have such issues been identified and addressed? For which does this still need to happen in subsequent reviews?

    The document does not touch any issue listed at: https://wiki.ietf.org/group/iesg/ExpertTopics

11. What type of RFC publication is being requested on the IETF stream (Best Current Practice, Proposed Standard, Internet Standard, Informational, Experimental or Historic)? Why is this the proper type of RFC? Do all Datatracker state attributes correctly reflect this intent?

    This document request to be published as Best Current Practice, also shown in the datatracker. It is because of its content and because it replaces RFC 7042 which is also Best Current Practice. 

12. Have reasonable efforts been made to remind all authors of the intellectual property rights (IPR) disclosure obligations described in BCP 79? To the best of your knowledge, have all required disclosures been filed? If not, explain why. If yes, summarize any relevant discussion, including links to publicly-available messages when applicable.

    All the co-authors, during WG last call, did state explicitly that they are not aware of any IPR related to this document. No one else did any IPR disclosure. 

13. Has each author, editor, and contributor shown their willingness to be listed as such? If the total number of authors and editors on the front page is greater than five, please provide a justification.

    Each co-author is clearly willing to be listed as such.

14. Document any remaining I-D nits in this document. Simply running the idnits tool is not enough; please review the "Content Guidelines" on authors.ietf.org. (Also note that the current idnits tool generates some incorrect warnings; a rewrite is underway.)

    The idnits shows 3 comments:
   
    - A non ascii character (easy to fix later)
    - A reference misinterpretation in Appendix B.1. The text is actually correct, no changes needed.
    - A non-existing downref. Reference [IEEE802.1AB] is considered a downref by the tool because is a non-RFC normative reference, but normative is actually the right type of reference.

    While reviewing this document I did not spot any other issue (except a few typos already communicated to the authors).

15. Should any informative references be normative or vice-versa? See the IESG Statement on Normative and Informative References.

    No reference should change type.

16. List any normative references that are not freely available to anyone. Did the community have sufficient access to review any such normative references?

    Normative references [IEEE802_OandA], [IEEE802.1AB], and [IEEE.802.1Q_2014] are not freely available. They must be either purchased individually or a subscription to ieeexplore is necessary. However, access to ieeexplore is common and the community should have sufficient access to review these documents. 

17. Are there any normative downward references (see RFC 3967 and BCP 97) that are not already listed in the DOWNREF registry? If so, list them.

    No normative downward references.
s
18. Are there normative references to documents that are not ready to be submitted to the IESG for publication or are otherwise in an unclear state? If so, what is the plan for their completion?

    No normative references are in unclear state or not ready.

19. Will publication of this document change the status of any existing RFCs? If so, does the Datatracker metadata correctly reflect this and are those RFCs listed on the title page, in the abstract, and discussed in the introduction? If not, explain why and point to the part of the document where the relationship of this document to these other RFCs is discussed.

    This document will obsolete RFC 7042, as stated in the relevant parts of the document. In particular, changes from RFC 7042 are discussed in section 1.2 of the document. The datatracker meta-data is not yet updated (co-authors have been notified this can be done during AD Review). 

20. Describe the document shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all aspects of the document requiring IANA assignments are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that each newly created IANA registry specifies its initial contents, allocations procedures, and a reasonable name (see RFC 8126).

    The whole document is an IANA Consideration. The content is consistent. The document does not request the creation of new registries neither any new assignment. However, a few updates are requested to IANA.

21. List any new IANA registries that require Designated Expert Review for future allocations. Are the instructions to the Designated Expert clear? Please include suggestions of designated experts, if appropriate.

    No new registries are created. Section 5 contains clarifications for the Expert Review for existing registries.