Re: AD review of draft-ietf-rtgwg-ipfrr-notvia-addresses

Stewart Bryant <stbryant@cisco.com> Fri, 14 December 2012 16:16 UTC

Return-Path: <stbryant@cisco.com>
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9071A21F88BC for <rtgwg@ietfa.amsl.com>; Fri, 14 Dec 2012 08:16:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.57
X-Spam-Level:
X-Spam-Status: No, score=-110.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QlxbU2YxVudG for <rtgwg@ietfa.amsl.com>; Fri, 14 Dec 2012 08:16:42 -0800 (PST)
Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 6B81D21F88B6 for <rtgwg@ietf.org>; Fri, 14 Dec 2012 08:16:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3776; q=dns/txt; s=iport; t=1355501802; x=1356711402; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=MgQq5wgQpd5UTopGpoQaONywK/M4pA6uOaq5jJJXZvc=; b=JVKw+UmGlB4LqDjZAXbcPHQbs4Zr5SsyMZs8HOk7pVYJTGHF0ACMfv2d j4XXvixxd/B+e/4dmouTDGM1hYnDgPj5bm9T3XGwGuit7xJVM6Uf1JJAg 5E8fnI5nEGtFX14mk9/H3WSQZvPmdvUg0xUgzKc90uiL1vHnkEG+3gpu1 c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AicHAG5Qy1CQ/khL/2dsb2JhbABFg0i7PRZzgh4BAQEEAQEBGhs2CgEQCxgJFg8JAwIBAgEVMBMBBQIBAYgPDLx+jFeEQwOWCZBIgnM
X-IronPort-AV: E=Sophos;i="4.84,282,1355097600"; d="scan'208";a="10450025"
Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-3.cisco.com with ESMTP; 14 Dec 2012 16:16:41 +0000
Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id qBEGGfx8005748 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Dec 2012 16:16:41 GMT
Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id qBEGGciA011750; Fri, 14 Dec 2012 16:16:39 GMT
Message-ID: <50CB50FA.7080701@cisco.com>
Date: Fri, 14 Dec 2012 16:16:58 +0000
From: Stewart Bryant <stbryant@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: adrian@olddog.co.uk
Subject: Re: AD review of draft-ietf-rtgwg-ipfrr-notvia-addresses
References: <05f201cdac19$72ac3260$58049720$@olddog.co.uk>
In-Reply-To: <05f201cdac19$72ac3260$58049720$@olddog.co.uk>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: draft-ietf-rtgwg-ipfrr-notvia-addresses.all@tools.ietf.org, rtgwg@ietf.org
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: stbryant@cisco.com
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: <http://www.ietf.org/mail-archive/web/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: Fri, 14 Dec 2012 16:16:43 -0000

Adrian

How about if we add a new first section that says:

"This document describes a method of providing fast re-route
in an IP or MPLS network based on the use of an IP address
known to avoid the failure. At the time of publication there is no
immediate demand to deploy this technology, however in view
of the subtleties involved in the design of routing protocol
extensions to provide IP Fast Reroute it was considered desirable
to publish this document to place on record the design
consideration of the not-via address approach."

Stewart


On 17/10/2012 04:42, Adrian Farrel wrote:
> Hi,
>
> I've done my usual AD review of your draft prior to issuing IETF last
> call and passing the I-D for IESG evaluation. The main purpose of the
> review is to catch issues that might come up in later reviews and to
> ensure that the document is ready for publication as and RFC.
>
> I only have a small point that needs to be resolved in a new revision of
> the document, so I will put it into "Revised I-D Needed" state in the
> data tracker and wait to hear from you.
>
> But I would also like the document shepherd to make an update to the
> write-up as described below.
>
> As always, all my comments are up for discussion and negotiation.
>
> Thanks for the work,
> Adrian
>
> ===
>
> The Shepherd write-up says...
>
>> There is consensus in the WG to proceed with publication.
> Looking at the mailing list, I see no comments positive or negative
> during WG last call. What is more, I see no discussion of the I-D
> going back four years (at which point I lost the will to search
> further). How do you justify there being WG consensus for this document?
>
> I think this issue can be resolved by a revision to the write-up with
> some explanation of the justification for publishing this as a WG
> document. I would also like the write-up to explain the purpose of the
> document as discussed in the following point.
>
> ---
>
> I was also unclear why you want to publish the document at all. I see a
> note from Alvaro (extending the WG last call for an extra week) that
> says:
>
>> this document is being published as an Informational RFC for
>> completeness purposes...as has been discussed in the mailing list and
>> live meetings.
> So I think that gives me the intended purpose: completeness. But I don't
> know what that means, and the document doesn't help me at all.
>
> Furthermore, I couldn't find the discussion of this intention to publish
> on the mailing list.
>
> Based on some conversations with Stewart, I understand that the idea
> here is to capture the current state of discussions in the WG so that
> they are not lost. But I also assume that the WG has no interest in
> pursuing these ideas further. So it would be reasonable to add a
> significant note to the Abstract and the Introduction about the
> purpose. This would say something along the lines of...
>
>    The idea is to capture the current state of discussions in the WG so
>    that they are not lost, can be referenced, and might be picked up
>    again later. The WG currently has no interest in pursuing these ideas
>    further. It is not intended that this document as currently written
>    should form the basis of an implementation or deployment.
>
> With this in mind, my review is considerably lighter than it would be
> for a standards track protocol specification, and I think the document
> will be fine for advancement.
>
> _______________________________________________
> rtgwg mailing list
> rtgwg@ietf.org
> https://www.ietf.org/mailman/listinfo/rtgwg
> .
>


-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html