Subject: [MMUSIC] Trafficclass Attribute -02 submitted

From: James Polk <[email-masked]>
Date: Tue, 17 Jul 2012 14:19:23 -0500

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

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 17 Jul 2012 17:40:26 -0400

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 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 19 Jul 2012 13:32:22 -0400

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