Reviewer: Tommy Pauly Review result: Not Ready 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@xxxxxxxx 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. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
