[OSPF] Opsdir telechat review of draft-ietf-ospf-link-overload-13

Tim Chown <tim.chown@jisc.ac.uk> Mon, 22 January 2018 14:55 UTC

Return-Path: <tim.chown@jisc.ac.uk>
X-Original-To: ospf@ietf.org
Delivered-To: ospf@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DF277124207; Mon, 22 Jan 2018 06:55:04 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Tim Chown <tim.chown@jisc.ac.uk>
To: ops-dir@ietf.org
Cc: ospf@ietf.org, draft-ietf-ospf-link-overload.all@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.69.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151663290487.7984.12317518080423140763@ietfa.amsl.com>
Date: Mon, 22 Jan 2018 06:55:04 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/ospf/piUqYanqSEmvswhk8_i5JqodkdY>
Subject: [OSPF] Opsdir telechat review of draft-ietf-ospf-link-overload-13
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.22
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ospf>, <mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ospf/>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Jan 2018 14:55:05 -0000

Reviewer: Tim Chown
Review result: Ready

Hi,

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.

This document defines mechanism(s) to allow OSPF routers to indicate that a
specific link, rather than a whole node, is entering an imminent maintenance
state, to allow other devices that understand the protocol extension(s) to more
gracefully re-route traffic around the affected link.

I believe the document is Ready for publication.  I have only three minor
comments below, which the authors may choose to act on.

Overall the document reads reasonably well. Not being overly familiar with the
material, I needed to read it through end-to-end more than once to better
understand its scope and intent. My first comment would be that perhaps the
introduction section could be better written; the abstract seemed clear on the
purpose of the draft, while the introduction felt a little muddled.  Sections
2, 3 and 4, which detail the motivations and extensions, were much clearer.

Secondly, there are some minor typographic errors throughout the document,
generally missing (in)definite articles.  While the RFC Editor would pick these
up, it would be nice for the authors to have a final pass and fix those before
submission.

Thirdly, the document does not give any advice on the timing of using the
extensions - how far in advance is it recommended to use the extensions? - or
on the return to 'normal' state once the maintenance is completed.  So perhaps
consider adding a short section on this, maybe in Section 5.

Best wishes,
Tim