[MMUSIC] Update to trafficclass attribute

James Polk <jmpolk@cisco.com> Thu, 01 November 2012 05:14 UTC

Return-Path: <jmpolk@cisco.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id DE49121F8545 for <mmusic@ietfa.amsl.com>; Wed, 31 Oct 2012 22:14:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id GGjeOYFlaeUl for <mmusic@ietfa.amsl.com>; Wed, 31 Oct 2012 22:14:16 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com []) by ietfa.amsl.com (Postfix) with ESMTP id 0C53F21F8531 for <mmusic@ietf.org>; Wed, 31 Oct 2012 22:14:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1686; q=dns/txt; s=iport; t=1351746856; x=1352956456; h=message-id:date:to:from:subject:mime-version; bh=9Kbi39PUjqrcoSsiRtV0UqZDhJ0Uw5E/ivNIuGo09c8=; b=cf67rHkDWVA6MY2exSlGd3r5BVmoISkR2J7/PeMzRFk+3OIl+GLfpJ2c Q9enEpHM2vtG6XPslA67/0ev0F+Y64BUUY2uTt8Yszw6EOqoUV1VoK8iZ XIR9/W44Y4cMoL7j72TL8ujOcsNS5nrGsuvYhudjSLuUgergma1jeVK4K w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EABsEklCtJV2d/2dsb2JhbABEw2WBCII3ASUCVjopRDWHZAuZXIEsoCGSNgOIWo43jT2Ba4MN
X-IronPort-AV: E=Sophos;i="4.80,691,1344211200"; d="scan'208";a="137613580"
Received: from rcdn-core-6.cisco.com ([]) by rcdn-iport-7.cisco.com with ESMTP; 01 Nov 2012 05:14:15 +0000
Received: from jmpolk-WS.cisco.com (rcdn-jmpolk-8715.cisco.com []) (authenticated bits=0) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id qA15EFYn024510 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <mmusic@ietf.org>; Thu, 1 Nov 2012 05:14:15 GMT
Message-Id: <201211010514.qA15EFYn024510@rcdn-core-6.cisco.com>
X-Mailer: QUALCOMM Windows Eudora Version
Date: Thu, 01 Nov 2012 00:14:14 -0500
To: mmusic <mmusic@ietf.org>
From: James Polk <jmpolk@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Authenticated-User: jmpolk
Subject: [MMUSIC] Update to trafficclass attribute
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, 01 Nov 2012 05:14:17 -0000


I'm letting the WG know that we've updated the trafficclass attribute 
draft to -03.


Here are the changes listed in Appendix 1 from the above URL

A.1  From -02 to -03

    These are the following changes made between the WG -02 version and
    the -03 version:

    - Rearranged a fair amount of text

    - Separated and defined the components into separate subsections.

    - built 5 different tables, one per category, that lists within each
      category - what applications are appropriate as well as what
      adjectives are appropriate for each application within that

Other stuff we did (not mentioned in the appendix), that we also changed:

- We also rather significantly modified the IANA considerations section.

- We worked with Paul K on the ABNF, which he likes now.

- created a "partial" admission qualifier for endpoints that send 
more traffic than had capacity admission applied to the session.

- we want to learn about any traffic flows we aren't considering that 
we should be.

- the rearranging made many little things visible that needed fixing, 
adding or deleting.

- what we have *not* addressed is Dan Wing's desire for a label to 
address his sensor traffic.  This is something that makes sense, but 
we want to hear from the WG on this. Should this attribute cover 
sporadic or occasional or busty and not fixed interval traffic such 
as sensor data?

I'll be mentioning most of this during my preso on Tuesday.

Comments and questions are appreciated.