From bdavie@cisco.com Fri Jun 4 09:41:38 2010 Return-Path: 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 83B9E3A68A4 for ; Fri, 4 Jun 2010 09:41:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.999 X-Spam-Level: X-Spam-Status: No, score=-7.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 ARKz6Hm9RTBe for ; Fri, 4 Jun 2010 09:41:36 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 5A8633A67A1 for ; Fri, 4 Jun 2010 09:41:36 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoAFAALJCEyrR7Hu/2dsb2JhbACSKYwccaU8mhKFFwQ X-IronPort-AV: E=Sophos;i="4.53,362,1272844800"; d="scan'208";a="207284929" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 04 Jun 2010 16:41:22 +0000 Received: from [10.32.241.76] ([10.32.241.76]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o54GfMpO022076 for ; Fri, 4 Jun 2010 16:41:22 GMT From: Bruce Davie Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 4 Jun 2010 12:41:21 -0400 Message-Id: To: rsvp-dir@ietf.org Mime-Version: 1.0 (Apple Message framework v1078) X-Mailer: Apple Mail (2.1078) Subject: [rsvp-dir] Our first work items for RSVP Directorate X-BeenThere: rsvp-dir@ietf.org 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 16:41:38 -0000 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=20 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: >=20 > 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 From lberger@labn.net Fri Jun 4 09:59:22 2010 Return-Path: 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 98D613A67AB for ; Fri, 4 Jun 2010 09:59:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.188 X-Spam-Level: X-Spam-Status: No, score=-0.188 tagged_above=-999 required=5 tests=[AWL=-0.523, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334] 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 xdiOI1OEw4kk for ; Fri, 4 Jun 2010 09:59:21 -0700 (PDT) Received: from cpoproxy2-pub.bluehost.com (cpoproxy2-pub.bluehost.com [67.222.39.38]) by core3.amsl.com (Postfix) with SMTP id B284F3A69D4 for ; Fri, 4 Jun 2010 09:59:21 -0700 (PDT) Received: (qmail 31911 invoked by uid 0); 4 Jun 2010 16:59:07 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy2.bluehost.com with SMTP; 4 Jun 2010 16:59:07 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=XtW6UdVw4tk6vD2gebdE0DzpI1ix1mmUXEIFpYNJlub+WajWlihySbRBcAcfFYioUhtEA2mWvHI80gD4UZJFfNo41SJP5FQnwpUwQ/3w5FfF7xbDUBUu7yrBGsgYknrh; Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1OKaEd-0004ZY-Gu; Fri, 04 Jun 2010 10:59:07 -0600 Message-ID: <4C0930DE.9040808@labn.net> Date: Fri, 04 Jun 2010 12:59:10 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.7) Gecko/20100301 Eudora/3.0.1 MIME-Version: 1.0 To: Bruce Davie References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: rsvp-dir@ietf.org Subject: Re: [rsvp-dir] Our first work items for RSVP Directorate X-BeenThere: rsvp-dir@ietf.org 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 16:59:22 -0000 Bruce, On 6/4/2010 12:41 PM, 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? > No concerns, but this does raise the point that the directorate should be aware of draft-berger-ccamp-assoc-info-01. Particularly that in it's current form the draft extends a TE mechanism to apply to the non-TE/LSP RSVP sessions. Lou From rbriscoe@jungle.bt.co.uk Fri Jun 4 10:40:02 2010 Return-Path: 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 EF85C3A67AB for ; Fri, 4 Jun 2010 10:40:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.775 X-Spam-Level: X-Spam-Status: No, score=0.775 tagged_above=-999 required=5 tests=[AWL=0.292, BAYES_50=0.001, DNS_FROM_RFC_BOGUSMX=1.482, RCVD_IN_DNSWL_LOW=-1] 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 rPC29dSPJiiL for ; Fri, 4 Jun 2010 10:39:54 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id 3D7F93A69D5 for ; Fri, 4 Jun 2010 10:39:53 -0700 (PDT) Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 4 Jun 2010 18:39:39 +0100 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 4 Jun 2010 18:39:39 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1275673178266; Fri, 4 Jun 2010 18:39:38 +0100 Received: from MUT.jungle.bt.co.uk ([10.215.130.87]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id o54HdaXY031030; Fri, 4 Jun 2010 18:39:36 +0100 Message-Id: <201006041739.o54HdaXY031030@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 04 Jun 2010 18:39:40 +0100 To: Bruce Davie From: Bob Briscoe In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 04 Jun 2010 17:39:39.0688 (UTC) FILETIME=[E87DFA80:01CB040C] Cc: rsvp-dir@ietf.org Subject: Re: [rsvp-dir] Our first work items for RSVP Directorate X-BeenThere: rsvp-dir@ietf.org 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:40:02 -0000 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 >rsvp-dir@ietf.org >https://www.ietf.org/mailman/listinfo/rsvp-dir ________________________________________________________________ Bob Briscoe, BT Innovate & Design From bdavie@cisco.com Fri Jun 4 10:48:25 2010 Return-Path: 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 3473F3A68A0 for ; Fri, 4 Jun 2010 10:48:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.999 X-Spam-Level: X-Spam-Status: No, score=-7.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 ibOTHB4J9B1x for ; Fri, 4 Jun 2010 10:48:24 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 2CD743A67E5 for ; Fri, 4 Jun 2010 10:48:24 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; 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 sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 04 Jun 2010 17:48:10 +0000 Received: from [10.32.241.76] ([10.32.241.76]) by sj-core-5.cisco.com (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: <201006041739.o54HdaXY031030@bagheera.jungle.bt.co.uk> Date: Fri, 4 Jun 2010 13:48:09 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9785CB6C-C88B-4B62-8662-57933C644339@cisco.com> References: <201006041739.o54HdaXY031030@bagheera.jungle.bt.co.uk> To: Bob Briscoe X-Mailer: Apple Mail (2.1078) Cc: rsvp-dir@ietf.org Subject: Re: [rsvp-dir] Our first work items for RSVP Directorate X-BeenThere: rsvp-dir@ietf.org 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 Bob, 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. Bruce On Jun 4, 2010, at 1:39 PM, Bob Briscoe wrote: > Bruce, >=20 > Will take a look. >=20 > 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"? >=20 > 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. >=20 > Is this fair? >=20 >=20 > Bob >=20 > 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: >>=20 >> draft-narayanan-tsvwg-rsvp-resource-sharing-02 >>=20 >> draft-lefaucheur-tsvwg-rsvp-multiple-preemption-02.txt >> draft-polk-tsvwg-intserv-multiple-tspec-03.txt >>=20 >> 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". >>=20 >> I would like to recommend that this be made a TSVWG work item. Any = comments or concerns? >>=20 >> 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. >>=20 >> 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? >>=20 >> Thanks, >> Bruce >>=20 >>=20 >> _______________________________________________ >> rsvp-dir mailing list >> rsvp-dir@ietf.org >> https://www.ietf.org/mailman/listinfo/rsvp-dir >=20 > ________________________________________________________________ > Bob Briscoe, BT Innovate & Design=20 From rbriscoe@jungle.bt.co.uk Mon Jun 7 10:51:41 2010 Return-Path: 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 1CBCD3A6A1B for ; Mon, 7 Jun 2010 10:51:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.483 X-Spam-Level: X-Spam-Status: No, score=0.483 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_RFC_BOGUSMX=1.482, RCVD_IN_DNSWL_LOW=-1] 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 QrT4GZ0I6JEv for ; Mon, 7 Jun 2010 10:51:34 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id A0F2128C266 for ; Mon, 7 Jun 2010 10:29:48 -0700 (PDT) Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 7 Jun 2010 18:29:48 +0100 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 7 Jun 2010 18:29:47 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1275931786656; Mon, 7 Jun 2010 18:29:46 +0100 Received: from MUT.jungle.bt.co.uk ([10.215.130.87]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id o57HTkCC015181; Mon, 7 Jun 2010 18:29:46 +0100 Message-Id: <201006071729.o57HTkCC015181@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 07 Jun 2010 18:29:50 +0100 To: Bruce Davie From: Bob Briscoe In-Reply-To: <9785CB6C-C88B-4B62-8662-57933C644339@cisco.com> References: <201006041739.o54HdaXY031030@bagheera.jungle.bt.co.uk> <9785CB6C-C88B-4B62-8662-57933C644339@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 07 Jun 2010 17:29:47.0974 (UTC) FILETIME=[070AD660:01CB0667] Cc: rsvp-dir@ietf.org Subject: Re: [rsvp-dir] Our first work items for RSVP Directorate X-BeenThere: rsvp-dir@ietf.org 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: Mon, 07 Jun 2010 17:51:41 -0000 Bruce, Perhaps there's a misunderstanding... Yes, I'm sure the authors want them to be WG drafts. And I'm sure the drafts are technically interesting enough. But I'm asking for the motivations from the authors that justifies why they think each draft is suitable to take IETF time as a WG draft (and our directorate reviewing time). In your original email, you gave nice outlines of *what* each draft is about, and we've all seen the presentations. But none of the presentations or the nice text capsules answer questions like: - This is needed for new applications w & x that are becoming important in the defence and the enterprise sectors - and yes, another way to do it is already standardised, but this new approach saves y amount of messages compared to approach z that we already have, - and n organisations/customers have said they would be interested in this being standardised and will contribute reviews. - or we admit no-one has said they would be interested, but it will provide a new fundamental capability that will enable p,q and r that people would not even be able to imagine they might want unless we standardse it. ie, stuff specific to each doc, that satisfies the concerns that led to the creation of this directorate in the first place. Bob At 18:48 04/06/2010, Bruce Davie wrote: >Bob, > 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. > >Bruce > >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 > >> rsvp-dir@ietf.org > >> https://www.ietf.org/mailman/listinfo/rsvp-dir > > > > ________________________________________________________________ > > Bob Briscoe, BT Innovate & Design ________________________________________________________________ Bob Briscoe, BT Innovate & Design From bdavie@cisco.com Mon Jun 7 16:19:25 2010 Return-Path: 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 9B1773A68AF for ; Mon, 7 Jun 2010 16:19:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.999 X-Spam-Level: X-Spam-Status: No, score=-7.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 5Enn-jKP9CWx for ; Mon, 7 Jun 2010 16:19:24 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 42AA53A6832 for ; Mon, 7 Jun 2010 16:19:24 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAH4bDUyrR7Hu/2dsb2JhbACeKXGldZo2hRcE X-IronPort-AV: E=Sophos;i="4.53,381,1272844800"; d="scan'208";a="541260584" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 07 Jun 2010 23:19:25 +0000 Received: from [10.32.241.76] ([10.32.241.76]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o57NJOOP022178; Mon, 7 Jun 2010 23:19:24 GMT Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Bruce Davie In-Reply-To: <201006071729.o57HTkCC015181@bagheera.jungle.bt.co.uk> Date: Mon, 7 Jun 2010 19:19:23 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201006041739.o54HdaXY031030@bagheera.jungle.bt.co.uk> <9785CB6C-C88B-4B62-8662-57933C644339@cisco.com> <201006071729.o57HTkCC015181@bagheera.jungle.bt.co.uk> To: Bob Briscoe X-Mailer: Apple Mail (2.1078) Cc: rsvp-dir@ietf.org Subject: Re: [rsvp-dir] Our first work items for RSVP Directorate X-BeenThere: rsvp-dir@ietf.org 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: Mon, 07 Jun 2010 23:19:25 -0000 Bob, I think we're still figuring out the rules of engagement here...let me = see if we can converge. Here is what I said to Lars about creating this directorate: >=20 > [...] I want to make a concrete suggestion that might help address = your concern going forward. I talked with Bob Braden, Scott, and = Francois about the formation of an "RSVP directorate". I think we could = assemble say 5 people, and those people would make a commitment to = perform the tasks mentioned above (read drafts, comment on their = suitability for adoption, review and comment) and also beat the bushes = to get more people to review and comment on drafts. I truly think that = the BOF has lit a fire under the people who care about RSVP, which is = why you're seeing people like Allain from SFR and Sanjay from Espial = being more forthcoming than usual. In any case, while we can't change = the past, the BOF sure seemed to me to suggest we can't shut down RSVP = work at the IETF right now without ignoring the wishes of the folks who = came to the BoF and spoke. So, as I see it, the first job of the directorate is to review drafts = that have been proposed for adoption, i.e., the 3 drafts that I = mentioned below.=20 You seem to be saying "why should the directorate waste its time = reviewing drafts if the authors can't make the case that they are = solving a problem that matters to someone, or will matter in the = future".=20 And I will grant you that the 3 drafts under consideration right now = don't do a great job of making that case. So, how about I approach the = authors and ask them for a paragraph or two to justify our reviewing = cycles, along the lines of what you have said below.=20 My hope is that they next time these guys show up at an IETF and present = their drafts, they can at least have a few people who will admit to = having read the drafts.=20 Bruce On Jun 7, 2010, at 1:29 PM, Bob Briscoe wrote: > Bruce, >=20 > Perhaps there's a misunderstanding... >=20 > Yes, I'm sure the authors want them to be WG drafts. And I'm sure the = drafts are technically interesting enough. >=20 > But I'm asking for the motivations from the authors that justifies why = they think each draft is suitable to take IETF time as a WG draft (and = our directorate reviewing time). >=20 > In your original email, you gave nice outlines of *what* each draft is = about, and we've all seen the presentations. But none of the = presentations or the nice text capsules answer questions like: >=20 > - This is needed for new applications w & x that are becoming = important in the defence and the enterprise sectors > - and yes, another way to do it is already standardised, but this new = approach saves y amount of messages compared to approach z that we = already have, > - and n organisations/customers have said they would be interested in = this being standardised and will contribute reviews. > - or we admit no-one has said they would be interested, but it will = provide a new fundamental capability that will enable p,q and r that = people would not even be able to imagine they might want unless we = standardse it. >=20 > ie, stuff specific to each doc, that satisfies the concerns that led = to the creation of this directorate in the first place. >=20 >=20 > Bob >=20 > At 18:48 04/06/2010, Bruce Davie wrote: >> Bob, >> 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. >>=20 >> 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. >>=20 >> Bruce >>=20 >> On Jun 4, 2010, at 1:39 PM, Bob Briscoe wrote: >>=20 >> > 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 >> >> rsvp-dir@ietf.org >> >> https://www.ietf.org/mailman/listinfo/rsvp-dir >> > >> > ________________________________________________________________ >> > Bob Briscoe, BT Innovate & Design >=20 > ________________________________________________________________ > Bob Briscoe, BT Innovate & Design=20 From rbriscoe@jungle.bt.co.uk Tue Jun 8 08:18:45 2010 Return-Path: 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 E56BF28C1D8 for ; Tue, 8 Jun 2010 08:18:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.483 X-Spam-Level: X-Spam-Status: No, score=0.483 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_RFC_BOGUSMX=1.482, RCVD_IN_DNSWL_LOW=-1] 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 HC5ZUG4vHATB for ; Tue, 8 Jun 2010 08:18:24 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id 3DDC83A69C5 for ; Tue, 8 Jun 2010 08:18:15 -0700 (PDT) Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 Jun 2010 16:18:15 +0100 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 8 Jun 2010 16:18:15 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt08.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1276010294516; Tue, 8 Jun 2010 16:18:14 +0100 Received: from MUT.jungle.bt.co.uk ([10.215.130.87]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id o58FIDAk026957; Tue, 8 Jun 2010 16:18:13 +0100 Message-Id: <201006081518.o58FIDAk026957@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 08 Jun 2010 16:18:18 +0100 To: Bruce Davie From: Bob Briscoe In-Reply-To: References: <201006041739.o54HdaXY031030@bagheera.jungle.bt.co.uk> <9785CB6C-C88B-4B62-8662-57933C644339@cisco.com> <201006071729.o57HTkCC015181@bagheera.jungle.bt.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 08 Jun 2010 15:18:15.0158 (UTC) FILETIME=[D0F87160:01CB071D] Cc: rsvp-dir@ietf.org Subject: Re: [rsvp-dir] Our first work items for RSVP Directorate X-BeenThere: rsvp-dir@ietf.org 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: Tue, 08 Jun 2010 15:18:45 -0000 Bruce, At 00:19 08/06/2010, Bruce Davie wrote: >Bob, > I think we're still figuring out the rules of engagement > here...let me see if we can converge. > Here is what I said to Lars about creating this directorate: > > > > [...] I want to make a concrete suggestion that might help > address your concern going forward. I talked with Bob Braden, > Scott, and Francois about the formation of an "RSVP directorate". I > think we could assemble say 5 people, and those people would make a > commitment to perform the tasks mentioned above (read drafts, > comment on their suitability for adoption, review and comment) and > also beat the bushes to get more people to review and comment on > drafts. I truly think that the BOF has lit a fire under the people > who care about RSVP, which is why you're seeing people like Allain > from SFR and Sanjay from Espial being more forthcoming than usual. > In any case, while we can't change the past, the BOF sure seemed to > me to suggest we can't shut down RSVP work at the IETF right now > without ignoring the wishes of the folks who came to the BoF and spoke. > > >So, as I see it, the first job of the directorate is to review >drafts that have been proposed for adoption, i.e., the 3 drafts that >I mentioned below. > >You seem to be saying "why should the directorate waste its time >reviewing drafts if the authors can't make the case that they are >solving a problem that matters to someone, or will matter in the future". >And I will grant you that the 3 drafts under consideration right now >don't do a great job of making that case. So, how about I approach >the authors and ask them for a paragraph or two to justify our >reviewing cycles, along the lines of what you have said below. Thanks Bruce. That's exactly what I'm saying. Except I don't expect them to write this sort of stuff actually in the drafts (drafts should normally only contain timeless info). But I would expect such motivation in a presentation or an email to the list at the point where WG draft is requested. I looked and it wasn't there (at a first pass at least). When I ask for one of my drafts to become a w-g item, I am always expected to provide such info. So I want these guys to jump the same hoops we all have to. >My hope is that they next time these guys show up at an IETF and >present their drafts, they can at least have a few people who will >admit to having read the drafts. Certainly. Cheers Bob >Bruce > > >On Jun 7, 2010, at 1:29 PM, Bob Briscoe wrote: > > > Bruce, > > > > Perhaps there's a misunderstanding... > > > > Yes, I'm sure the authors want them to be WG drafts. And I'm sure > the drafts are technically interesting enough. > > > > But I'm asking for the motivations from the authors that > justifies why they think each draft is suitable to take IETF time > as a WG draft (and our directorate reviewing time). > > > > In your original email, you gave nice outlines of *what* each > draft is about, and we've all seen the presentations. But none of > the presentations or the nice text capsules answer questions like: > > > > - This is needed for new applications w & x that are becoming > important in the defence and the enterprise sectors > > - and yes, another way to do it is already standardised, but this > new approach saves y amount of messages compared to approach z that > we already have, > > - and n organisations/customers have said they would be > interested in this being standardised and will contribute reviews. > > - or we admit no-one has said they would be interested, but it > will provide a new fundamental capability that will enable p,q and > r that people would not even be able to imagine they might want > unless we standardse it. > > > > ie, stuff specific to each doc, that satisfies the concerns that > led to the creation of this directorate in the first place. > > > > > > Bob > > > > At 18:48 04/06/2010, Bruce Davie wrote: > >> Bob, > >> 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. > >> > >> Bruce > >> > >> 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 > >> >> rsvp-dir@ietf.org > >> >> https://www.ietf.org/mailman/listinfo/rsvp-dir > >> > > >> > ________________________________________________________________ > >> > Bob Briscoe, BT Innovate & Design > > > > ________________________________________________________________ > > Bob Briscoe, BT Innovate & Design ________________________________________________________________ Bob Briscoe, BT Innovate & Design