Re: [Idr] AD statement on draft-ietf-idr-bgp-issues

"Susan Hares" <shares@ndzh.com> Wed, 17 October 2012 16:44 UTC

Return-Path: <shares@ndzh.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 AC46B21F866D; Wed, 17 Oct 2012 09:44:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.948
X-Spam-Level:
X-Spam-Status: No, score=-1.948 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 nlEh0iM-oA+k; Wed, 17 Oct 2012 09:44:20 -0700 (PDT)
Received: from hickoryhill-consulting.com (hhc-web.hickoryhill-consulting.com [64.9.205.140]) by ietfa.amsl.com (Postfix) with ESMTP id 43B4C21F866E; Wed, 17 Oct 2012 09:44:20 -0700 (PDT)
X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=64.112.195.202;
Received: from SKH2012HPLT (unverified [64.112.195.202]) by hickoryhill-consulting.com (SurgeMail 5.2a) with ESMTP id 9742-1945496 for multiple; Wed, 31 Oct 2012 02:45:14 -0500
From: Susan Hares <shares@ndzh.com>
To: stbryant@cisco.com, idr-chairs@tools.ietf.org, 'idr mailing list' <idr@ietf.org>, draft-ietf-idr-bgp-issues@tools.ietf.org
References: <506C2940.2010507@cisco.com>
In-Reply-To: <506C2940.2010507@cisco.com>
Date: Wed, 17 Oct 2012 12:44:15 -0400
Message-ID: <01d801cdac86$a5819320$f084b960$@ndzh.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_01D9_01CDAC65.1E73C3B0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQKYFlSt+lreVufF6fhRaEgWQSZ6nZYo4E3w
Content-Language: en-us
X-Authenticated-User: skh@ndzh.com
Cc: iesg@ietf.org
Subject: Re: [Idr] AD statement on draft-ietf-idr-bgp-issues
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
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, 17 Oct 2012 16:44:21 -0000

Stewart:

 

We will approach item 4 and 3 and 3a in parallel.  Thank you for the AD
Review. 

 

Sue 

 

From: Stewart Bryant [mailto:stbryant@cisco.com] 
Sent: Wednesday, October 03, 2012 8:02 AM
To: idr-chairs@tools.ietf.org; idr mailing list;
draft-ietf-idr-bgp-issues@tools.ietf.org
Cc: iesg@ietf.org
Subject: AD statement on draft-ietf-idr-bgp-issues

 

 
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