Re: Advancing S-BFD

Jeffrey Haas <jhaas@pfrc.org> Tue, 22 March 2016 02:35 UTC

Return-Path: <jhaas@slice.pfrc.org>
X-Original-To: rtg-bfd@ietfa.amsl.com
Delivered-To: rtg-bfd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80B3612D63A for <rtg-bfd@ietfa.amsl.com>; Mon, 21 Mar 2016 19:35:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.417
X-Spam-Level:
X-Spam-Status: No, score=-0.417 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FAKE_REPLY_C=1.486, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 aZ6hPzNuyJcH for <rtg-bfd@ietfa.amsl.com>; Mon, 21 Mar 2016 19:35:05 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 3ADB012D11F for <rtg-bfd@ietf.org>; Mon, 21 Mar 2016 19:35:05 -0700 (PDT)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 3598F1E837; Mon, 21 Mar 2016 22:38:51 -0400 (EDT)
Date: Mon, 21 Mar 2016 22:38:51 -0400
From: Jeffrey Haas <jhaas@pfrc.org>
To: "Alvaro Retana (aretana)" <aretana@cisco.com>, "Carlos Pignataro (cpignata)" <cpignata@cisco.com>
Subject: Re: Advancing S-BFD
Message-ID: <20160322023850.GI1389@pfrc.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <52E423A1-74DB-4A3F-B7E9-2C1130EF9AA3@cisco.com> <D311D5D5.118AEB%aretana@cisco.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtg-bfd/zVqZqol-4aX34zqe9FuY9ivpD1c>
Cc: "<rtg-bfd@ietf.org>" <rtg-bfd@ietf.org>
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-bfd/>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 22 Mar 2016 02:35:06 -0000

On Fri, Mar 18, 2016 at 08:31:08PM +0000, Alvaro Retana (aretana) wrote:
> I had asked the WG to consider not publishing
> draft-ietf-bfd-seamless-use-case [A], but after a lengthy exchange with
> the authors and a discussion at IETF 94, the WG decided to "give another
> chance to the authors" [B].
> 
> Last week I met with one of the authors of
> draft-ietf-bfd-seamless-use-case; he assured me that he will be working on
> the document in short order.  As you mentioned above, there is little
> value in publishing the use cases *after* the solution.
> 
> The way forward is simple: I'll wait for draft-ietf-bfd-seamless-use-case
> before progressing all 3 base documents together.  If the WG changes its
> mind (about publishing draft-ietf-bfd-seamless-use-case) then we will have
> other options.  

I have just reviewed the updated -04 for the use case document.

It's my belief that the issues you had raised are covered in this update.

There are a number of small grammatical and typo issues in the document, but
none that should impact clarity upon the editing process.  I would propose
that we leave the cleanup of these to the RFC Editor who will do a much
better job of it than the WG will in fewer passes. :-)

I believe this document is ready to advance with the bundle.

On Fri, Mar 18, 2016 at 11:25:34PM +0000, Carlos Pignataro (cpignata) wrote:
> That does not sounds terribly convincing. Don’t get me wrong — I
> personally have no strong opinion about what to do with use-case; in fact,
> I find it terribly disappointing and even demoralizing that folks invest
> their volunteer time to get to Finish_Line_minus_5_minutes and be told
> ‘the race got cancelled’. I believe those decisions are taken early and
> then we stick with the decision, and IETF WGs and chairs will be much
> better served with an actual IESG statement about this. However, I do have
> an opinion about not artificially slowing down protocol work, and I
> believe that protocol (i.e., the 5 S-BFD documents on base, ip, ospf,
> isis, l2tpext, and pals) work is the high-order bit in this set.

The fact that the sense of IETF has been shifting away from publishing use
case documents is something that caught the contributors to the draft in
mid-stream.  It's for that reason the chairs and the Alvaro have been
patient about advancing the bundle.

(It doesn't hurt that we also hit a common IETF pattern that the required
edits for the other documents didn't happen until near the cut-off. :-)

While I think we'll be using this effort as an example of how *not* to
motivate use case authors, let's push this to the finish line.

-- Jeff