Re: [Tsv-art] Tsvart last call review of draft-ietf-rift-applicability-03 Thu, 21 January 2021 10:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E611E3A0DDA; Thu, 21 Jan 2021 02:04:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.917
X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2JtcHNFeNbdm; Thu, 21 Jan 2021 02:04:28 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A67A73A1871; Thu, 21 Jan 2021 02:04:17 -0800 (PST)
Received: from (unknown []) by Forcepoint Email with ESMTPS id 9B6F84A7E1881DE84B61; Thu, 21 Jan 2021 18:04:15 +0800 (CST)
Received: from ([]) by with SMTP id 10LA4Bus031552; Thu, 21 Jan 2021 18:04:11 +0800 (GMT-8) (envelope-from
Received: from mapi (dgapp01[null]) by mapi (Zmail) with MAPI id mid1; Thu, 21 Jan 2021 18:04:13 +0800 (CST)
Date: Thu, 21 Jan 2021 18:04:13 +0800 (CST)
X-Zmail-TransId: 2af96009519db1232eeb
X-Mailer: Zmail v1.0
Message-ID: <>
In-Reply-To: <>
Mime-Version: 1.0
From: <>
To: <>
Cc: <>, <>, <>, <>
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: 10LA4Bus031552
Archived-At: <>
Subject: Re: [Tsv-art] =?utf-8?q?Tsvart_last_call_review_of_draft-ietf-rift-a?= =?utf-8?q?pplicability-03?=
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Review Team <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 21 Jan 2021 10:04:33 -0000

Dear Tommy,

I updated a new version. I hope it resolved your concerns.

Comments and suggestions are always welcome.

Thank you!

Best Regards,

Yuehua Wei

M: +86 13851460269 E:


日 期 :2021年01月07日 00:48
主 题 :Tsvart last call review of draft-ietf-rift-applicability-03

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