Re: [rsvp-dir] Getting RSVP Directorate Feedback into TSVWG

Lixia Zhang <lixia@cs.ucla.edu> Tue, 09 November 2010 03:07 UTC

Return-Path: <lixia@cs.ucla.edu>
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 EFC023A6930 for <rsvp-dir@core3.amsl.com>; Mon, 8 Nov 2010 19:07:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 F8QDIHX-+Y8e for <rsvp-dir@core3.amsl.com>; Mon, 8 Nov 2010 19:07:22 -0800 (PST)
Received: from smtp.cs.ucla.edu (smtp.cs.ucla.edu [131.179.128.62]) by core3.amsl.com (Postfix) with ESMTP id 72A5028C28B for <rsvp-dir@ietf.org>; Mon, 8 Nov 2010 19:07:14 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id 893FA39E80B1; Mon, 8 Nov 2010 19:07:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu
Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e4r6SjgUBZKf; Mon, 8 Nov 2010 19:07:36 -0800 (PST)
Received: from dhcp-446b.meeting.ietf.org (dhcp-446b.meeting.ietf.org [130.129.68.107]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id 6131E39E80FA; Mon, 8 Nov 2010 19:07:34 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=us-ascii
From: Lixia Zhang <lixia@cs.ucla.edu>
In-Reply-To: <4CCFD5D4.5000009@erg.abdn.ac.uk>
Date: Mon, 8 Nov 2010 19:07:31 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <1AF60ABC-97D5-4DE9-BE72-7297B2248797@cs.ucla.edu>
References: <201011012250.oA1MoRUu007129@sj-core-3.cisco.com> <FD7CFB5D-9E65-45B5-A93E-59F4B6752624@cisco.com> <201011012358.oA1NwuAA027247@sj-core-2.cisco.com> <4CCFD5D4.5000009@erg.abdn.ac.uk>
To: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
X-Mailer: Apple Mail (2.1081)
Cc: rsvp-dir@ietf.org, "James M. Polk" <jmpolk@cisco.com>
Subject: Re: [rsvp-dir] Getting RSVP Directorate Feedback into TSVWG
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: Tue, 09 Nov 2010 03:07:25 -0000

On Nov 2, 2010, at 2:11 AM, Gorry Fairhurst wrote:

> James,
> 
> At the most basic level, I need help and I need to see reviews posted to the list. At the moment, since you are personally involved in some drafts this leaves me very exposed and this leaves us without an "RSVP" Chair. I think the directorate can help fix this. We seem to be still working out the ways the directorate can help.
> 
> Here is what I think can be done, suggestions welcome:
> 
> 1) If I were to see several sets of detailed comments, a few reviews of the wording and scope of sections, promises to review in the WG and contribute to WGLC, etc - My recommendation to the ADs would be much clearer. I have so far, seen one review from the directorate from Bruce Davie (thanks). I can post my notes to the directorate to restore synchronisation and see if others have more to add, if this helps.
> 
> 2) I did make a list of questions that I'd like the directorate to help answer (David Harrington also posted a list). Answers to well-chosen questions would be extremely helpful in deciding whether to progress a draft. I would be happy to attempt to merge the list of questions and repost them - checking first with our ADs.
> 
> 3) I didn't see much discussion on RSVP on the list in the last period, nor substantive "improvements" in the drafts - I can see this may mostly easily follow (1,2) above.
> 
> 4) If the directorate/WG would like, it is possible we could formulate a more formal set of requirements for progression of an I-D along the lines you hint at below. You should not be surprised that I'd generally agree with what you say: 5 reviews would be great, promises that reviews would be provided (and NiT lists) to the WG and at WGLC would also seem very helpful. To me, I don't think this means you need to prove the spec is implementable/interoperable when it is standardised (as I recall, SCTP-advocates said they liked this approach, and that worked for them, which I liked). I'd weight heavily any interop experience and would attach value customer/service provider reviews and requirements. But personally, I'd recommend another go at (1,2,3) before we reach this stage (4) - the results of a formal process are of course easier to see and to appeal should you need, they are however likely to be binding and inflexible.
> 
> James/directorate do let me know your thoughts and we can move forward.
> 
> Gorry

catching up email by skipping some WG meetings :(

1/ as Bruce mentioned earlier, I did give my vote earlier (around Maastricht IETF?) for letting the 2 drafts move forward.

I just flipped through the two drafts again, look fine to me in principle (I admit I did not examine all details). One minor comment is that carrying multiple TSPEC in RESV makes the router do more work, but I'm not a router vendor to know whether that is/not an problem (and the authors do work for a known vendor:)

2/ Gorry mentioned in the above that he and Dave made a list of specific questions. Would be happy to help answer those questions, but I dont think I have seen the list (this is the last msg on this threat)

Lixia
 
> 
> 
> On 01/11/2010 23:58, James M. Polk wrote:
>> Bruce
>> 
>> Thanks for responding so quickly. Part of my reaction was to what the
>> ADs said in Maastricht during TSVWG, that they had no input from the
>> Directorate, and the discussion went downhill from there IMO. Depending
>> on who you believe, even after listening to the meeting audio, there was
>> 
>> - mention of the need for two independent implementations in order for
>> the ADs to agree to have MULTI_TSPEC adopted as a WG item (by one AD);
>> and
>> - there was mention of the need for 5 full reviews of any new
>> RSVP/IntServ based ID before one AD would consider recommending to TSVWG
>> that they adopt this item (this by the other AD).
>> 
>> With either one of the above, the bar is set quite high (in fact higher
>> than I've ever experienced in the IETF).
>> 
>> Additionally, the discussion of the first topic (needing two
>> implementations to be considered a WG item) devolved IMO when Randy
>> Stewart joined the discussion by indicating that this is what he does
>> for all his SCTP IDs, therefore the practice ought to used for everything.
>> 
>> No one in the WG agreed to this other than Randy, and in fact, had
>> several folks stating on the mic this was out of line to ask for (Matt
>> Mathis, Fred Baker, and Ken Carlberg if memory serves).
>> 
>> James
>> 
>> 
>> At 05:55 PM 11/1/2010, Bruce Davie wrote:
>>> James,
>>> I have reviewed the multiple tspec draft and I am in favor of its
>>> adoption (as I think I have said before, and, IIRC, I provided details
>>> as to why). I think Lixia is also on record as supporting that draft.
>>> 
>>> I have asked the directorate for feedback a couple of times, and Bob
>>> Briscoe gave some feedback, which led to me gather more info from you
>>> as to why these drafts were worthy of consideration. I have provided
>>> that info to the directorate.
>>> 
>>> I will craft a more publicly acceptable email for the TSVWG list. But
>>> I can't speak much more for the directorate than I have done here.
>>> 
>>> Bruce
>>> 
>>> 
>>> On Nov 1, 2010, at 6:50 PM, James M. Polk wrote:
>>> 
>>> > All
>>> >
>>> > This is written as both the TSVWG chair and as an individual author
>>> of several active IDs into TSVWG.
>>> >
>>> > As an individual, I didn't think I needed to request this, but I am
>>> anyway - because I haven't received any feedback from the RSVP
>>> Directorate to date, and we're 5 days away from the next IETF meeting.
>>> >
>>> > I am requesting that the RSVP Directorate review these two IDs
>>> >
>>> >
>>> http://www.ietf.org/internet-drafts/draft-polk-tsvwg-intserv-multiple-tspec-05.txt
>>> and
>>> >
>>> http://www.ietf.org/internet-drafts/draft-polk-tsvwg-rsvp-app-id-vv-profiles-01.txt
>>> 
>>> >
>>> > Are either or both of these IDs worth the effort of the TSVWG to
>>> take on a WG items (or not)?
>>> >
>>> > Lars freely admits that he considers IntServ to be joined with RSVP
>>> wrt the TSVWG charter. We chairs are crafting text for a charter
>>> update to reflect that explicitly.
>>> >
>>> > The MULTI_TSPEC ID has been presented at every IETF, in TSVWG, since
>>> San Francisco -- and really was the reason this Directorate formed
>>> (because the ADs chose to punt the ball wrt whether to allow the
>>> adoption of this WG item by TSVWG). This Directorate had a BoF of
>>> sorts in Anaheim, which was well attended and included a lot of
>>> energy. At issue is that no one from the Directorate provided an ounce
>>> of input into TSVWG for the next IETF (in Maastricht), and I - as
>>> chair - haven't heard from any of you since Maastricht on either of
>>> the documents listed above one way or the other.
>>> >
>>> > This is where I put my WG chair hat on, as ask - rather bluntly -
>>> why there has been zero input into TSVWG even though the Directorate
>>> charter (if you will) clearly states reviewing RSVP based IDs is the
>>> purpose of the Directorate, and the fact that there are now two IDs
>>> sitting in completely limbo awaiting WG input from the Directorate.
>>> >
>>> > I realize everyone's time here is quite busy, but these IDs need
>>> feedback from those chartered to give said feedback.
>>> >
>>> > Please response on to this nudge on the TSVWG list.
>>> >
>>> > James
>>> >
>> 
>> 
>