Re: [rsvp-dir] RSVP directorate formed

"James M. Polk" <jmpolk@cisco.com> Mon, 10 May 2010 21:47 UTC

Return-Path: <jmpolk@cisco.com>
X-Original-To: rsvp-dir@core3.amsl.com
Delivered-To: rsvp-dir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10EF33A6AA0 for <rsvp-dir@core3.amsl.com>; Mon, 10 May 2010 14:47:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.413
X-Spam-Level:
X-Spam-Status: No, score=-10.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uny3+J+KKsMe for <rsvp-dir@core3.amsl.com>; Mon, 10 May 2010 14:47:51 -0700 (PDT)
Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id A318F3A6A98 for <rsvp-dir@ietf.org>; Mon, 10 May 2010 14:47:50 -0700 (PDT)
Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEALMb6EurR7Hu/2dsb2JhbACeI3GibZlSgmCCNASDQQ
X-IronPort-AV: E=Sophos;i="4.53,202,1272844800"; d="scan'208";a="324775325"
Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 10 May 2010 21:47:39 +0000
Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8713.cisco.com [10.99.80.20]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o4ALld37024674; Mon, 10 May 2010 21:47:39 GMT
Message-Id: <201005102147.o4ALld37024674@sj-core-5.cisco.com>
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Mon, 10 May 2010 16:47:38 -0500
To: "David Harrington" <ietfdbh@comcast.net>, "'Lars Eggert'" <lars.eggert@nokia.com>
From: "James M. Polk" <jmpolk@cisco.com>
In-Reply-To: <0cd701caf081$4a944980$0600a8c0@china.huawei.com>
References: <E119C8DF-64CE-46DD-976B-1C9750720F45@nokia.com> <201005101816.o4AIGdHL021437@sj-core-2.cisco.com> <0cd701caf081$4a944980$0600a8c0@china.huawei.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: gorry@erg.abdn.ac.uk, rsvp-dir@ietf.org
Subject: Re: [rsvp-dir] RSVP directorate formed
X-BeenThere: rsvp-dir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: RSVP directorate <rsvp-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/rsvp-dir>, <mailto:rsvp-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rsvp-dir>
List-Post: <mailto:rsvp-dir@ietf.org>
List-Help: <mailto:rsvp-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rsvp-dir>, <mailto:rsvp-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 May 2010 21:47:52 -0000

David

I have no issues wrt your proposed addition.

Wrt the IntServ not being in the current TSVWG charter, most have 
assumed (incorrectly) that IntServ wouldn't be touched again, and 
that there were only tweaks to RSVP that were needed (if they were 
needed) - mostly because most didn't understand where RSVP ended and 
IntServ started -- therefore no Transport WG has IntServ in its charter.

Lars has said on ocassion that IntServ IDs can get the approval from 
the ADs because of this close relationship with RSVP.

I think that if the RSVP Directorate believes that any ID - which is 
mostly IntServ based - is needed by the community, then TSVWG is the 
most likely place for WG review of that work. At this point, we TSVWG 
chairs should work with the ADs to change the charter text to 
explicitly add IntServ to the charter so that any future IntServ IDs 
don't have to run this gauntlet again (i.e., justifying why in 
TSVWG), and merely have this be a "is this ID worthy of progressing 
or not" discussion.

Make any sense?

James

At 03:42 PM 5/10/2010, David Harrington wrote:
>Hi,
>
>I recommend the first bullet of the rsvp-dir tasks be slightly
>modified:
>OLD:
> >   * Review of all new work related to RSVP and Integrated Services
>that
> >     is proposed for IETF adoption. The purpose of this review is to
> >     advise the ADs and the chairs of the Transport Area Working
>Group
> >     (TSVWG) on whether a particular proposal should be taken on as a
> >     work item.
>NEW:
> >   * Review of all new work related to RSVP and Integrated Services
>that
> >     is proposed for IETF adoption. The purpose of this review is to
> >     advise the ADs and the chairs of the Transport Area Working
>Group
> >     (TSVWG) on whether a particular proposal should be taken on as a
> >     work item, including whether the proposal fits within the
>charter of
>       the TSVWG whose RSVP scope is limited to minor extensions and
>maintenance.
>
>If the rsvp-dir does not find it to be within the scope of TSVWG, then
>the work would
>require a charter deliverable update with AD approval, I assume.
>If Intserv is not within the charter, then Intserv proposals are
>presumably
>going to be found not in scope.
>Then the TSVWG chairs can presumbaly use the normal "this is the
>catch-all WG" logic
>to determine WG consensus and get AD approval for the new work item.
>
>(If there is consensus that this would help the situation, we could
>update the TSVWG
>charter to also include Intserv minor updates and maintenance.)
>
>my $.02
>dbh
>
> > -----Original Message-----
> > From: rsvp-dir-bounces@ietf.org
> > [mailto:rsvp-dir-bounces@ietf.org] On Behalf Of James M. Polk
> > Sent: Monday, May 10, 2010 2:17 PM
> > To: Lars Eggert
> > Cc: gorry@erg.abdn.ac.uk; rsvp-dir@ietf.org
> > Subject: Re: [rsvp-dir] RSVP directorate formed
> >
> > Lars
> >
> > AS a follow-on to the public reply...
> >
> > {I reduced the To: and cc: lists}
> >
> > What do we do about the TSVWG charter saying RSVP is only to do
>minor
> > extensions and maintenance, when at least one individual ID that
> > wants to become a TSV WG item is considered by some to be more than
> > minor (MULTI_TSPEC that creates a new Object)?
> >
> > I know the ADs can approve anything to become a WG item (within
> > reason), including this ID - but one of the things this process
> > highlighted (at least to me) is that IntServ is nowhere in the TSVWG
>
> > charter, and this particular ID is an extension to IntServ.
> >
> > Do we chairs propose new charter text that addresses just this small
>
> > omission, or do we chairs propose more of what this directorate is
> > about (i.e., what they are to help with)?
> >
> > James
> >
> > At 08:01 AM 5/10/2010, Lars Eggert wrote:
> > >Hi,
> > >
> > >following the discussion during the IETF-77 TSVAREA meeting on how
> > >to better review and progress extensions to (non-TE) RSVP and
> > >IntServ, the transport area directors have formed a new RSVP
> > >directorate and given it these tasks:
> > >
> > >   * Review of all new work related to RSVP and Integrated
> > Services that
> > >     is proposed for IETF adoption. The purpose of this review is
>to
> > >     advise the ADs and the chairs of the Transport Area
> > Working Group
> > >     (TSVWG) on whether a particular proposal should be taken on as
>a
> > >     work item. The directorate will continue to guide and
> > review such
> > >     new work in TSVWG until it is ready for publication as an RFC.
> > >
> > >   * Review of selected documents during IETF last call or under
>IESG
> > >     review. The directorate monitors ongoing IETF work and should
> > >     independently decide when a document will benefit from
> > their review,
> > >     assign a reviewer and enter into a follow-on discussion with
>the
> > >     authors. When deemed necessary, the area directors will
> > on occasion
> > >     directly consult the directorate while forming their opinion
>on
> > >     selected documents being under review by the IESG.
> > >
> > >   * Cross-working group review. RSVP documents may have relevance
>to
> > >     several working groups, including TSVWG and MPLS-related
>groups
> > >     such as MPLS WG and CCAMP WG. The directorate will ensure that
> > >     drafts submitted to TSV WG are reviewed in the
> > appropriate MPLS-related
> > >     WGs if necessary, and will bring drafts from the
> > MPLS-related WGs
> > >     to the attention of the TSV WG as appropriate.
> > >
> > >The directorate can be reached at rsv-dir@ietf.org. Additional
> > >information about the directorate is at
> > >http://trac.tools.ietf.org/area/tsv/trac/wiki/RSVP-Directorate.
> > >
> > >Lars
> >
> > _______________________________________________
> > rsvp-dir mailing list
> > rsvp-dir@ietf.org
> > https://www.ietf.org/mailman/listinfo/rsvp-dir
> >