[bess] Genart early review of draft-ietf-bess-rfc7432bis-08

[Stewart Bryant via Datatracker <[e-mail]>]

Reviewer: Stewart Bryant
Review result: Ready with Issues

This is a well written document with a few issues that are editorial in nature.

Firstly id-nits picks up a number of issues that need to be addressed:

== Missing Reference: 'RFC4448' is mentioned on line 1115, but not defined
== The expression 'MAY NOT', while looking like RFC 2119 requirements text,
     is not defined in RFC 2119, and should not be used.  Consider using 'MUST
     NOT' instead (if that is what you mean).

     Found 'MAY NOT' in this paragraph:

     *  If a network (inclusive of all PE and P nodes) uses entropy
     labels per [RFC6790] for ECMP load balancing, then the control word MAY
     NOT be used.
 -- The draft header indicates that this document obsoletes RFC7432, but the
     abstract doesn't seem to mention this, which it should.

  -- The draft header indicates that this document updates RFC8214, but the
     abstract doesn't seem to mention this, which it should.
=======
1.1.  Summary of changes from RFC 7432
I wondered if the authors planned to keep this section or whether it was just
used for development purposes? If it is planned to keep it it might be less
intrusive to the flow of the text if it were made an appendix with a forward
reference.
========
   This means that for a given <EVI, BD>, a given MAC address is only
   reachable only via the PE announcing the associated MAC/IP
SB> too many onlys
========
18.1.  Flow Label
SB> There are many flow labels in different IETF protocols and so it took a few
moments to figure out what was going on here. I gather that this is essentially
a FAT label and given that what follows is a PW structure I wonder why the name
was changed.

SB> In any case I thing that it would be helpful to the user to include a stack
diagram to show how it works rather than requiring the reader to figure it it
out form some mildly dense text.

========

   IANA has allocated the following EVPN Extended Community sub-types in
   [RFC7153], and this document is the only reference for them, in
   addition to [RFC7432].
SB> Given that this RFC obsoletes RFC7432 it seems wrong to call that up in the
IANA section as a reference. Once this document is published RFC7432 cases to
exist as normative text so it cannot be referred to as a definitive reference.

      0x00     MAC Mobility                 [RFC7432]
      0x01     ESI Label                    [RFC7432]
      0x02     ES-Import Route Target       [RFC7432]
SB> Also the registries are already created so the IANA section of this
document should I would have thought be an instruction to change the defining
reference from RFC7432 to this document. SB> Again the following language is
strange relative to an existing registry and my previous comments apply to this
text.
   This document creates a registry called "EVPN Route Types".  New
   registrations will be made through the "RFC Required" procedure
   defined in [RFC8126].  The registry has a maximum value of 255.
   Registrations carried forward from [RFC7432] are as follows:

      0     Reserved                           [RFC7432]
      1     Ethernet Auto-discovery            [RFC7432]
      2     MAC/IP Advertisement               [RFC7432]
      3     Inclusive Multicast Ethernet Tag   [RFC7432]
      4     Ethernet Segment                   [RFC7432]
============
SB> The acknowledgements section is very strange.
Appendix A.  Acknowledgments for This Document (2022)
SB> It is not clear what version this applies to, if you keep it should have an
RFC reference Appendix B.  Contributors for This Document (2021)

   In addition to the authors listed on the front page, the following
   co-authors have also contributed to this document:
SB> No names are in this section. Is it needed?

Appendix C.  Acknowledgments from the First Edition (2015)
SB> Why not do the acknowledgements in narrative text rather than a set of
appendixes?
========
SB> The way that the previous authors acknowledgements are done is also very
confusing making it harder than needed to identify the authors of this text. I
am also not sure that their contact details are still needed as this text
replaces the previous documents and if they are really needed they are on file
in the archived RFCs. SB> Please consider simplifying and possibly using a
narrative text approach.