Re: Submitted rev of RSVP APP-ID profiles ID

Francois Le Faucheur <> Wed, 10 November 2010 02:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BDAE13A63C9 for <>; Tue, 9 Nov 2010 18:38:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.889
X-Spam-Status: No, score=-9.889 tagged_above=-999 required=5 tests=[AWL=-0.710, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_GIF_ATTACH=1.42]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mI0XC8gJxpcd for <>; Tue, 9 Nov 2010 18:38:20 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 33A253A635F for <>; Tue, 9 Nov 2010 18:38:11 -0800 (PST)
Authentication-Results:; dkim=neutral (message not signed) header.i=none
X-Files: image001.jpg, green.gif : 11041, 87
X-IronPort-AV: E=Sophos; i="4.59,176,1288569600"; d="gif'147?jpg'147,145?scan'147,145,208,145,147"; a="617336527"
Received: from ([]) by with ESMTP; 10 Nov 2010 02:38:37 +0000
Received: from ( []) by (8.13.8/8.14.3) with ESMTP id oAA2cXTg019382; Wed, 10 Nov 2010 02:38:35 GMT
Subject: Re: Submitted rev of RSVP APP-ID profiles ID
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: multipart/mixed; boundary="Apple-Mail-77--335840860"
From: Francois Le Faucheur <>
In-Reply-To: <>
Date: Wed, 10 Nov 2010 10:34:47 +0800
Message-Id: <>
References: <>
To: "James M. Polk" <>
X-Mailer: Apple Mail (2.1081)
Cc: tsvwg <>
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: Wed, 10 Nov 2010 02:38:33 -0000

Hi James,

A few more suggestions:

* for the GUID, you may want to use "" where xyz will be the RFC number of your document
(instead of rfc4594 and rfc5865) because really it is your document that defines the meaning of what comes afterwards.

* you could probably structure the document a little more succinctly by merging all the sub--sections 3.x and just have a table that lists all possible values and the reference to the RFC where the class is actually are defined (ie rfc4594 and rfc5865)

* regarding the VER field:
I am not clear about the value of mandating the inclusion of VER= and mandating there is no value afterwards. If there is a need for VER later, then whatever document defines its meaning can simply state that the field can be added then. 

* regarding a new P-Type: 
One thing you must make sure is that it is possible to signal both an App class and a regular app identity  (eg "real-time-interactive" & "MyFavoriteAppVendor/MyFAvoriteApp". As long as this is possible I am happy.
Another option that came to my mind is that you keep the existing P-Type but define a new keyword "APP-CLASS=" instead of "APP=". So you now have three choices. EIther one is fine by me (as long as you confirm the requirement above is met).



On 29 Oct 2010, at 08:10, James M. Polk wrote:

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

Francois Le Faucheur
Distinguished Engineer
Corporate Development
Phone: +33 49 723 2619
Mobile: +33 6 19 98 50 90

Cisco Systems France
400 Ave de Roumanille
06410 Sophia Antipolis


 Think before you print.

This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message.

Cisco Systems France, Société à responsabiité limitée, Rue Camille Desmoulins – Imm Atlantis Zac Forum Seine Ilot 7 92130 Issy les Moulineaux, Au capital de 91.470 €, 349 166 561 RCS Nanterre, Directeur de la publication: Jean-Luc Michel Givone.

For corporate legal information go to: