[Last-Call] Opsdir last call review of draft-ietf-ccamp-gmpls-otn-b100g-applicability-11

Joe Clarke via Datatracker <noreply@ietf.org> Wed, 28 September 2022 16:28 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: last-call@ietf.org
Delivered-To: last-call@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E4840C15257F; Wed, 28 Sep 2022 09:28:47 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Joe Clarke via Datatracker <noreply@ietf.org>
To: ops-dir@ietf.org
Cc: ccamp@ietf.org, draft-ietf-ccamp-gmpls-otn-b100g-applicability.all@ietf.org, last-call@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 8.17.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <166438252792.49026.16582113448138282229@ietfa.amsl.com>
Reply-To: Joe Clarke <jclarke@cisco.com>
Date: Wed, 28 Sep 2022 09:28:47 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/P45xg4Qmmns7hm0dF_VmBhPCjJE>
Subject: [Last-Call] Opsdir last call review of draft-ietf-ccamp-gmpls-otn-b100g-applicability-11
X-BeenThere: last-call@ietf.org
X-Mailman-Version: 2.1.39
List-Id: IETF Last Calls <last-call.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/last-call>, <mailto:last-call-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/last-call/>
List-Post: <mailto:last-call@ietf.org>
List-Help: <mailto:last-call-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/last-call>, <mailto:last-call-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 28 Sep 2022 16:28:48 -0000

Reviewer: Joe Clarke
Review result: Has Nits

I have been tasked to review this document on behalf of the OPS DIR.  I
wouldn't say I'm an expert in this area, but overall I found the draft easy to
read, and from an operations point of view I appreciate the succinct
applicability summaries, as well as the points to future extensibility work
(though I wonder if those deserve their own section for added clarity).

On the nits side, I notice you compare your Figure 3 with the figure in Section
3 of RFC7138.  However, you omit the notion of labeling the A, B, etc. with
"OTN Switch", which I think would help.  I'm also not sure what "3R" means here
or in Figure 1 (but that is likely my lack of experience here).  Finally, the
two parts of Figure 3 seem to be showing both one-hop and multi-hop OTUCn links
but you do not call that out as is done in RFC7138.