Re: [MMUSIC] Trafficclass Attribute -02 submitted

Paul Kyzivat <pkyzivat@alum.mit.edu> Thu, 19 July 2012 17:31 UTC

Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FE6F21F87E7 for <mmusic@ietfa.amsl.com>; Thu, 19 Jul 2012 10:31:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.344
X-Spam-Level:
X-Spam-Status: No, score=-2.344 tagged_above=-999 required=5 tests=[AWL=0.255, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mmUIornryMpI for <mmusic@ietfa.amsl.com>; Thu, 19 Jul 2012 10:31:33 -0700 (PDT)
Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [76.96.59.211]) by ietfa.amsl.com (Postfix) with ESMTP id 24A8821F87D4 for <mmusic@ietf.org>; Thu, 19 Jul 2012 10:31:32 -0700 (PDT)
Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by QMTA11.westchester.pa.mail.comcast.net with comcast id cGbj1j0021c6gX85BHYStJ; Thu, 19 Jul 2012 17:32:26 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta23.westchester.pa.mail.comcast.net with comcast id cHYF1j00p3ZTu2S3jHYFGs; Thu, 19 Jul 2012 17:32:15 +0000
Message-ID: <500844A6.6090304@alum.mit.edu>
Date: Thu, 19 Jul 2012 13:32:22 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: mmusic@ietf.org
References: <201207171919.q6HJJQij014492@mtv-core-3.cisco.com> <5005DBCA.8040405@alum.mit.edu>
In-Reply-To: <5005DBCA.8040405@alum.mit.edu>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [MMUSIC] Trafficclass Attribute -02 submitted
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Jul 2012 17:31:34 -0000

I have a general question about this draft:

The descriptions of the five categories in 2.1-2.5 are each 
characterized by values for tolerance to loss, delay, and jitter. It 
appears that there are 64 possible combinations of values for those 
things. (Four values for each - very low, low, medium, high.) And the 
existing 5 categories cover 17 of those combinations. (Some cover more 
than one.)

Is it intended that each combination of those values be associated with 
at most one defined category? (IOW, if a new category is to be defined, 
it must be defined with values that don't conflict with any previously 
defined category.)

(There is a similar characterization in RFC4594. There the service class 
names don't have unique characterizations. But there the names are 
complete service classes, whereas the current draft the category name is 
qualified by application and attribute to construct a traffic class name.)

IIUC, the category name should identify the required tolerance to loss, 
delay, and jitter. Then the application and attributes provide 
additional info about the intended use that can be taken into account 
for policy decisions. Do I have it right?

	Thanks,
	Paul

On 7/17/12 5:40 PM, Paul Kyzivat wrote:
> Some comments on the new version:
>
> In section 3 (SDP syntax):
>
> tcl-token = %2D / %30-%39 / %41-%5A / %61-7A
>
> That only allows one character tokens. Minimally you probably want:
>
> tcl-token = 1*(%2D / %30-%39 / %41-%5A / %61-7A)
>
> But it would be more readable as:
>
> tcl-token = 1*( ALPHA / DIGIT / "-" )
>
> (Those symbols are defined with ABNF in RFC 5234. If so you need a
> reference. Paraphrasing 3261, you might say: "Appendix B.1 of RFC 5234
> defines a set of core rules that are used by this specification, and not
> repeated here.")
>
> But that allows leading and trailing, and multiple consecutive "-"s. So
> you could tighten it up with:
>
> tcl-token = ALPHA 0*(ALPHA / DIGIT) 0*("-" 1*(ALPHA / DIGIT))
>
> Also, your syntax doesn't cover non-standard-adjectives. You could cover
> that by:
>
> adjective = standard-adjective / non-standard-adjective
>
> standard-adjective = classified-adjective / unclassified-adjective
>
> non-standard-adjective = "_" standard-adjective
>
> Sections 6.3 & 6.4:
>
> "Specification Required" implies expert review. That in turn calls for
> some criteria by which the expert can decide if a proposed value is
> appropriate to be registered.
>
> IIUC, 'aq', 'admitted', 'non-admitted', and 'none' are *not* Unqualified
> adjectives. Rather,
>
> 'aq:admitted', 'aq:non-admitted', and 'aq:none' are *qualified* adjectives.
>
> Does the distinction matter for registration? Should there be different
> criteria for registering new qualified adjectives? Maybe so. Maybe there
> should be some review of whether the new 'aq:foo' is compatible with the
> intended meaning of 'aq'???
>
> Thanks,
> Paul
>
> On 7/17/12 3:19 PM, James Polk wrote:
>> MMUSIC
>>
>> We've submitted a revision of the Traffic Class Label attribute here
>> https://datatracker.ietf.org/doc/draft-ietf-mmusic-traffic-class-for-sdp
>>
>> These are the following changes made between the WG -01 version and
>> the -02 version:
>>
>> - converged the use of terms 'parent' and 'category' to just
>> 'category' for consistency.
>>
>> - changed ABNF to reflect extensibility by not having applications
>> and adjectives named in the ABNF, rather have them merely IANA
>> registered. This was brought up on the list and in the Paris
>> meeting.
>>
>> - merged the qualified and unqualified adjective sections into a
>> single section on adjectives, but allowing some to have a
>> preceding qualifier. This was brought up on the list and in the
>> Paris meeting.
>>
>> - text clean-up
>>
>> We have one known open issue, which is related to some document
>> structure around the categories, applications and adjectives.
>>
>> We have another known open issue regarding articulating better which
>> adjectives are appropriate with which applications, as well as which
>> applications are appropriate with which categories.
>>
>> Other comments and questions are solicited.
>>
>> James/Subha/Paul
>>
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
>>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>