Submitted rev of RSVP APP-ID profiles ID

["James M. Polk" <[e-mail]>]

TSVWG

I've submitted a rev of the RSVP APP-ID profiles ID, here
http://www.ietf.org/internet-drafts/draft-polk-tsvwg-rsvp-app-id-vv-profiles-01.txt

This rev addresses two of Francois's three concerns below, which I'll 
answer now (Francois, a thousand pardons!!!):

- I incorporated his suggestion to change the value of the GUID from 
something like "RFC4594" to "http://www.ietf.org/rfc/rfc4594.txt" for 
each profile.

- I removed the (obvious now) DSCP from each profile name

- I did not address creating a new attribute for this simple reason, 
right now, this is only an IANA registry doc, and creating a new 
attribute would make it more than it is.  I don't have a clear view 
of what folks think about making this change. I know that right now, 
this is an individual ID so I can make any changes I want, but I'd 
like to get the WG to agree to this change -- which I'm not against. 
What do folks think about making this more than a simple IANA registry doc?

James
(without my WG chair hat on, obviously)


>James, Subha,
>
>The idea of signaling an RSVP policy locator at the granularity of 
>application class make sense to me.
>
>A few comments on the document from a first read:
>         * for GUID, I suggest you use something like 
> "http://www.ietf.org/rfc/rfc4594.txt" instead of "RFC4594"
>         * have you considered defining a new attribute (eg APP-SC = 
> Application Service Class) to carry the application service class 
> instead of reusing the existing APP attribute (that is itended to 
> identify applications)?
>         * I strongly suggest you remove the DS Codepoint from the 
> name of each "profile"
>(ie s/The Broadcast video (CS5) Profile/The Broadcast video 
>Profile/) because the relationship between the two is only 
>"RECOMMENDED". So what you want to signal is the Service Class, 
>which typically will be mapped into the recommended CS codepoint 
>(but possibly into another).
>
>Cheers
>
>Francois