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

[Gorry Fairhurst <[e-mail]>]

Thanks Ken - good to see more comments on this draft.

You may be pleased to know that I put the case to our ADs some weeks ago 
to consider a charter update that would enable the WG to consider such 
work. I'm expecting them soon to conclude and we can then move forward.

Best wishes,

Gorry

On 16/05/2011 18:59, ken carlberg wrote:
> 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.
>
>