Subject: [Tsv-art] Tsvart last call review of draft-ietf-pce-pcep-flowspec-09

From: Joseph Touch via Datatracker <[email-masked]>
Date: Fri, 03 Jul 2020 19:20:51 -0700

Reviewer: Joseph Touch
Review result: Ready with Nits

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
[email-masked] if you reply to or forward this review.

Overall, the document has no direct transport issues.

There are potential issues in coupled documents, notably in
draft-ietf-idr-rfc5575bis. Section 4.2.2.4 of that other document indicates
three issues of concern: 1) inability to handle transport protocols other than
TCP and UDP (e.g., SCTP or DCCP), 2) inability to handle any but initial
fragments, and 3) the omission of addressing MTU issues in the associated
tunnels. Presumably those will be addressed when that document is reviewed more
thoroughly.

Nits:

I would encourage a revision of the abstract to focus on this document and its
contributions, particularly as a single paragraph. The abstract of this
document buries the lede; the final sentence would be usefully moved to the
front and supporting material explaining context can be moved into the intro or
a background section. The abstract could more usefully provide a summary of the
actual contents of this document instead, e.g., from paragraph 7 of the
introduction.

The introduction has similar issues; the document itself is not discussed until
the 6th paragraph. Again, it would be useful to focus on this document and
address the relation of its contents to other documents and the overall PCE
architecture in a background section separately.

It also seems odd that this paragraph (#6 of the intro) undermines the
terminology of the document that this supplements (as cited in the abstract).
These documents as a pair should have consistent use of terminology, coining
new terms as needed rather than redefining a key term as different in the two.