Re: [bfcpbis] Use of the "TBD" Mux Category in bfcpbis.

"Suhas Nandakumar (snandaku)" <snandaku@cisco.com> Wed, 24 October 2018 18:08 UTC

Return-Path: <snandaku@cisco.com>
X-Original-To: bfcpbis@ietfa.amsl.com
Delivered-To: bfcpbis@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7496126DBF; Wed, 24 Oct 2018 11:08:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level:
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xRYDqqm2g808; Wed, 24 Oct 2018 11:08:19 -0700 (PDT)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4E0B129619; Wed, 24 Oct 2018 11:08:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2964; q=dns/txt; s=iport; t=1540404498; x=1541614098; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=t+74ogaR2UBb2wnyskAueKKje1X5SApon1JZXz5nn4k=; b=Y2CZllOPU2yiFOvGWA0IVi7QNwY+EeGySMxOjncHfuCkybOYxdp7uDLV dVJ+LMsaaQaPJnOEs9i/m0EMX2edtvIu4M71FAW3KtmeOuEAZM+MKX0y5 AsU0hdPPZVa2+hOvG5IncJRyVREt1QXi5mtvrbwanXDdhc1Q6fIdFoZX6 g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0ADAAArtNBb/4UNJK1kGQEBAQEBAQEBAQEBAQcBAQEBAQGBUQQBAQEBAQsBggSBZSiDdYgYjBeBaCWXFYF6CwEBhGwCF4J0ITQNDQEDAQECAQECbSiFOgEBAQMBIxFFBQsCAQgYAgImAgICMBUQAgQOBRmDCIF6CKlKgS6KJ4ELhESGExeBQT+BEScME4JMhH6DAzGCJgKKWZN3CQKQcheBUo5eiSmNGwIRFIEmHTiBVXAVZQGCQZBXb40tAQE
X-IronPort-AV: E=Sophos;i="5.54,421,1534809600"; d="scan'208";a="191062387"
Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Oct 2018 18:08:16 +0000
Received: from XCH-ALN-009.cisco.com (xch-aln-009.cisco.com [173.36.7.19]) by alln-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id w9OI8GrE013395 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 24 Oct 2018 18:08:16 GMT
Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-ALN-009.cisco.com (173.36.7.19) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 24 Oct 2018 13:08:15 -0500
Received: from xch-aln-008.cisco.com ([173.36.7.18]) by XCH-ALN-008.cisco.com ([173.36.7.18]) with mapi id 15.00.1395.000; Wed, 24 Oct 2018 13:08:15 -0500
From: "Suhas Nandakumar (snandaku)" <snandaku@cisco.com>
To: Ben Campbell <ben@nostrum.com>
CC: "mmusic@ietf.org" <mmusic@ietf.org>, "bfcpbis@ietf.org" <bfcpbis@ietf.org>, "draft-ietf-bfcpbis-rfc4583bis.all@ietf.org" <draft-ietf-bfcpbis-rfc4583bis.all@ietf.org>, "draft-ietf-mmusic-sdp-mux-attributes@ietf.org" <draft-ietf-mmusic-sdp-mux-attributes@ietf.org>, The IESG <iesg@ietf.org>
Thread-Topic: Use of the "TBD" Mux Category in bfcpbis.
Thread-Index: AQHUa7fTCN0f+vZll0yyj+gMy5T53qUusaGQ
Date: Wed, 24 Oct 2018 18:08:15 +0000
Message-ID: <B99C9CC6-89F5-4896-90C2-2AA2B8C28A56@cisco.com>
References: <6EA38BB6-27E3-44B0-8F04-7EF8C5857BF5@nostrum.com>
In-Reply-To: <6EA38BB6-27E3-44B0-8F04-7EF8C5857BF5@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Outbound-SMTP-Client: 173.36.7.19, xch-aln-009.cisco.com
X-Outbound-Node: alln-core-11.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/bfcpbis/6MNAwTGlmM-E3w2Mv-ToAIJTQR8>
Subject: Re: [bfcpbis] Use of the "TBD" Mux Category in bfcpbis.
X-BeenThere: bfcpbis@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: BFCPBIS working group discussion list <bfcpbis.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bfcpbis>, <mailto:bfcpbis-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bfcpbis/>
List-Post: <mailto:bfcpbis@ietf.org>
List-Help: <mailto:bfcpbis-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bfcpbis>, <mailto:bfcpbis-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Oct 2018 18:08:22 -0000

Hi Ben

 The mmusic WG agreed  to freeze further categorizations inside mux draft and that any new draft has to define the categories for the attributes they define. In this case the bis draft needs to define the needed categories and update IANA.
The procedures for the same as defined in Mux draft as well

Thanks
Suhas
Sent from my iPhone

> On Oct 24, 2018, at 9:37 AM, Ben Campbell <ben@nostrum.com> wrote:
> 
> Hi,
> 
> I’d like to get the opinions of MMUSIC participants on the use of the “TBD” mux category.
> 
> draft-ietf-bfcpbis-rfc4583bis ( in IESG evaluation) defines a new SDP attribute “bfcpver”. Since it’s associated with bfcp, which does not specify mux/demux procedures, the draft gives it a mux-category of “TBD”. Is that the right choice? If not, what is?
> 
> draft-ietf-mmusic-sdp-mux-attributes describes TBD as follows:
> 
>>   The attributes in the TBD category have not been analyzed under the
>>   proposed multiplexing framework and SHOULD NOT be multiplexed.
> 
> However, mux-attributes goes on to use TBD for several attributes, including one for bfcp, with notes to the effect of the following:
> 
>>   NOTE: As per section 9 of [I-D.ietf-mmusic-sdp-bundle-negotiation
>> ],
>>   there exists no publicly available specification that defines
>>   procedures for multiplexing/demultiplexing BFCP streams over a single
>>   5-tuple.  Once such a specification is available, the multiplexing
>>   categories assignments for the attributes in this section could be
>>   revisited.
> 
> That doesn’t really fit the definition. It seems more like the attributes _have_ been analyzed, and the note states the conclusion.
> 
> This is further complicated by the fact that  the only change 4566bis allows to an existing mux-category registration is to move from “TBD” to something else. Any other choice will make life harder if we later update bfcp with mux/demux procedures.
> 
> I am not (yet) suggesting a change to mux-attributes or 4566bis; I’m just trying to figure out the right way to specify mux-categories for new attributes.
> 
> Thanks!
> 
> Ben.
> 
> 
> 
>