[mpls] Review of draft-ietf-mpls-tp-temporal-hitless-psm-12

Jon Mitchell <jrmitche@puck.nether.net> Wed, 08 March 2017 05:51 UTC

Return-Path: <jrmitche@puck.nether.net>
X-Original-To: mpls@ietf.org
Delivered-To: mpls@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 26B291293FD; Tue, 7 Mar 2017 21:51:06 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Jon Mitchell <jrmitche@puck.nether.net>
To: <ops-dir@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.47.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <148895226612.17662.7706011588102984090@ietfa.amsl.com>
Date: Tue, 07 Mar 2017 21:51:06 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/_mSlPiqn-bWtmAvr2rKCVCdwf2k>
Cc: mpls@ietf.org, draft-ietf-mpls-tp-temporal-hitless-psm.all@ietf.org, ietf@ietf.org
Subject: [mpls] Review of draft-ietf-mpls-tp-temporal-hitless-psm-12
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.17
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Mar 2017 05:51:06 -0000

Reviewer: Jon Mitchell
Review result: Has Nits

I have reviewed this document as part of the Operational directorate's

ongoing effort to review all IETF documents being processed by the
IESG.  These 
comments were written with the intent of improving the operational
aspects of the 
IETF drafts. Comments that are not addressed in last call may be
included in AD reviews 
during the IESG review.  Document editors and WG chairs should treat
these comments 
just like any other last call comments. 

Document is Ready with Nits.  I share the concern that it's not
totally clear upfront this is
a requirements versus solution document.  There is also not much in
the way of requirements
of notification or how to signal back to the operator that a fault has
occurred, but this
may be OK if whatever solution would meet the requirements of this
draft will include
such text or rely on existing mechanisms discussed in RFC6371.