Submitted rev of RSVP APP-ID profiles ID

"James M. Polk" <> Fri, 29 October 2010 00:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id ACAB83A6971 for <>; Thu, 28 Oct 2010 17:09:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -110.55
X-Spam-Status: No, score=-110.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uvnDGqlF9mck for <>; Thu, 28 Oct 2010 17:09:06 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 8548C3A6452 for <>; Thu, 28 Oct 2010 17:09:06 -0700 (PDT)
Authentication-Results:; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAGuuyUyrR7H+/2dsb2JhbAChVHGiKJwlgnOCVQSEVw
X-IronPort-AV: E=Sophos;i="4.58,255,1286150400"; d="scan'208";a="287760883"
Received: from ([]) by with ESMTP; 29 Oct 2010 00:10:53 +0000
Received: from ( []) by (8.13.8/8.14.3) with ESMTP id o9T0Arw7013334 for <>; Fri, 29 Oct 2010 00:10:53 GMT
Message-Id: <>
X-Mailer: QUALCOMM Windows Eudora Version
Date: Thu, 28 Oct 2010 19:10:52 -0500
To: tsvwg <>
From: "James M. Polk" <>
Subject: Submitted rev of RSVP APP-ID profiles ID
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Transport Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 29 Oct 2010 00:09:07 -0000


I've submitted a rev of the RSVP APP-ID profiles ID, here

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 "" 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?

(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 
> "" 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).