[Idr] AD statement on draft-ietf-idr-bgp-issues
Stewart Bryant <stbryant@cisco.com> Wed, 03 October 2012 12:02 UTC
Return-Path: <stbryant@cisco.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3778A21F867F; Wed, 3 Oct 2012 05:02:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.602
X-Spam-Level:
X-Spam-Status: No, score=-110.602 tagged_above=-999 required=5 tests=[AWL=-0.004, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 gnNT1BHxrDkJ; Wed, 3 Oct 2012 05:02:15 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 2FF7821F86BD; Wed, 3 Oct 2012 05:02:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8422; q=dns/txt; s=iport; t=1349265734; x=1350475334; h=message-id:date:from:reply-to:mime-version:to:cc:subject; bh=jJwartBzELIQh5YbLUSGFh+8WZLOrBcex398it0sl8Q=; b=O+ImDoufpdCY72e+7caIyePqipJ+YzSrj1yIW1wZv0YZbW/HGjOYFJQY KTUBodV+qNRzWf2vrJmVyEBhqml/vhs4W0ZteV9lEGClbe7Slmb4uzOJX ZhPbbhInG9A/ijKINOom0JdtCVZGpFQ8K9ENtD46eS9Uo0z+1MgUVPiTC s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAK8obFCQ/khL/2dsb2JhbABFvnOBCII5AQJjATwWGAMCAQIBSwEMAQcBAR6HY5gjg0oQgU6aUpFdA5VpjkKBBmOCboFi
X-IronPort-AV: E=Sophos; i="4.80,527,1344211200"; d="scan'208,217"; a="144714589"
Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 03 Oct 2012 12:02:12 +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 q93C2BVV019192 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Oct 2012 12:02:12 GMT
Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id q93C289I015649; Wed, 3 Oct 2012 13:02:09 +0100 (BST)
Message-ID: <506C2940.2010507@cisco.com>
Date: Wed, 03 Oct 2012 13:02:08 +0100
From: Stewart Bryant <stbryant@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: "idr-chairs@tools.ietf.org" <idr-chairs@tools.ietf.org>, idr mailing list <idr@ietf.org>, draft-ietf-idr-bgp-issues@tools.ietf.org
Content-Type: multipart/alternative; boundary="------------050204090503030801000700"
Cc: "iesg@ietf.org" <iesg@ietf.org>
Subject: [Idr] AD statement on draft-ietf-idr-bgp-issues
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: stbryant@cisco.com
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/idr>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Oct 2012 12:02:18 -0000
To the IDR WG, IDR WG Chairs and authors of draft-ietf-idr-bgp-issues: I have performed an Area Director review of draft-ietf-idr-bgp-issues (Issues in Revising BGP-4 (RFC1771 to RFC4271)), and it is my conclusion that, as submitted to me for AD review, this draft is not suitable for publication as an RFC in the IETF Series. Whilst I understand and support the goal of documenting the key design decisions that formed the basis of the BGP RFC4271, the method that the authors have chosen to present this information lacks the efficiency of presentation of information that I believe is required in the IETF RFC Series. The draft is a reproduction of detailed email exchanges that took place on the IDR list in the early part of the last decade, together with a running commentary and conclusion on each point. Within this 170 pages of text there is far too much cruft and irrelevant discussion for me to accept this publication request. As an aside I also have serious concerns at the extent of review that this document has received by the IDR WG. The only commenter during WG Last call states "... I did look at it when it first appeared, in 2005, and put it on the shelf for further study, where it has remained ever since." This in itself gives concerns regarding the method that the authors have chosen to present this information to the reader. I therefore think that IDR WG needs to find another way to record this information for posterity in a archival format. The IDR WG could proceed on a number of paths with this work. I suggest six ways forward here, but others may be also acceptable. 1) The IDR WG could heavily edit the draft so that it presents in a more conventional, significantly shorter format, the essential issues that were resolved and baked into RFC4271. I would sponsor the publication of a significantly reduced, well targeted, document. 2) The IDR WG could deconstruct the issues and record them in the IETF issue tracker software. This is a method that other WGs have used to address this problem. I accept that this was not possible when the draft was first written in 2003, and that this approach would be a great deal of work. We would have to verify the degree to which this approach matched the archival requirements of the IDR WG. 3) The IDR WG could make some minor modifications and publish this text on an IETF web page with a permanent URL. 3a) The IDR WG could write a short informational RFC that points to that web page so that whilst the text is not in the RFC series, it can be found from the RFC series of documents. 4) The IDR WG could request that the authors approach the Independent Stream RFC Editor, and ask that this draft be published as a RFC in the Independent Stream. Publication in the independent stream would require a conflict review, but if the consensus of the WG was to use this approach, I foresee no issue in that regard. If this approach is taken, I would suggest that the opinion of the IS Editor is sought, before making significant edits to the text of the draft. 5) The IDR WG Chairs could approach another member of the IESG and ask if they would be prepared to sponsor publication of this draft as an RFC. I would not block publication of the draft if it was sponsored by another Area Director. It is of course up to the IDR WG which path it is chosen to explore, but if I were going to progress this draft as a chair, I would probably start by exploring options (3+3a) and (4) in the list above, since this probably requires the least editing of the existing draft text. I am therefore returning this draft to the IDR working group, and await the decision of the IDR Chairs on how they wish to proceed. Regards Stewart
- [Idr] AD statement on draft-ietf-idr-bgp-issues Stewart Bryant
- Re: [Idr] AD statement on draft-ietf-idr-bgp-issu… Susan Hares