[Teas] Artart last call review of draft-ietf-teas-rfc3272bis-24

Rich Salz via Datatracker <noreply@ietf.org> Fri, 14 July 2023 00:18 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: teas@ietf.org
Delivered-To: teas@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 44D53C1524DC; Thu, 13 Jul 2023 17:18:02 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Rich Salz via Datatracker <noreply@ietf.org>
To: art@ietf.org
Cc: draft-ietf-teas-rfc3272bis.all@ietf.org, last-call@ietf.org, teas@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 11.5.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <168929388226.24431.4984682028458012674@ietfa.amsl.com>
Reply-To: Rich Salz <rsalz@akamai.com>
Date: Thu, 13 Jul 2023 17:18:02 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/NTcrBV7WwN5Q-NaovXywrsmCr8c>
Subject: [Teas] Artart last call review of draft-ietf-teas-rfc3272bis-24
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.39
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Jul 2023 00:18:02 -0000

Reviewer: Rich Salz
Review result: Ready

Sorry this is a day late.

This document explains what traffic engineering, on the Internet, is.  It is a
primer. It is also a history book, and discusses the lessons learned since the
original 3272, with many references to RFC's most of them published since that
document.

This is a magnum opus.  This document is READY. It seems to adequately cover
application-level things by describing ALTO and related items.

I found section 1.1 a little hard to follow.  I'm not sure why, and I have no
recommendations to make.

Consider adding definitions of "ingress node" and "egress node" to 1.4

Sec 2.1, maybe change the first sentence to add "...includes the following
sub-contexts:"

"the ability of the network administrators to translate policies into network
configurations."  Nice to see the human aspect mentioned.

Sec 2.3, "A network-wide view of the topology is also a must for offline
planning" Presumably not the WHOLE network; maybe add clarification?

Sec 4.1, do you need/want definitions or references for STT and ALB methods?

Sec 5.1.2.3, To a customer, a slice looks like ... "with additional information
about the level of service required between endpoints"  s/required/provided/ ?

Sec 5.1.3.1.1 typo's "Exampls" and "netrock"

Sec 5.1.3.12 space before colon and while you're there, maybe s/;/, or/  And
the "four types" described should be an unnumbered list or some such.

Sec 6, I was surprised to see the definitions of functional/non-functional be
in a different order from the sections that followed. Maybe a sentence at the
end explaining why. "This document first summarizes the non-functional
requirements, and covers the functional requirements in the following
subsections."

In 6.1, is the ordering of attributes arbitrary? Could/should it be made
alphabetical?

In 6.5, typo "conforma"

In 6.6.2, should "1+1" be "1:1" ? Apparently not, since 1+1 is not the same as
1:1  This should be mentioned.

In 6.7, "Networks are often arranged in layers"  Should arranged by
implemented?  What about Ogres (a little Shrek Joke,
https://youtu.be/-FtCTW2rVFM?t=43)

Sec 8, "taken over a lot of" stuck out to me as rather informal.  "Some other
southbound interface"  What's a southbound interface?  "such as a
multi-national" add "enterprise"