Joel Jaeggli's No Objection on draft-ietf-rtgwg-lfa-manageability-09: (with COMMENT)

"Joel Jaeggli" <joelja@bogus.com> Thu, 25 June 2015 05:14 UTC

Return-Path: <joelja@bogus.com>
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 397761B2F3D; Wed, 24 Jun 2015 22:14:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N_eEt7sxB23s; Wed, 24 Jun 2015 22:14:20 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D66041B2F3A; Wed, 24 Jun 2015 22:14:20 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "Joel Jaeggli" <joelja@bogus.com>
To: "The IESG" <iesg@ietf.org>
Subject: Joel Jaeggli's No Objection on draft-ietf-rtgwg-lfa-manageability-09: (with COMMENT)
X-Test-IDTracker: no
X-IETF-IDTracker: 6.0.4
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150625051420.27171.7350.idtracker@ietfa.amsl.com>
Date: Wed, 24 Jun 2015 22:14:20 -0700
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtgwg/alym3aL1rQrHvCfG_Bf3GIZIDAA>
Cc: rtgwg@ietf.org
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.15
List-Id: Routing Area Working Group <rtgwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtgwg/>
List-Post: <mailto:rtgwg@ietf.org>
List-Help: <mailto:rtgwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Jun 2015 05:14:22 -0000

Joel Jaeggli has entered the following ballot position for
draft-ietf-rtgwg-lfa-manageability-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-rtgwg-lfa-manageability/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Ron Bonica's Opsdir review.

Folks,

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 is on the Standards Track. It provides operational feedback
on LFA, highlights some limitations, and proposes a set of refinements to
address those limitations.  It also proposes required management
specifications.

The document is well-written and nearly ready for publication.

Major Issues
----------------
None

Minor Issues
---------------
- Please run this document through the NIT checker and address the NITS

- I am not sure how the sitting IESG feels about the use of lowercase
"must", "should" and "may". You may want to check this before the IESG
review.


Ron Bonica

---

example that I would cite as good to all caps

6.1
...


   o  Per prefixes: prefix protection SHOULD have a better priority
      compared to interface protection.  This means that if a specific
      prefix must be protected due to a configuration request, LFA must
      be computed and installed for this prefix even if the primary
      outgoing interface is not configured for protection.

LFA MUST

since it's a requirement

in most other cases I see a lower cast must what is being described is
the logic that draws you to a conclusion, and those are ok.