draft-polk-tsvwg-intserv-multiple-tspec-06

ken carlberg <carlberg@g11.org.uk> Mon, 16 May 2011 17:59 UTC

Return-Path: <carlberg@g11.org.uk>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E746E0799 for <tsvwg@ietfa.amsl.com>; Mon, 16 May 2011 10:59:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.11
X-Spam-Level:
X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vv+4dLnS-Ztl for <tsvwg@ietfa.amsl.com>; Mon, 16 May 2011 10:59:40 -0700 (PDT)
Received: from portland.eukhosting.net (portland.eukhosting.net [92.48.97.5]) by ietfa.amsl.com (Postfix) with ESMTP id B4751E0798 for <tsvwg@ietf.org>; Mon, 16 May 2011 10:59:34 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=g11.org.uk; h=Received:From:Content-Type:Content-Transfer-Encoding:Subject:Date:Message-Id:To:Mime-Version:X-Mailer:X-Source:X-Source-Args:X-Source-Dir; b=pLZgGbe+7LMCCJamG/jKCiqNYpiF++mhHJvYad67AC5cLCu/50thMhjJSJWxo4BKu6gC6Nwf9u20S5Qr2C3Yp1l7PPtyt0CbT4szjEfi3ZF6AC6GswV/a3pPeGd3S3A3;
Received: from c-76-111-69-4.hsd1.va.comcast.net ([76.111.69.4]:51459 helo=[192.168.0.20]) by portland.eukhosting.net with esmtpa (Exim 4.69) (envelope-from <carlberg@g11.org.uk>) id 1QM24a-0005YJ-FI for tsvwg@ietf.org; Mon, 16 May 2011 17:59:16 +0000
From: ken carlberg <carlberg@g11.org.uk>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: draft-polk-tsvwg-intserv-multiple-tspec-06
Date: Mon, 16 May 2011 13:59:23 -0400
Message-Id: <F73EACB4-56D3-468A-A1FF-57BAD75D90D6@g11.org.uk>
To: tsvwg <tsvwg@ietf.org>
Mime-Version: 1.0 (Apple Message framework v1082)
X-Mailer: Apple Mail (2.1082)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - portland.eukhosting.net
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - g11.org.uk
X-Source:
X-Source-Args:
X-Source-Dir:
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tsvwg>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 May 2011 17:59:41 -0000

James and Subha,

here is a more detailed review of the draft.  The following are a combination of nits, general comments, and questions.  You can decide as to their importance. 


page 3, 4'th paragraph.  In the previous paragraph, you denote the direction of the ADSPEC as being "downstream".  for the sake of completeness, you should probably denote the direction of the RESV.

page 4, 1'st paragraph.  Break up the first sentence.  it runs waaaaaay to long with too many thoughts entwined in it.

page 4, 5'th paragraph.  You should qualify the last sentence to say that dynamically adapting data streams during reservation set up.

page 5.  Figure 1.  This figure (along with Figure 4 and Figure 6) repeat information in existing RFCs.  I have a preference to have this information removed and simply refer the reader to the appropriate RFCs.  While it may be helpful when first writing the first multi-tspec draft for the initial reading (and people reading it at its first presentation :-), I don't think anything is gained by repeating the information in future versions of the draft.  Shame on the reader for being too lazy to look up the info.

page 5, 1'st paragraph.  For the sake of completeness, you may want to point out that Section 5 deals with security considerations.

Section 3.  There is no mention of a maximum number of Multi-tspec entries (you do make mention of this in 4.10, but as an open issue).  I know this has been brought up in previous meetings, and I'd like to re-advocate the idea of putting a cap on the number of entries.  Poorly developed code, or malicious behavior, could conceivably send tspec in the hundreds (thousands?), which would seem at the very least to represent an attack vector for RSVP capable nodes.  How about something like a recommendation of at most 4 entries of the multi_tspec object, and a max of 10?  The thing to note is that if you decide to add a maximum amount, you'll probably need/want to slightly change the format of your multi_tspec object.

page 14, 3'rd paragraph.  You state that "At any router that a reservation cannot honor a TSPEC, this TSPEC MUST be removed from the RESV...".  Exactly how do you consider removing the TSPEC?  Does that router need to construct a new message without the TSPEC?  If so, would it be simpler to just add a flag indicating that the TSPEC can/cannot be supported?

Section 5.  I think that if you allow an unbounded number of tspec entries, then its difficult (incorrect?) to say that the security considerations do not exceed what has been written in rfc-2205 and rfc-2210.

General question.  Given the recent work on RSVP proxies, do you feel that a comment needs to be made about the relationship of your multi-tspec draft and that work?

-ken

ps, comment to the ADs and co-chair.  I'll reiterate again that I feel this draft, as is (and without responding to the above comments), is baked enough for it to be added as a working group document.