Re: IDR WG charter

[Yakov Rekhter <[e-mail]>]

Eric,

> Yakov,
> 
> 	I would like to understand whether those who
> rejected the new proposal did so because they felt
> the current charter is better, or because they are
> convinced that a better charter could be produced.
> 
> 	At a minimum, the current charter needs to 
> be updated.  If people are unhappy with proposals
> from the AD, then they should be explicit about
> their reasoning.  Ideally, those rejecting the
> proposal would make either specific suggestions
> as to changes or propose an alternative.
> 
> 	As it is currently left, we are making no
> progress...

We certainly have "rough consensus" to accept the new charter,
and that is exactly what the WG is going to do.

The only thing we need to do with the new charter is to add
few items that have been missing, like Cease subcodes, Graceful
restart, Dynamic Capability (they've been missing both in the
current charter and in the new proposed charter), and settle
on the dates. I'll post the updated new charter within few
days.

Yakov.

> 
> Eric W. Gray
> Systems Architect
> Celox Networks, Inc.
> [e-mail]
> 508 305 7214
> 
> 
> > -----Original Message-----
> > From: Yakov Rekhter [mailto:[e-mail]]
> > Sent: Wednesday, September 18, 2002 10:53 AM
> > To: [e-mail]
> > Subject: IDR WG charter
> > 
> > Folks,
> > 
> > In response to the attached I got 7 "accept" and 4 "reject".
> > 
> > Yakov.
> > ------- Forwarded Message
> > 
> > Date:    Tue, 03 Sep 2002 09:43:42 -0700
> > From:    Yakov Rekhter <[e-mail]>
> > To:      [e-mail]
> > cc:      [e-mail], [e-mail]
> > Subject: IDR WG charter
> 
> > Folks,
> > 
> > So far we received just two e-mail on the subject of the IDR WG
> > charter proposed by Bill and Alex. The WG chairs would like to get
> > opinion of the WG members on whether the WG should accept the new
> > charter, or stay with the existing one.  With this in mind, please
> > send me an e-mail with either "accept" (means accept the new
> > charter), or "reject" (means stay with the existing charter). The
> > deadline is Sep 17.
> > 
> > Sue & Yakov.
> > - ------- Forwarded Message
> > 
> > Date:    Mon, 26 Aug 2002 07:18:00 -0700
> > From:    Yakov Rekhter <[e-mail]>
> > To:      [e-mail]
> > cc:      [e-mail]
> > Subject: IDR WG charter
> > 
> > Folks,
> > 
> > Please comment on the revised charter proposed by Bill and Alex
> > (see below). The deadline for comments is Sep 10, 2002.
> > 
> > Sue & Yakov
> > - - ------- Forwarded Message
> > 
> > Date:    Thu, 22 Aug 2002 16:11:10 -0700
> > From:    Bill Fenner <[e-mail]>
> > To:      [e-mail]
> > Subject: BGP spec and IDR WG charter
> > 
> > Dear IDR WG,
> > 
> >   After some consideration, the Routing Area Directors have decided
> > not to forward any IDR documents for IESG consideration until the
> > base BGP spec update is finished.[*]  Despite the best efforts of all
> > involved, the spec update has been taking an incredible amount of
> > time.  We take this step in order to focus all possible resources
> > of the WG community on the BGP spec update.
> > 
> >   This may seem like a negative action.  On the contrary, it is
> > meant to support the accomplishment of the working group's goals.[**]
> > The milestone for the submission of the BGP4 draft to the IESG
> > was scheduled for January 2002.
> > 
> >   Attached is a proposed update for the IDR working group charter.
> > Note that we just made up the dates in the goals and milestones,
> > and the WG should come up with realistic ones.
> > 
> >   Bill and Alex
> > 
> > [*] "finished" means, in this case, WG consensus, WG Last Call,
> > AD Review, IETF Last Call, and IESG approval for publication.
> > 
> > [**] In further support of the goal of having a quality specification
> > that reflects current reality, the ADs have been working on assembling
> > a team of reviewers that consists primarily of protocol implementors,
> > who have committed their time to examine the spec.  We will be
> > sending another message to this list explaining the details of how
> > this team will do its work.
> > 
> > - - - - - -
> > 
> > The Inter-Domain Routing Working Group is chartered to standardize
> > and promote the Border Gateway Protocol Version 4 (BGP-4) [RFC
> > 1771] capable of supporting policy based routing for TCP/IP internets.
> > The objective is to promote the use of BGP-4 to support IP version
> > 4 and IP version 6. The working group will continue to work on
> > improving the scalability of BGP.
> > 
> > The current tasks of the WG are limited to:
> > 
> > - - - - Revise and clarify the base BGP4 document (RFC 1771). Note that
> > RFC 1771 no longer documents existing practice and one goal of the
> > update is document existing practice. Determine whether the document
> > can be advanced as full Standard or needs to recycle at Proposed
> > or Draft Standard.
> > 
> > - - - - Submit updated MIBs to accompany the revised base BGP4 document.
> > 
> > Once these tasks are completed, work will progress on the following:
> > 
> > - - - - Review and Evaluate Existing RFCs on AS Confederations and Route
> > Reflection. If changes are needed, create and advance revisions.
> > 
> > - - - - Review RFC 2385 (Protection of BGP via TCP MD5 signature) to see
> > if any changes need to be made based on current Internet practice
> > or based on the changes to the current bgp draft. If changes are
> > needed, create an revision. Issue the WG Last Call on advancing
> > the document to Draft Standard.
> > 
> > - - - - Produce an updated MIB for AS Confederations, Route Reflection,
> > Communities, Multi-Protocol BGP, etc..
> > 
> > - - - - Review and evaluate Multiprotocol BGP (RFC 2858) for advancement
> > as Draft Standard.
> > 
> > - - - - Complete work on an Extended Community Attribute. Develop MIB
> > for BGP Extended Communities.
> > 
> > - - - - Extend BGP to support a 4-byte AS number, develop plan for
> > transitioning to usage of 4-byte AS numbers
> > 
> > - - - - Progress along the IETF standards track a BGP-based mechanism
> > that allows a BGP speaker to send to its BGP peer a set of route
> > filters that the peer would use to constrain/filter its outbound
> > routing updates to the speaker. Currently defined in
> > draft-ietf-idr-route-filter-03.txt.
> > 
> > - - - - Progress along standards track an Outbound Router Filter (ORF)
> > type for BGP, that can be used to perform aspath based route
> > filtering. The ORF-type will support aspath based route filtering
> > as well as regular expression based matching for address groups.
> > Currently defined in draft-ietf-idr-aspath-orf-00.txt.
> > 
> > Tasks for this working group are limited to those listed above;
> > new items to be added to the charter must be approved by the IESG.
> > 
> > Goals and Milestones
> > 
> > DONE    Submit BGP Capability Advertisement to the IESG
> > NOV 02  Submit BGP4 document to IESG.
> > DEC 02  Submit updated base BGP4 MIB to IESG.
> > MAR 03  Submit extensible BGP MIB to IESG.
> > MAR 03  Submit Extended Communities draft to IESG.
> > MAR 03  Submit 4-byte AS ID to IESG.
> > MAR 03  Initial Draft for RFC2858 (if needed)
> > MAR 03  BGP TCP MD5 signatures document to IESG.
> > MAR 03  Outbound Route Filter, Prefix and ASpath ORF draft to IESG.
> > 
> > - - ------- End of Forwarded Message
> > 
> > 
> > - ------- End of Forwarded Message
> > 
> > 
> > ------- End of Forwarded Message