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

<> Thu, 25 June 2015 11:24 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 4F2C61A1B2D; Thu, 25 Jun 2015 04:24:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qyYdaBc4aHPP; Thu, 25 Jun 2015 04:24:05 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 048451A1B18; Thu, 25 Jun 2015 04:24:05 -0700 (PDT)
Received: from (unknown [xx.xx.xx.1]) by (ESMTP service) with ESMTP id 5380326460A; Thu, 25 Jun 2015 13:24:03 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown []) by (ESMTP service) with ESMTP id 23D4335C070; Thu, 25 Jun 2015 13:24:03 +0200 (CEST)
Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILMA2.corporate.adroot.infra.ftgroup ([fe80::bc1c:ad2f:eda3:8c3d%19]) with mapi id 14.03.0235.001; Thu, 25 Jun 2015 13:24:02 +0200
From: <>
To: "Joel jaeggli (" <>, "Alvaro Retana (aretana) (" <>, "Alia Atlas (" <>, Ben Campbell <>, "The IESG" <>, "" <>, "Brian Haberman (" <>
Subject: RE: Joel Jaeggli's No Objection on draft-ietf-rtgwg-lfa-manageability-09: (with COMMENT)
Thread-Topic: Joel Jaeggli's No Objection on draft-ietf-rtgwg-lfa-manageability-09: (with COMMENT)
Thread-Index: AQHQrwXPGFSw1hbaVkyAhQyoNC4JeJ29FJqw
Date: Thu, 25 Jun 2015 11:24:01 +0000
Message-ID: <17359_1435231443_558BE4D3_17359_2540_1_9E32478DFA9976438E7A22F69B08FF9216678FA2@OPEXCLILMA4.corporate.adroot.infra.ftgroup>
References: <>
In-Reply-To: <>
Accept-Language: fr-FR, en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version:, Antispam-Engine:, Antispam-Data: 2015.6.25.95415
Archived-At: <>
Cc: "" <>
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Routing Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 25 Jun 2015 11:24:07 -0000

Hi All,

I just posted v10 based on your comments.

The IETF datatracker status page for this draft is:

There's also a htmlized version available at:

A diff from the previous version is available at:


-----Original Message-----
From: rtgwg [] On Behalf Of Joel Jaeggli
Sent: Thursday, June 25, 2015 07:14
To: The IESG
Subject: Joel Jaeggli's No Objection on draft-ietf-rtgwg-lfa-manageability-09: (with COMMENT)

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
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:


Ron Bonica's Opsdir review.


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

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


   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.


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.

rtgwg mailing list


Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.