Issues in Revising BGP-4 (RFC1771 to RFC4271)
draft-ietf-idr-bgp-issues-06

I sent the following message to the IDR list on Wed, 03 Oct 2012 13:02:08 +0100

Please see

http://www.ietf.org/mail-archive/web/idr/current/msg11540.html

A copy of the text of the message is included in this tracker note.

- Stewart

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