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 >
- [MMUSIC] Trafficclass Attribute -02 submitted James Polk
- Re: [MMUSIC] Trafficclass Attribute -02 submitted Paul Kyzivat
- Re: [MMUSIC] Trafficclass Attribute -02 submitted Paul Kyzivat
- Re: [MMUSIC] Trafficclass Attribute -02 submitted Paul E. Jones
- Re: [MMUSIC] Trafficclass Attribute -02 submitted Paul Kyzivat
- Re: [MMUSIC] Trafficclass Attribute -02 submitted Paul E. Jones