[Tsv-art] Tsvart last call review of draft-ietf-mpls-rfc6374-sfl-08
Mirja Kühlewind via Datatracker <firstname.lastname@example.org> Mon, 25 January 2021 14:07 UTC
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 324A93A128F; Mon, 25 Jan 2021 06:07:33 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
From: =?utf-8?q?Mirja_K=C3=BChlewind_via_Datatracker?= <email@example.com>
Cc: firstname.lastname@example.org, email@example.com, firstname.lastname@example.org
Reply-To: =?utf-8?q?Mirja_K=C3=BChlewind?= <email@example.com>
Date: Mon, 25 Jan 2021 06:07:33 -0800
Subject: [Tsv-art] Tsvart last call review of draft-ietf-mpls-rfc6374-sfl-08
List-Id: Transport Area Review Team <tsv-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsv-art>, <mailto:firstname.lastname@example.org?subject=unsubscribe>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsv-art>, <mailto:email@example.com?subject=subscribe>
X-List-Received-Date: Mon, 25 Jan 2021 14:07:33 -0000
Reviewer: Mirja Kühlewind Review result: On the Right Track 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 firstname.lastname@example.org if you reply to or forward this review. I have one high level comment from a TSV point of view regarding RFC8321 below, however, unfortunately this document is in some places editorially not easy to follow and there are multiple places in the document where the document appears to not be ready to proceed out of the working group: E.g. section 7 contains the following text: "A number of methods are described. The expectation is that the MPLS WG possibly with the assistance of the IPPM WG will select one or maybe more than one of these methods for standardization." Is the plan still to select one? If not, why are these different formats needed? Also there is this editorial note in Sec 9.1: "Editor's Note we need to review the following in the light of further thoughts on the associated signaling protocol(s). I am fairly confident that we need all the fields other than SFL Batch and SFL Index. The Index is useful in order to map between the label and information associated with the FEC. The batch is part of the lifetime management process." And in this context also the purpose of section 10 is unclear to me: "A future version of the this document will discuss the applicability of the various methods to pro-active and on-demand Measurement." One procedural comment: I had to take a look at draft-ietf-mpls-sfl-framework to look up the concept of SFL which suggests to me that this document should probably be a normative reference. Now regarding RFC8321: The marking scheme shown in section 5 seems to assume a RFC832-like marking. RFC8321 is mentioned (only) in section 8, however, the discussion there is rather unclear to me. To me it seem that RFC8321 marking is assumed and as such this should be stated clearly in the introduction, potentially with a normative reference to RFC8321. Some nits: - Sec 5: "acting as proxy data service packets Section 4" -> ... as described in Section 4...? - Sec 5: "This it is proposed" -> "Thus it is proposed" - Sec 5: "that in the time interval being analyzed, 10 packets always flow." -> Maybe "that 10 packets are used in each flow in the time interval being analyzed" ...? packets always flow.
- [Tsv-art] Tsvart last call review of draft-ietf-m… Mirja Kühlewind via Datatracker
- Re: [Tsv-art] Tsvart last call review of draft-ie… Stewart Bryant