Last Call Review of draft-ietf-rift-applicability-03
review-ietf-rift-applicability-03-tsvart-lc-pauly-2021-01-06-00

This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
tsv-art@ietf.org if you reply to or forward this review.

From a Transport Area perspective, this applicability document didn't raise any
concerns during my review. However, I found the document to be unclear and hard
to approach. Since applicability documents are particularly meant to be
explanatory for a potentially broader audience, I would recommend the document
going through a revision to make it more readable.

As someone not deeply familiar with the topics described in this document, I
found that it could benefit from more explanation of terms, or else references
to RFCs that define the terms used. This applies throughout sections 2 and 3.
For example, there should be at least some references or expansions for Clos,
fat-tree, SPF, PoD, TIEs, TORs, PDU, DC, ZTP, etc. Sometimes terms are
expanded/defined much later than when they are first used.

Editorially, the document needs some revisions to be grammatically clearer and
have a less awkward/colloquial tone. For example, this sentence:

"There are a bunch of more advantages unique to RIFT listed below which could
be understood if you read the details of [RIFT]."

Would read better as:

"RIFT provides many other unique advantages, which are listed below and
detailed further in [RIFT]."

There are many other similar examples that should be cleaned up before
publication.

I also found that the document made statements about how the industry would be
deploying this technology, such as “poised to deliver a majority of computation
and storage services in the future”. Whiale this may certainly be the case,
such statements don’t benefit a technical document, and make it too tied to
this moment in time (and can be harmful if the predictions ever change). Many
of these statements can be simply removed, and the document would be clearer
and more concise.