Re: [rsvp-dir] Our first work items for RSVP Directorate

Bruce Davie <> Fri, 04 June 2010 17:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3473F3A68A0 for <>; Fri, 4 Jun 2010 10:48:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.999
X-Spam-Status: No, score=-7.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ibOTHB4J9B1x for <>; Fri, 4 Jun 2010 10:48:24 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 2CD743A67E5 for <>; Fri, 4 Jun 2010 10:48:24 -0700 (PDT)
Authentication-Results:; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAKfZCEyrR7Hu/2dsb2JhbACeRnGlWpoNhRcE
X-IronPort-AV: E=Sophos;i="4.53,362,1272844800"; d="scan'208";a="139555468"
Received: from ([]) by with ESMTP; 04 Jun 2010 17:48:10 +0000
Received: from [] ([]) by (8.13.8/8.14.3) with ESMTP id o54Hm9Bv020776; Fri, 4 Jun 2010 17:48:10 GMT
Mime-Version: 1.0 (Apple Message framework v1078)
Content-Type: text/plain; charset=us-ascii
From: Bruce Davie <>
In-Reply-To: <>
Date: Fri, 4 Jun 2010 13:48:09 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: Bob Briscoe <>
X-Mailer: Apple Mail (2.1078)
Subject: Re: [rsvp-dir] Our first work items for RSVP Directorate
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: RSVP directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 04 Jun 2010 17:48:25 -0000

 The RSVP directorate will not, of course, decide the fate of these documents. Our job is to review documents and advise the TSV ADs and TSVWG chairs. I'm just trying to jump start that process, so that when the authors show up at TSVWG, (a) the chairs will be able to say whether it's even worth the time of the WG to hear a presentation on the draft (b) there will be at least a couple of people in the audience who have read the drafts.

 For the record, all 3 of the drafts mentioned below were presented at IETF 76. The authors have asked that they be taken on as TSVWG items.


On Jun 4, 2010, at 1:39 PM, Bob Briscoe wrote:

> Bruce,
> Will take a look.
> A process break point.... for a draft to be adopted by a working group, the authors have to present it (possibly a couple of times) then justify to the WG why it is ready to be adopted as a WG item. Shouldn't we raise a similar bar for these drafts, rather than pick up "a few drafts floating around"?
> We have probably all seen these presented (tho I personally haven't been in CCAMP so I will have missed narayanan). But I'd now like to see the authors justify to us why they are ready to be WG items, against the criteria established recently.
> Is this fair?
> Bob
> At 17:41 04/06/2010, Bruce Davie wrote:
>> Folks,
>> There are a few drafts floating around that I think we should take a look at and make a recommendation to the ADs regarding their suitability for the TSVWG. These drafts are:
>> draft-narayanan-tsvwg-rsvp-resource-sharing-02
>> draft-lefaucheur-tsvwg-rsvp-multiple-preemption-02.txt
>> draft-polk-tsvwg-intserv-multiple-tspec-03.txt
>> The first one seems pretty non-controversial. Here are comments from the author:
>> >
>> > draft-narayanan-tsvwg-rsvp-resource-sharing-02 is now a companion draft to draft-berger-ccamp-assoc-info-01, and contains only the RSVP-CAC-specific part of the resource sharing thingy. Given that TSVWG is the place for RSVP CAC extensions, yes, I would think TSVWG is the place for it. It's a very small draft basically defining a new codepoint (Resource Sharing Remote-ID Association) with a small behavioural change (only treat this Association-ID as binding on the Resv, not on the Path), so I don't envision any significant backpressure of the form "this is not a small change to RSVP".
>> I would like to recommend that this be made a TSVWG work item. Any comments or concerns?
>> The lefaucheur and polk drafts should probably be treated as a pair. Both relate to the issue of reserving an appropriate level of resource (e.g. bandwidth) in a single round trip when it is not known in advance how much resource is available. This is quite helpful, for example, in a video conferencing application that has a choice of codecs. The polk draft in particular was (I think) a catalyst for the RSVP discussion in Anaheim because it seemed to be stretching the scope of what has normally been done in TSVWG for RSVP maintenance.
>> Given the scope of the directorate, I would like a couple of folks on the directorate to review those drafts and then we can discuss whether they should become TSVWG work items. Can I have some volunteers?
>> Thanks,
>> Bruce
>> _______________________________________________
>> rsvp-dir mailing list
> ________________________________________________________________
> Bob Briscoe,                                BT Innovate & Design