Re: [auth48] AUTH48: RFC-to-be 9542 <draft-ietf-intarea-rfc7042bis-11> for your review

[Donald Eastlake <[e-mail]>]

Hi,

On Fri, Apr 5, 2024 at 2:22 AM <[e-mail]> wrote:
>
> Authors,
>
> While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the XML file.
>
> 1) <!--[rfced] FYI, because this document obsoletes RFC 7042,
> it has been assigned BCP 141 (the same BCP number as RFC 7042).
> If you prefer otherwise, please let us know.
> -->

That's the right thing.

> 2) <!-- [rfced] Please insert any keywords (beyond those that appear
> in the title) for use on https://www.rfc-editor.org/search. -->

All the keywords from RFC 7042 should carry over. I believe those are
      Ethernet, EtherType, 802, OUI, EUI, LSAP
In addition you should add the following keywords
      AFN, CBOR, LLC, SLAP, SNAP, CID

> 3) <!--[rfced] To avoid this hyphenation, may we update "IEEE
> 802-related" as follows?
>
> Original:
>    Some IETF protocols use Ethernet or other IEEE 802-related
>    communication frame formats and parameters [IEEE802].
>    ...
>    IEEE Std 802 describes assignment procedures and policies for IEEE
>    802-related identifiers [IEEE802_OandA].
>
> Perhaps:
>    Some IETF protocols use Ethernet or other
>    communication frame formats and parameters related to IEEE 802 [IEEE802].
>    ...
>    IEEE Std 802 describes assignment procedures and policies for
>    identifiers related to IEEE 802 [IEEE802_OandA].
> -->

OK.

> 4) <!--[rfced] Section 1.1: We suggest removing the quotation marks
> from this section, as they are not typically used in this manner.
> (Although they are used in RFC 7042, this is an opportunity to
> improve the document.) Please let us know if this change is
> acceptable.
>
> Current:
>    "AFN"       Address Family Number [RFC4760].
>
>    "CBOR"      Concise Binary Object Representation [RFC8949].
>
>    "CFM"       Connectivity Fault Management [RFC7319].
>
>    [...]
>
> Suggested:
>    AFN       Address Family Number [RFC4760].
>
>    CBOR      Concise Binary Object Representation [RFC8949].
>
>    CFM       Connectivity Fault Management [RFC7319].
>
>    [...]
> -->

I would prefer to leave in the quote marks notwithstanding that this
is not consistent with many other RFCs. My reasons are (1) the last
entry for "**" would be confusing without the quotes and confusing in
a different way if it was the only entry with quotes, (2) there are a
few multi-word entries for which I think the quotes help a little, and
(3) this is consistent with the previous RFCs in this series: 7042 and
5342.

> 5) <!-- [rfced] Please review whether any of the notes in this
> document (for example, the text marked "Historical Note" or "NOTE")
> should be in the <aside> element. It is defined as "a container for
> content that is semantically less important or tangential to the
> content that surrounds it"
> (https://authors.ietf.org/en/rfcxml-vocabulary#aside). -->

An interesting question. Examining the "Notes" in this document, I
believe the one in the first part of Section 2 and the one in Section
2.3.1, that is to say the two "historical" notes, would reasonably be
viewed as "asides". On the other hand, the two notes in Section 2.1.1
and the one in Section 5 are important parts of the main text of the
document.

Also, I notice that the two notes in Section 2.1.1 are somewhat
indented and by different amounts. I think this just follows the draft
but seems wrong to the extent that it may give the false impression
that they are both subsidiary to the "Standard Assignment - ..." item
just above them while only the first note is. I suggest making the
second of these two notes have the same indentation as the main body
text (3 spaces for .txt, flush left for .pdf, ...).

> 6) <!--[rfced] Would it be accurate for these instances of "2023"
> to be updated to "2024"? It seems the year of publication would
> make more sense here.
> Original:
>    As of 2023 there
>    are three lengths of prefixes assigned, as shown in the table below;
>    however, some prefix bits can have special meaning as shown in
>    Figure 1.
>    ...
>    As of 2023, 4 out of these 256 values have been
>    assigned.
>    ...
>    As of 2023, 1 out of these 256 values has been
>    assigned.
>    ...
>    As of 2023, 4 out of these 256
>    values have been assigned.
>    ...
>    As of 2023, 1 out of these 256 values has been
>    assigned.
> -->

Yes, I've checked and these can all be updated to 2024.

> 7) <!--[rfced] We see that "universal/local" and "Local/Global" are
> both used to describe the X bit. Should this be made consistent?
> Original:
>    X bit  - This bit is also called the "universal/local" bit
>    ...
>    When so used, the EUI-64 is modified by
>    inverting the X (Local/Global) bit to form an IETF "Modified EUI-64
>    identifier".
> -->

I believe IEEE favors the universal/local nomenclature so I guess we
should go with that. However, at the first instance or the like,
please add a parenthetical "(formerly called Local/Global)"

> 8) <!--[rfced] As the plus sign could indicate addition, may we replace it
> with "and"?
>
> Original:
>    Y+Z bits  - These two bits have no special meaning if the X bit is
>       zero.
>
> Perhaps:
>    Y and Z bits -  These two bits have no special meaning if the X bit is
>       zero.
> -->

To avoid verbosity, how about "Y&Z"?

> 9) <!--[rfced] Since two instances of "NOTE" are listed directly
> after this definition, should "see NOTE below" be more specific?
>
> Original:
>    Standard Assigned -  MAC addresses in this quadrant are called
>       Standard Assigned Identifiers (SAIs).  An SAI is assigned by a
>       protocol specified in an IEEE 802 standard, for example
>       [IEEE802.1CQ] (but see NOTE below).
>
>          NOTE: While the SLAP has MAC addresses assigned through a local
>          protocol in the SAI quadrant and assigned by a protocol
>          specified in an IEEE 802 standard, the SLAP is optional.  Local
>          network administrators may use the IETF protocol provisions in
>          [RFC8947] and [RFC8948] which support assignment of a MAC
>          address in the local MAC address space using DHCPv6 [RFC8415]
>          or other protocol methods.
>
>       NOTE: There isn't any automated way to determine if or to what
>       extent a local network is configured for and/or operating
>       according to SLAP.
> -->

Yes, it would probably be good to change the referring text to "see
first NOTE below" and to decrease the indentation of the 2nd note,
which is actually related to much of the entire section. See item 5
above.

> 10) <!--[rfced] Regarding Section 2.2.2:
>
> a) Would it be acceptable to replace this list with a table that
> exactly matches the IANA registry
> (as shown in Table 3 of https://www.rfc-editor.org/authors/rfc9542-table.txt)?
> The rationale is so that the addresses and usage match the registry
> and because it is referred to as "[t]he following table".

Replacing with the IANA table has the primary advantage of including
the references clearly so I guess it is OK.

> b) "EF" has been changed to "FC" to match the IANA registry as follows.
> Please let us know if this is not correct.
>
> Original:
>    02-00-5E-10-00-00-01-00 to 02-00-5E-EF-FF-FF-FF-FF  available for
>       assignment
>
> Current:
>    02-00-5E-10-00-00-01-00 to 02-00-5E-FC-FF-FF-FF-FF  available for
>       assignment

I believe the IANA registry (for which I am the primary expert) is
wrong. This has consistently been "EF" in the RFCs back through RFC
7042 and RFC 5342. Looks like an error on my part in reviewing the
IANA registry 16 years ago back in 2008. This correction to the IANA
registry clearly does not affect any existing assignments or the like
so it should be straight forward. Should I send a separate message to
IANA?

> c) If you choose the table, we note the "02-00-5E" is not included, so
> would you like to add text to the preceding paragraph in order to note that?
> Perhaps:
>
>   These values are prefixed with 02-00-5E to form unicast
>   modified EUI-64 addresses.
> -->

Yes, if we convert to a table such a note is essential.

> 11) <!--[rfced] To clarify "8 bits length", may we update this
> sentence as follows?
>
> Original:
>    Should some other multiple of 8 bits length MAC
>    addresses be used in the future, such as a 128-bit (16 octet) MAC
>    address, the TBD1 tag will be used.
>
> Perhaps:
>    Should some other multiple of 8 bits be used in the future
>    for the length of MAC addresses, such as a 128-bit (16-octet) MAC
>    address, the 48 tag will be used.
> -->

That looks fine.

> 12) <!--[rfced] As the protocol identifier uses "AA-AA", should the
> text be updated to reflect this?
>
> Original:
>       xx-xx-AA-AA-03-yy-yy-yy-zz-zz
>
>    where xx-xx is the frame length and, as above, must be small enough
>    not to be confused with an EtherType; "AA" is the LSAP that indicates
>    this use and is sometimes referred to as the SNAP Service Access
>    Point (SNAP SAP);
>
> Perhaps:
>       xx-xx-AA-AA-03-yy-yy-yy-zz-zz
>
>    where xx-xx is the frame length and, as above, must be small enough
>    not to be confused with an EtherType; "AA-AA" is the LSAP that indicates
>    this use and is sometimes referred to as the SNAP Service Access
>    Point (SNAP SAP);
> -->

Well, that's actually an interesting question. The "AA-AA" is actually
two protocol points, since it is "AA" appearing in both the DSAP and
SSAP positions. So the current text is not wrong. On the other hand, a
single AA code point is never, as far as I know, paired with a
different SSAP or DSAP code point. While this could go either way, I
would prefer to leave the current wording.

> 13) <!--[rfced] Should instances of "LLC control" be updated to read
> simply "LLC" to avoid redundancy (if expanded, "LLC protocol" would
> read as "Logical Link Control control"). Please review and let us
> know if any updates are needed.
>
> Original:
>    ..."03" is the LLC control octet indicating datagram
>    service; yy-yy-yy is an OUI; and zz-zz is a protocol number, under
>    that OUI, assigned by the OUI owner.  The five-octet length for such
>    OUI-based protocol identifiers results, with the LLC control octet
>    ("0x03"), in the preservation of 16-bit alignment.
> -->

I think the wording needs to stay as is. "LLC" refers to the entire
header pattern of which the "control byte", value 03, is only part.

> 14) <!--[rfced] May we clarify "it" in the list item to be "the
> assignment"?
>
> Original:
>    New assignments of protocol numbers
>    (qq-qq) under the IANA OUI must meet the following requirements:
>    ...
>    *  it must be documented in an Internet-Draft or RFC, and
> -->

"it" => "the protocol"

> 15) <!--[rfced] We are having some difficulty parsing this sentence.
> How should it be updated for clarity?
>
> Original:
>    (Either that EtherType can be used directly or,
>    in the LSAPs case, using the SNAP SAP and putting an all-zeros
>    "OUI" before the EtherType as described above.)
>
> Perhaps (where each hyphen would be two hyphens):
>
>    (That EtherType can be used directly, or
>    - in the LSAPs case - it can be used with the SNAP SAP by putting
>    an all-zero "OUI" before the EtherType as described above.)
> -->

Your re-wording is fine.

> 16) <!--[rfced] Does "is felt to be large enough" mean "is considered to
> be large enough" or "is believed to be large enough"? Would it be more
> clear as one of those?
>
> Original:
>    While finite, the universe of MAC code points from which Expert-
>    judged assignments will be made is felt to be large enough that the
>    requirements given in this document and the Experts' good judgment
>    are sufficient guidance.
> -->

"considered" is better.

> 17) <!--[rfced] This document and the IANA registry do not match for
> the following description ("24-bit OUI" vs. "OUI"). Which one is correct?
>
> This document:
>    | 24-bit OUI | 16391   |
>
> vs. IANA registry (https://www.iana.org/assignments/address-family-numbers)::
> 16391   OUI
>
> -->

An OUI is always 24-bits long, just drop the "24-bit" here from the
document to make it consistent with the IANA registry.

> 18) <!--[rfced] Section 5.7: Regarding the actual notes on the IANA registries,
> "IANA Unicast 48-bit MAC Addresses" mentions Section 2.1.5 and
> "IANA Multicast 48-bit MAC Addresses" mentions Section 2.1.4.
>
> For the latter, is 2.1.4 correct?
> This document indicates "Section 2.1.5" for both:
>
>    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
>    |  9542.
> -->

Ahhh, looking at the purpose of this reference, I believe that both
the "IANA Unicast 48-bit MAC Addresses" registry and the "IANA
Multicast 48-bit MAC Addresses" registry notes should reference 2.1.3,
not 2.1.5. So it is correct that they both reference the same section,
it is just that they reference the wrong section right now. 2.1.3 is
the 48-bit section parallel with what 2.2.2 is for 64-bit.

> 19) <!-- [rfced] Would you like the references to be alphabetized
> or left in their current order?
> -->

Please alphabetize.

> 20) <!--[rfced] As this document informatively references RFC 5798,
> would you like to delay publishing in order to be published at the
> same time as draft-ietf-rtgwg-vrrp-rfc5798bis-18, which is also
> currently in the RFC Editor queue? -->

I don't think the reason for this reference will change in any way so
there is no reason to hold up publication of rfc7042bis.

> 21) <!--[rfced] We note that the following term is used inconsistently
> throughout the document. Please review and let us know how it may be
> made consistent.
>
> 'CF Series' vs. CF Series vs. "CF" series
> -->

I think the single/double quotes here can just be removed except where
there is the literal quote of text taken from RFC 2153 which should be
faithful to the punctuation in RFC 2153.

> 22) <!-- [rfced] FYI, we have added expansions for the following abbreviations
> per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
> expansion in the document carefully to ensure correctness.
>
> Network Layer Protocol Identifier (NLPID)
> -->

OK.

> 23) <!-- [rfced] Please review the "Inclusive Language" portion of the online
> Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
> and let us know if any changes are needed.
>
> For example, please consider whether "sanity" should be updated.  --> </back>

You may replace "sanity" with "reasonableness".


CHANGES FROM REVIEW OF DOCUMENT:


Section 2.3.2: This is a pretty minor persnickety comment but in the
.txt version I don't like where the line break falls in the indented
text about CF-00-00. In particular, in the .txt version, it can be
mistaken for two separate lines of independent text, both
ungrammatical. To avoid this problem for some readers, I suggest
rewording this with no change in meaning as

"CF-00-00 is reserved. CF-00-00-00-00-00 is a multicast identifier
listed by IANA as used for Ethernet loopback tests."

This should move the line break to after CF-00-00-00-00-00 instead of
just before CF-00-00-00-00-00 eliminating this minor problem. (There
is no problem in the .html and .pdf versions.)


Effective April 2nd, I am no longer sponsored by Futurewei
Technologies. My affiliation need to be changed on the first page and
in the Author Addresses section.
OLD
Futurewei Technologies
NEW
Independent


Acknowledgements
"people persons" -> "persons"


Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   [phone] (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 [e-mail]


> Thank you.
>
> RFC Editor/ap/ar
>
>
> On Apr 4, 2024, [e-mail] wrote:
>
> *****IMPORTANT*****
>
> Updated 2024/04/04
>
> RFC Author(s):
> --------------
>
> Instructions for Completing AUTH48
>
> Your document has now entered AUTH48.  Once it has been reviewed and
> approved by you and all coauthors, it will be published as an RFC.
> If an author is no longer available, there are several remedies
> available as listed in the FAQ (https://www.rfc-editor.org/faq/).
>
> You and you coauthors are responsible for engaging other parties
> (e.g., Contributors or Working Group) as necessary before providing
> your approval.
>
> Planning your review
> ---------------------
>
> Please review the following aspects of your document:
>
> *  RFC Editor questions
>
>   Please review and resolve any questions raised by the RFC Editor
>   that have been included in the XML file as comments marked as
>   follows:
>
>   <!-- [rfced] ... -->
>
>   These questions will also be sent in a subsequent email.
>
> *  Changes submitted by coauthors
>
>   Please ensure that you review any changes submitted by your
>   coauthors.  We assume that if you do not speak up that you
>   agree to changes submitted by your coauthors.
>
> *  Content
>
>   Please review the full content of the document, as this cannot
>   change once the RFC is published.  Please pay particular attention to:
>   - IANA considerations updates (if applicable)
>   - contact information
>   - references
>
> *  Copyright notices and legends
>
>   Please review the copyright notice and legends as defined in
>   RFC 5378 and the Trust Legal Provisions
>   (TLP – https://trustee.ietf.org/license-info/).
>
> *  Semantic markup
>
>   Please review the markup in the XML file to ensure that elements of
>   content are correctly tagged.  For example, ensure that <sourcecode>
>   and <artwork> are set correctly.  See details at
>   <https://authors.ietf.org/rfcxml-vocabulary>.
>
> *  Formatted output
>
>   Please review the PDF, HTML, and TXT files to ensure that the
>   formatted output, as generated from the markup in the XML file, is
>   reasonable.  Please note that the TXT will have formatting
>   limitations compared to the PDF and HTML.
>
>
> Submitting changes
> ------------------
>
> To submit changes, please reply to this email using ‘REPLY ALL’ as all
> the parties CCed on this message need to see your changes. The parties
> include:
>
>   *  your coauthors
>
>   *  [e-mail] (the RPC team)
>
>   *  other document participants, depending on the stream (e.g.,
>      IETF Stream participants are your working group chairs, the
>      responsible ADs, and the document shepherd).
>
>   *  [e-mail], which is a new archival mailing list
>      to preserve AUTH48 conversations; it is not an active discussion
>      list:
>
>     *  More info:
>        https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
>
>     *  The archive itself:
>        https://mailarchive.ietf.org/arch/browse/auth48archive/
>
>     *  Note: If only absolutely necessary, you may temporarily opt out
>        of the archiving of messages (e.g., to discuss a sensitive matter).
>        If needed, please add a note at the top of the message that you
>        have dropped the address. When the discussion is concluded,
>        [e-mail] will be re-added to the CC list and
>        its addition will be noted at the top of the message.
>
> You may submit your changes in one of two ways:
>
> An update to the provided XML file
> — OR —
> An explicit list of changes in this format
>
> Section # (or indicate Global)
>
> OLD:
> old text
>
> NEW:
> new text
>
> You do not need to reply with both an updated XML file and an explicit
> list of changes, as either form is sufficient.
>
> We will ask a stream manager to review and approve any changes that seem
> beyond editorial in nature, e.g., addition of new text, deletion of text,
> and technical changes.  Information about stream managers can be found in
> the FAQ.  Editorial changes do not require approval from a stream manager.
>
>
> Approving for publication
> --------------------------
>
> To approve your RFC for publication, please reply to this email stating
> that you approve this RFC for publication.  Please use ‘REPLY ALL’,
> as all the parties CCed on this message need to see your approval.
>
>
> Files
> -----
>
> The files are available here:
>   https://www.rfc-editor.org/authors/rfc9542.xml
>   https://www.rfc-editor.org/authors/rfc9542.html
>   https://www.rfc-editor.org/authors/rfc9542.pdf
>   https://www.rfc-editor.org/authors/rfc9542.txt
>
> Diff file of the text:
>   https://www.rfc-editor.org/authors/rfc9542-diff.html
>   https://www.rfc-editor.org/authors/rfc9542-rfcdiff.html (side by side)
>
> Diff of the XML:
>   https://www.rfc-editor.org/authors/rfc9542-xmldiff1.html
>
>
> Tracking progress
> -----------------
>
> The details of the AUTH48 status of your document are here:
>   https://www.rfc-editor.org/auth48/rfc9542
>
> Please let us know if you have any questions.
>
> Thank you for your cooperation,
>
> RFC Editor
>
> --------------------------------------
> RFC9542 (draft-ietf-intarea-rfc7042bis-11)
>
> Title            : IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters
> Author(s)        : D. Eastlake, J. Abley, Y. Li
> WG Chair(s)      : Juan-Carlos Zúñiga, Wassim Haddad
>
> Area Director(s) : Erik Kline, Éric Vyncke