From nobody Mon Aug 1 08:25:34 2016 Return-Path: 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 BCDBE12DC53 for ; Mon, 1 Aug 2016 08:25:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.488 X-Spam-Level: X-Spam-Status: No, score=-5.488 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 cH_QCQD9MLIl for ; Mon, 1 Aug 2016 08:25:32 -0700 (PDT) Received: from alum-mailsec-scanner-6.mit.edu (alum-mailsec-scanner-6.mit.edu [18.7.68.18]) by ietfa.amsl.com (Postfix) with ESMTP id 20D5D12DC42 for ; Mon, 1 Aug 2016 08:25:32 -0700 (PDT) X-AuditID: 12074412-1afff70000000931-b8-579f69ea0083 Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) by (Symantec Messaging Gateway) with SMTP id 6A.DE.02353.AE96F975; Mon, 1 Aug 2016 11:25:31 -0400 (EDT) Received: from Paul-Kyzivats-MacBook-Pro.local (c-73-218-51-154.hsd1.ma.comcast.net [73.218.51.154]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id u71FPT83031885 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Mon, 1 Aug 2016 11:25:30 -0400 To: mmusic@ietf.org References: From: Paul Kyzivat Message-ID: Date: Mon, 1 Aug 2016 11:25:28 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJIsWRmVeSWpSXmKPExsUixO6iqPs6c364wY1jshZTlz9mcWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxvIL89gLZspVPFk3i62B8YpEFyMnh4SAicTZwzNZuxi5OIQE tjJKbN+6lAXC+cUk8aGnjwWkSljAUeL/6w/sILaIgLDEjLd/2UBsIQFbiefnX7OC2GwCWhJz Dv0Hq+cVsJdY/GUKcxcjBweLgIrEu3tZIGFRgTSJ6Yf7GSFKBCVOznzCAlLCKWAnMW2fNkiY GWjinbm7mSFseYnmrbOZJzDyzULSMQtJ2SwkZQsYmVcxyiXmlObq5iZm5hSnJusWJyfm5aUW 6Zrp5WaW6KWmlG5ihISY0A7G9SflDjEKcDAq8fByMM0LF2JNLCuuzD3EKMnBpCTK+1l2brgQ X1J+SmVGYnFGfFFpTmrxIUYJDmYlEd7zqfPDhXhTEiurUovyYVLSHCxK4rw/F6v7CQmkJ5ak ZqemFqQWwWRlODiUJHhDgLEkJFiUmp5akZaZU4KQZuLgBBnOAzTcDaSGt7ggMbc4Mx0if4pR UUqcd0oGUEIAJJFRmgfXC0sBrxjFgV4R5rUGqeIBpg+47ldAg5mABifazwEZXJKIkJJqYJRc +U9Y9U7VftFMoyfmXVcZj93SZpbX5kuNZP+Yf+rH1wSOLcdmXJSdfqXzTUzfj08nGvWZOm1N fh98pu6zPzRY6s8Kvun8k3kcux4ddH1b0XVyp471gS/cK4ycjnpMXiMztenTkd1r/JldNh1c 1LHp97EVbS1HDF/+jpeY8eRn0YlNJg+M1hcqsRRnJBpqMRcVJwIAyghnntwCAAA= Archived-At: Subject: Re: [MMUSIC] Media type "image" is missing in rfc4566bis X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2016 15:25:34 -0000 This sort of problem seems to come up often with documents that establish IANA registries, and the successors to such documents. Initially, the "founding" document contains definitions of all the possible values. People get lazy, and assume that they don't need to look at the registry for the complete list. Later, when a bis document is created, it isn't clear how best to carry on. The registry contains references to the old (about to be obsolete) document for the original values. You want to ensure that the registry is revised to refer to the bis document for the values that were defined in its ancestor. But should the bis also be updated to mention all the then-defined values in the registry? I don't think that is necessary. It will simply encourage people to assume (wrongly) that the bis is authoritative. I suggest we just change the language in this section: OLD: is the media type. Currently defined media are "audio", "video", "text", "application", and "message", although this list may be extended in the future (see Section 8). NEW: is the media type. This document defines the values "audio", "video", "text", "application", and "message". This list may be extended in the future (see Section 8). Thanks, Paul On 7/30/16 2:18 AM, Gunnar Hellström wrote: > I noted a small issue in rfc4566bis: > > In section 5.14 of draft-ietf-mmusic-rfc4566bis-17, a paragraph defining > media says: > > -----------------current text in 5.14------------------------------------ > > is the media type. Currently defined media are "audio", "video", > "text", "application", and "message", although this list may be extended > in the future (see Section 8). > > ------------------------------------------------------------------------------- > > The "image" media is also defined and should be included in this list. > It was registered by RFC 6466. > > So, the paragraph should read: > > --------------proposed modified text for 5.14------------------------------ > > is the media type. Currently defined media are "audio", "video", > "text", "application", "message", and "image", although this list may be > extended in the future (see Section 8). > > -------------end of change > 1------------------------------------------------------------------- > > It should also be considered if the fact that "image" is a defined media > type should be reflected in section 8.2.1, where it is currently said: " > > --------------------------current text in > 8.2.1------------------------------------------- > > This memo registers the media types "audio", "video", "text", > "application", and "message". > ----------------------------------------------------------- > > The action in section 8.2.1 depends on what the plans are for IANA register of rfc4566bis values, but somehow "image" should be mentioned also in section 8.2.1. If the registration of the other media types for sdp are still regarded as registered by RFC 4566, the sentence is proposed to read: > > ------------------------Proposed replacement---------------------- > Registered media types at the publication of this memo are "audio", "video", "text", "application", "message", and "image". > -----------------end of change 2------------------------------------------------- > > (while if registration of the basic set of media will be regarded to be moved to have been made by rfc4566bis, then another wording is needed.) > > Regards > Gunnar > > -- > ----------------------------------------- > Gunnar Hellström > Omnitor > gunnar.hellstrom@omnitor.se > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From nobody Mon Aug 1 13:42:06 2016 Return-Path: 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 F2F7312D89E for ; Mon, 1 Aug 2016 13:42:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 00kJWG6dfLaS for ; Mon, 1 Aug 2016 13:42:03 -0700 (PDT) Received: from bin-vsp-out-02.atm.binero.net (vsp-unauthed02.binero.net [195.74.38.227]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C45312B01D for ; Mon, 1 Aug 2016 13:42:02 -0700 (PDT) X-Halon-ID: 62a81072-5828-11e6-b8a7-005056917f90 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.136] (unknown [85.238.221.179]) by bin-vsp-out-02.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Mon, 1 Aug 2016 22:41:55 +0200 (CEST) To: Paul Kyzivat , mmusic@ietf.org References: From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: Date: Mon, 1 Aug 2016 22:41:47 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [MMUSIC] Media type "image" is missing in rfc4566bis X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2016 20:42:06 -0000 Den 2016-08-01 kl. 17:25, skrev Paul Kyzivat: > This sort of problem seems to come up often with documents that > establish IANA registries, and the successors to such documents. > > Initially, the "founding" document contains definitions of all the > possible values. People get lazy, and assume that they don't need to > look at the registry for the complete list. > > Later, when a bis document is created, it isn't clear how best to > carry on. The registry contains references to the old (about to be > obsolete) document for the original values. You want to ensure that > the registry is revised to refer to the bis document for the values > that were defined in its ancestor. But should the bis also be updated > to mention all the then-defined values in the registry? I don't think > that is necessary. It will simply encourage people to assume (wrongly) > that the bis is authoritative. > > I suggest we just change the language in this section: > > OLD: > > is the media type. Currently defined media are "audio", > "video", "text", "application", and "message", although this list > may be extended in the future (see Section 8). > > NEW: > > is the media type. This document defines the values > "audio", "video", "text", "application", and "message". This list > may be extended in the future (see Section 8). GH: Yes, makes sense, except that the list is already extended by "image". I suggest the last sentence to read: "This list is extended and may be further extended by other memos registering media types in the future (see Section 8). The list of media types also occur in the syntax chapter preceded by "typically". Please propose a solution for that as well. Maybe just keep as is. > > Thanks, > Paul > > On 7/30/16 2:18 AM, Gunnar Hellström wrote: >> I noted a small issue in rfc4566bis: >> >> In section 5.14 of draft-ietf-mmusic-rfc4566bis-17, a paragraph defining >> media says: >> >> -----------------current text in >> 5.14------------------------------------ >> >> is the media type. Currently defined media are "audio", "video", >> "text", "application", and "message", although this list may be extended >> in the future (see Section 8). >> >> ------------------------------------------------------------------------------- >> >> >> The "image" media is also defined and should be included in this list. >> It was registered by RFC 6466. >> >> So, the paragraph should read: >> >> --------------proposed modified text for >> 5.14------------------------------ >> >> is the media type. Currently defined media are "audio", "video", >> "text", "application", "message", and "image", although this list may be >> extended in the future (see Section 8). >> >> -------------end of change >> 1------------------------------------------------------------------- >> >> It should also be considered if the fact that "image" is a defined media >> type should be reflected in section 8.2.1, where it is currently >> said: " >> >> --------------------------current text in >> 8.2.1------------------------------------------- >> >> This memo registers the media types "audio", "video", "text", >> "application", and "message". >> ----------------------------------------------------------- >> >> The action in section 8.2.1 depends on what the plans are for IANA >> register of rfc4566bis values, but somehow "image" should be >> mentioned also in section 8.2.1. If the registration of the other >> media types for sdp are still regarded as registered by RFC 4566, the >> sentence is proposed to read: >> >> ------------------------Proposed replacement---------------------- >> Registered media types at the publication of this memo are "audio", >> "video", "text", "application", "message", and "image". >> -----------------end of change >> 2------------------------------------------------- >> >> (while if registration of the basic set of media will be regarded to >> be moved to have been made by rfc4566bis, then another wording is >> needed.) >> >> Regards >> Gunnar >> >> -- >> ----------------------------------------- >> Gunnar Hellström >> Omnitor >> gunnar.hellstrom@omnitor.se >> >> >> >> _______________________________________________ >> 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 -- ----------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se From nobody Mon Aug 1 14:58:46 2016 Return-Path: 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 5A43312D1A6 for ; Mon, 1 Aug 2016 14:58:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no 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 8zYId0vMA57j for ; Mon, 1 Aug 2016 14:58:43 -0700 (PDT) Received: from resqmta-ch2-05v.sys.comcast.net (resqmta-ch2-05v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0055912D73E for ; Mon, 1 Aug 2016 14:58:42 -0700 (PDT) Received: from resomta-ch2-13v.sys.comcast.net ([69.252.207.109]) by resqmta-ch2-05v.sys.comcast.net with SMTP id ULDubI0732FGMULEQbhWuZ; Mon, 01 Aug 2016 21:58:42 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by comcast with SMTP id ULEObDhTSDgDkULEPbKfWj; Mon, 01 Aug 2016 21:58:41 +0000 To: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= , mmusic@ietf.org References: From: Paul Kyzivat Message-ID: Date: Mon, 1 Aug 2016 17:58:39 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfG235GYGkuLX+1ZY8Z2ClsSAROpR/wXmXGqsIxFaqHMLhp7n0NCTWEkUGgbtEFzMrZDR+O3AdUDtehjllDSfzIDhstDvGplujNU6aksFdADs1Rmwa9Hx DVuc6drbOFIDQ+v+/05BwNTUeINNLyoGPjFxfrbP3p6jfayLADvXUkd48iANy5qjNbvZ9xSw/Nv5SFvVXvwsl495ljx59n1VUSO7fgW7W8XB+mIjG2ICrXFq Archived-At: Subject: Re: [MMUSIC] Media type "image" is missing in rfc4566bis X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2016 21:58:44 -0000 Lets see if the approach is acceptable, and then fine tune the language. Thanks, Paul On 8/1/16 4:41 PM, Gunnar Hellström wrote: > Den 2016-08-01 kl. 17:25, skrev Paul Kyzivat: >> This sort of problem seems to come up often with documents that >> establish IANA registries, and the successors to such documents. >> >> Initially, the "founding" document contains definitions of all the >> possible values. People get lazy, and assume that they don't need to >> look at the registry for the complete list. >> >> Later, when a bis document is created, it isn't clear how best to >> carry on. The registry contains references to the old (about to be >> obsolete) document for the original values. You want to ensure that >> the registry is revised to refer to the bis document for the values >> that were defined in its ancestor. But should the bis also be updated >> to mention all the then-defined values in the registry? I don't think >> that is necessary. It will simply encourage people to assume (wrongly) >> that the bis is authoritative. >> >> I suggest we just change the language in this section: >> >> OLD: >> >> is the media type. Currently defined media are "audio", >> "video", "text", "application", and "message", although this list >> may be extended in the future (see Section 8). >> >> NEW: >> >> is the media type. This document defines the values >> "audio", "video", "text", "application", and "message". This list >> may be extended in the future (see Section 8). > GH: Yes, makes sense, except that the list is already extended by > "image". I suggest the last sentence to read: > > "This list is extended and may be further extended by other memos > registering media types in the future (see Section 8). > > The list of media types also occur in the syntax chapter preceded by > "typically". Please propose a solution for that as well. Maybe just keep > as is. >> >> Thanks, >> Paul >> >> On 7/30/16 2:18 AM, Gunnar Hellström wrote: >>> I noted a small issue in rfc4566bis: >>> >>> In section 5.14 of draft-ietf-mmusic-rfc4566bis-17, a paragraph defining >>> media says: >>> >>> -----------------current text in >>> 5.14------------------------------------ >>> >>> is the media type. Currently defined media are "audio", "video", >>> "text", "application", and "message", although this list may be extended >>> in the future (see Section 8). >>> >>> ------------------------------------------------------------------------------- >>> >>> >>> The "image" media is also defined and should be included in this list. >>> It was registered by RFC 6466. >>> >>> So, the paragraph should read: >>> >>> --------------proposed modified text for >>> 5.14------------------------------ >>> >>> is the media type. Currently defined media are "audio", "video", >>> "text", "application", "message", and "image", although this list may be >>> extended in the future (see Section 8). >>> >>> -------------end of change >>> 1------------------------------------------------------------------- >>> >>> It should also be considered if the fact that "image" is a defined media >>> type should be reflected in section 8.2.1, where it is currently >>> said: " >>> >>> --------------------------current text in >>> 8.2.1------------------------------------------- >>> >>> This memo registers the media types "audio", "video", "text", >>> "application", and "message". >>> ----------------------------------------------------------- >>> >>> The action in section 8.2.1 depends on what the plans are for IANA >>> register of rfc4566bis values, but somehow "image" should be >>> mentioned also in section 8.2.1. If the registration of the other >>> media types for sdp are still regarded as registered by RFC 4566, the >>> sentence is proposed to read: >>> >>> ------------------------Proposed replacement---------------------- >>> Registered media types at the publication of this memo are "audio", >>> "video", "text", "application", "message", and "image". >>> -----------------end of change >>> 2------------------------------------------------- >>> >>> (while if registration of the basic set of media will be regarded to >>> be moved to have been made by rfc4566bis, then another wording is >>> needed.) >>> >>> Regards >>> Gunnar >>> >>> -- >>> ----------------------------------------- >>> Gunnar Hellström >>> Omnitor >>> gunnar.hellstrom@omnitor.se >>> >>> >>> >>> _______________________________________________ >>> 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 > From nobody Wed Aug 3 05:43:03 2016 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5676712DB5C; Wed, 3 Aug 2016 05:43:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alexey Melnikov" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160803124301.10977.52483.idtracker@ietfa.amsl.com> Date: Wed, 03 Aug 2016 05:43:01 -0700 Archived-At: Cc: fandreas@cisco.com, mmusic-chairs@ietf.org, draft-ietf-mmusic-mux-exclusive@ietf.org, mmusic@ietf.org Subject: [MMUSIC] Alexey Melnikov's No Objection on draft-ietf-mmusic-mux-exclusive-09: (with COMMENT) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2016 12:43:01 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-mmusic-mux-exclusive-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-mmusic-mux-exclusive/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- In Section 3: The mux category [I-D.ietf-mmusic-sdp-mux-attributes] for the 'rtcp- mux-only' attribute is 'IDENTICAL', which means that the attribute, if used within a BUNDLE group [I-D.ietf-mmusic-sdp-bundle-negotiation], must be associated with all multiplexed RTP-based media descriptions within the BUNDLE group. This sounds pretty normative, so I think the following 2 references should be Normative: [I-D.ietf-mmusic-sdp-mux-attributes] Nandakumar, S., "A Framework for SDP Attributes when Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-12 (work in progress), January 2016. [I-D.ietf-mmusic-sdp-bundle-negotiation] Holmberg, C., Alvestrand, H., and C. Jennings, "Negotiating Media Multiplexing Using the Session Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- negotiation-31 (work in progress), June 2016. From nobody Wed Aug 3 09:08:01 2016 Return-Path: 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 81DF412D16C; Wed, 3 Aug 2016 09:07:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 OP-5T_UejiSY; Wed, 3 Aug 2016 09:07:51 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5808D12D781; Wed, 3 Aug 2016 09:04:36 -0700 (PDT) X-AuditID: c1b4fb30-ea88e980000009f9-30-57a21612d46f Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.183.84]) by (Symantec Mail Security) with SMTP id 74.E9.02553.21612A75; Wed, 3 Aug 2016 18:04:34 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.142]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0301.000; Wed, 3 Aug 2016 18:04:33 +0200 From: Christer Holmberg To: Alexey Melnikov , The IESG Thread-Topic: Alexey Melnikov's No Objection on draft-ietf-mmusic-mux-exclusive-09: (with COMMENT) Thread-Index: AQHR7YST4yumesWySUaHAUUy+iP9+KA3ZmmG Date: Wed, 3 Aug 2016 16:04:32 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4771795C@ESESSMB209.ericsson.se> References: <20160803124301.10977.52483.idtracker@ietfa.amsl.com> In-Reply-To: <20160803124301.10977.52483.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B4771795CESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrAIsWRmVeSWpSXmKPExsUyM2J7iK6Q2KJwg22r1S32vz/EZHF56ylW i/cXdC1m/JnIbHF+53omi6nLH7M4sHlM+b2R1WPnqQNsHkuW/GQKYI7isklJzcksSy3St0vg ypj68ztjQYdtxfknJ1gaGK+adjFyckgImEi8WryFvYuRi0NIYD2jxOUXO6CcxYwSu+/NA3I4 ONgELCS6/2mDmCICbhIPrzuClDAL9DJJTJu0kx1kkLBAssSE7dtZQGwRgRSJp7+nskHYRhJt X3aB1bAIqEhsnnSTEcTmFfCV+H/hDxOILSTgKDHz2W2wek4BJ4m2dU/B6hkFxCS+n1oDVsMs IC7R9GUlK8TRAhJL9pxnhrBFJV4+/scKUZMvsWHeFWaI+YISJ2c+YZnAKDwLSfssJGWzkJRB xA0kvry/DWVrSyxb+JoZwtaX6H5/mglZfAEj+ypG0eLU4qTcdCMjvdSizOTi4vw8vbzUkk2M wHg7uOW3wQ7Gl88dDzEKcDAq8fAuuL8gXIg1say4MvcQowQHs5IIb6DIonAh3pTEyqrUovz4 otKc1OJDjNIcLErivP4vFcOFBNITS1KzU1MLUotgskwcnFINjAl500OqtTfq711itNNbJUR6 /qKWfepemc7udYklEkopQo++3Gz8r3OLl3//rTe1CRJPmdJUZaUZTGavlGX+KcH24anHjSsH Nv3vY7aU1bGaYRLrvYF/4+XMRX++63v4z3XqfGL7euob59BcHuWSdvUrs4x6Ohm/MCyTdhdw DXKOzOS2zo5XYinOSDTUYi4qTgQARH/6KLMCAAA= Archived-At: Cc: "fandreas@cisco.com" , "mmusic-chairs@ietf.org" , "draft-ietf-mmusic-mux-exclusive@ietf.org" , "mmusic@ietf.org" Subject: Re: [MMUSIC] Alexey Melnikov's No Objection on draft-ietf-mmusic-mux-exclusive-09: (with COMMENT) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2016 16:07:55 -0000 --_000_7594FB04B1934943A5C02806D1A2204B4771795CESESSMB209erics_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Hi Alexey, I can make the references normative. Note, however, that an endpoint suppor= ting the draft is NOT required to support the 2 referenced documents. Regards, Christer Sent from my Windows Phone ________________________________ From: Alexey Melnikov Sent: =FD03/=FD08/=FD2016 15:43 To: The IESG Cc: draft-ietf-mmusic-mux-exclusive@ietf.org; Flemming Andreasen; mmusic-c= hairs@ietf.org; fandreas@cisco.com; mmusic@ietf.org Subject: Alexey Melnikov's No Objection on draft-ietf-mmusic-mux-exclusive-= 09: (with COMMENT) Alexey Melnikov has entered the following ballot position for draft-ietf-mmusic-mux-exclusive-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-mmusic-mux-exclusive/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- In Section 3: The mux category [I-D.ietf-mmusic-sdp-mux-attributes] for the 'rtcp- mux-only' attribute is 'IDENTICAL', which means that the attribute, if used within a BUNDLE group [I-D.ietf-mmusic-sdp-bundle-negotiation], must be associated with all multiplexed RTP-based media descriptions within the BUNDLE group. This sounds pretty normative, so I think the following 2 references should be Normative: [I-D.ietf-mmusic-sdp-mux-attributes] Nandakumar, S., "A Framework for SDP Attributes when Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-12 (work in progress), January 2016. [I-D.ietf-mmusic-sdp-bundle-negotiation] Holmberg, C., Alvestrand, H., and C. Jennings, "Negotiating Media Multiplexing Using the Session Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- negotiation-31 (work in progress), June 2016. --_000_7594FB04B1934943A5C02806D1A2204B4771795CESESSMB209erics_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
Hi Alexey,
I can make the references normative. Note, however, that an endpoint suppor= ting the draft is NOT required to support the 2 referenced documents.

Regards,

Christer

Sent from my Windows Phone
From: Alexey Melnikov
Sent: =FD03= /=FD08/=FD2016 15:43
To: The IESG
Cc: draft-ietf-mmusic-mu= x-exclusive@ietf.org; Flemming Andreasen; mmusic-chairs@ietf.org; fandreas@= cisco.com; mmusic@ietf.org
Subject: Alexe= y Melnikov's No Objection on draft-ietf-mmusic-mux-exclusive-09: (with COMM= ENT)

Alexey Melnikov has entered the following ballot p= osition for
draft-ietf-mmusic-mux-exclusive-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-mmusic-mux-exclusive/


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

In Section 3:

   The mux category [I-D.ietf-mmusic-sdp-mux-attributes] for the = 'rtcp-
   mux-only' attribute is 'IDENTICAL', which means that the attri= bute,
   if used within a BUNDLE group
   [I-D.ietf-mmusic-sdp-bundle-negotiation], must be associated w= ith all
   multiplexed RTP-based media descriptions within the BUNDLE gro= up.

This sounds pretty normative, so I think the following 2 references
should be Normative:

   [I-D.ietf-mmusic-sdp-mux-attributes]
            &nb= sp; Nandakumar, S., "A Framework for SDP Attributes when
            &nb= sp; Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-12
            &nb= sp; (work in progress), January 2016.

   [I-D.ietf-mmusic-sdp-bundle-negotiation]
            &nb= sp; Holmberg, C., Alvestrand, H., and C. Jennings,
            &nb= sp; "Negotiating Media Multiplexing Using the Session
            &nb= sp; Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle-
            &nb= sp; negotiation-31 (work in progress), June 2016.


 --_000_7594FB04B1934943A5C02806D1A2204B4771795CESESSMB209erics_-- From nobody Wed Aug 3 10:26:12 2016 Return-Path: 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 4773512D0FA; Wed, 3 Aug 2016 10:26:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastmail.fm header.b=Qz2IZpgR; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=OsbW9PjI 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 tJ0i5riFHBIe; Wed, 3 Aug 2016 10:25:52 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EE8312D0A6; Wed, 3 Aug 2016 10:25:52 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 56D422039F; Wed, 3 Aug 2016 13:25:49 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute6.internal (MEProxy); Wed, 03 Aug 2016 13:25:49 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=aBwIjRanO18ekF2s4U4IEwWTPgM=; b=Qz2IZp gRRwgRq1xcy1vNmgZ9dARI8r7QNLIroDsCCcPN4484EhJUnk9zjRp4tAdPt8Pwl/ qjmzeBAUHglIZ0bz+vP5DsXNR+ENziR8agBjIPcMnXwuiwG17xXIxEI2aNGwqGLK zy3OxHpXDcrZk/6f1DMK0UYb5n1SbJ+Kr0lyw= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=aBwIjRanO18ekF2 s4U4IEwWTPgM=; b=OsbW9PjI3WVv6zNSY5fEZ+pAu2jJYMmJmsqhIVnLM0gnbEe n0O8nvz/jby9BQNkYe/8eZvK4efUtoIDEPRnWGKlFAUD//IsxajKbcS89xJowEdj wDdVPsMkk7KL5nR6X0m0P3UNBJJxcoh+cOsT+1bchs1XG18kV0e+nJI02rSY= Received: by mailuser.nyi.internal (Postfix, from userid 99) id 20394A8531; Wed, 3 Aug 2016 13:25:49 -0400 (EDT) Message-Id: <1470245148.3431403.685086017.0C25AB0E@webmail.messagingengine.com> X-Sasl-Enc: wp+KtLwBCMn9l09gq5yBTiGPYSzFVwWpDZO1wStRh/1+ 1470245148 From: Alexey Melnikov To: Christer Holmberg , The IESG MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_147024514934314030"; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-25d422ed Date: Wed, 03 Aug 2016 18:25:48 +0100 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4771795C@ESESSMB209.ericsson.se> References: <20160803124301.10977.52483.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B4771795C@ESESSMB209.ericsson.se> Archived-At: Cc: Flemming Andreasen , mmusic-chairs@ietf.org, draft-ietf-mmusic-mux-exclusive@ietf.org, mmusic@ietf.org Subject: Re: [MMUSIC] Alexey Melnikov's No Objection on draft-ietf-mmusic-mux-exclusive-09: (with COMMENT) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2016 17:26:07 -0000 This is a multi-part message in MIME format. --_----------=_147024514934314030 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Hi Christer, On Wed, Aug 3, 2016, at 05:04 PM, Christer Holmberg wrote: > Hi Alexey, > > I can make the references normative. Note, however, that an endpoint > supporting the draft is NOT required to support the 2 referenced > documents. Whether they are required or not doesn't actually matter, as there are interactions between them. So if you would, I think it will be the right thing. > > Regards, > > Christer > > Sent from my Windows Phone > *From: *Alexey Melnikov[1] > *Sent: *=E2=80=8E03/=E2=80=8E08/=E2=80=8E2016 15:43 > *To: *The IESG[2] > *Cc: *draft-ietf-mmusic-mux-exclusive@ietf.org; Flemming Andreasen[3]; > mmusic-chairs@ietf.org; fandreas@cisco.com; mmusic@ietf.org > *Subject: *Alexey Melnikov's No Objection on draft-ietf-mmusic-mux-exclus= ive- > 09: (with COMMENT) > > > Alexey Melnikov has entered the following ballot position for draft-ietf-= mmusic-mux-exclusive- > 09: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut > this introductory paragraph, however.) > > > Please refer to > https://www.ietf.org/iesg/statement/discuss-criteria.html for more > information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-mmusic-mux-exclusive/ > > > > --------------------------------------------------------------- > ------- > COMMENT: > --------------------------------------------------------------- > ------- > > In Section 3: > > The mux category [I-D.ietf-mmusic-sdp-mux-attributes] for the 'rtcp- > mux-only' attribute is 'IDENTICAL', which means that the attribute, > if used within a BUNDLE group [I-D.ietf-mmusic-sdp-bundle- > negotiation], must be associated with all multiplexed RTP-based media > descriptions within the BUNDLE group. > > This sounds pretty normative, so I think the following 2 references > should be Normative: > > [I-D.ietf-mmusic-sdp-mux-attributes] Nandakumar, S., "A Framework for > SDP Attributes when Multiplexing", draft-ietf-mmusic-sdp-mux-attributes- > 12 (work in progress), January 2016. > > [I-D.ietf-mmusic-sdp-bundle-negotiation] Holmberg, C., Alvestrand, > H., and C. Jennings, "Negotiating Media Multiplexing Using the > Session Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- > negotiation-31 (work in progress), June 2016. > > Links: 1. mailto:aamelnikov@fastmail.fm 2. mailto:iesg@ietf.org 3. mailto:fandreas@cisco.com --_----------=_147024514934314030 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
Hi Christer,

On Wed, Aug 3, 2016, at 05:04 PM, Christer Holmberg wrote:
Hi Alexey,

I can make the references normative. Note, however, that an endpoint = supporting the draft is NOT required to support the 2 referenced documents.=

Whether they are required or not doesn't actually matter, as there are= interactions between them.

So if you would, I think it will be the right thing.

Regards,

Christer

Sent from my Windows Phone
Sent: =E2=80=8E03/=E2=80=8E08/=E2=80=8E2016 15:43
Subject: Alexey Melnikov's No Objection on draft-ietf-m= music-mux-exclusive-09: (with COMMENT)


Alexey Melnikov has entered the following ballot pos= ition for
draft-ietf-mmusic-mux-exclusive-09: No Objection

Whe= n responding, please keep the subject line intact and reply to all
emai= l addresses included in the To and CC lines. (Feel free to cut this
int= roductory paragraph, however.)


Please refer to https://www.ietf.o= rg/iesg/statement/discuss-criteria.html
for more information about = IESG DISCUSS and COMMENT positions.


The document, along with = other ballot positions, can be found here:
https://datatracker.ietf.= org/doc/draft-ietf-mmusic-mux-exclusive/



-----------= -----------------------------------------------------------
COMMENT: ----------------------------------------------------------------------
In Section 3:

The mux category [I-D.ietf-mmusic-sdp-mux-att= ributes] for the 'rtcp-
mux-only' attribute is 'IDENTICAL', which means= that the attribute,
if used within a BUNDLE group
[I-D.ietf-mmusic= -sdp-bundle-negotiation], must be associated with all
multiplexed RTP-b= ased media descriptions within the BUNDLE group.

This sounds prett= y normative, so I think the following 2 references
should be Normative:=

[I-D.ietf-mmusic-sdp-mux-attributes]
Nandakumar, S., "A Frame= work for SDP Attributes when
Multiplexing", draft-ietf-mmusic-sdp-mux-a= ttributes-12
(work in progress), January 2016.

[I-D.ietf-mmusi= c-sdp-bundle-negotiation]
Holmberg, C., Alvestrand, H., and C. Jennings= ,
"Negotiating Media Multiplexing Using the Session
Description Pro= tocol (SDP)", draft-ietf-mmusic-sdp-bundle-
negotiation-31 (work in pro= gress), June 2016.



--_----------=_147024514934314030-- From nobody Wed Aug 3 10:31:30 2016 Return-Path: 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 63C1912D0FA; Wed, 3 Aug 2016 10:31:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] autolearn=unavailable autolearn_force=no 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 2Cu4VSnJsA2L; Wed, 3 Aug 2016 10:31:23 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 556BB12D0B4; Wed, 3 Aug 2016 10:31:23 -0700 (PDT) Received: from [10.0.1.4] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u73HVC1U011653 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 3 Aug 2016 12:31:13 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.4] From: "Ben Campbell" To: "Alexey Melnikov" Date: Wed, 03 Aug 2016 12:31:12 -0500 Message-ID: <74D3DCB8-6DBF-4EF8-8EF0-80554D1E25EC@nostrum.com> In-Reply-To: <1470245148.3431403.685086017.0C25AB0E@webmail.messagingengine.com> References: <20160803124301.10977.52483.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B4771795C@ESESSMB209.ericsson.se> <1470245148.3431403.685086017.0C25AB0E@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: mmusic-chairs@ietf.org, mmusic@ietf.org, Flemming Andreasen , The IESG , Christer Holmberg , draft-ietf-mmusic-mux-exclusive@ietf.org Subject: Re: [MMUSIC] Alexey Melnikov's No Objection on draft-ietf-mmusic-mux-exclusive-09: (with COMMENT) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2016 17:31:25 -0000 On 3 Aug 2016, at 12:25, Alexey Melnikov wrote: > Hi Christer, > > On Wed, Aug 3, 2016, at 05:04 PM, Christer Holmberg wrote: >> Hi Alexey, >> >> I can make the references normative. Note, however, that an endpoint >> supporting the draft is NOT required to support the 2 referenced >> documents. > > Whether they are required or not doesn't actually matter, as there are > interactions between them. Hi Alexey: I'm not disagreeing--in fact it's very likely that I agree with you. But I'm not sure what you mean be "interactions between then", can you clarify? Thanks! Ben. > > So if you would, I think it will be the right thing. >> >> Regards, >> >> Christer >> >> Sent from my Windows Phone >> *From: *Alexey Melnikov[1] >> *Sent: *‎03/‎08/‎2016 15:43 >> *To: *The IESG[2] >> *Cc: *draft-ietf-mmusic-mux-exclusive@ietf.org; Flemming >> Andreasen[3]; >> mmusic-chairs@ietf.org; fandreas@cisco.com; mmusic@ietf.org >> *Subject: *Alexey Melnikov's No Objection on >> draft-ietf-mmusic-mux-exclusive- >> 09: (with COMMENT) >> >> >> Alexey Melnikov has entered the following ballot position for >> draft-ietf-mmusic-mux-exclusive- >> 09: No Objection >> >> When responding, please keep the subject line intact and reply to >> all >> email addresses included in the To and CC lines. (Feel free to cut >> this introductory paragraph, however.) >> >> >> Please refer to >> https://www.ietf.org/iesg/statement/discuss-criteria.html for more >> information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-mmusic-mux-exclusive/ >> >> >> >> --------------------------------------------------------------- >> ------- >> COMMENT: >> --------------------------------------------------------------- >> ------- >> >> In Section 3: >> >> The mux category [I-D.ietf-mmusic-sdp-mux-attributes] for the 'rtcp- >> mux-only' attribute is 'IDENTICAL', which means that the attribute, >> if used within a BUNDLE group [I-D.ietf-mmusic-sdp-bundle- >> negotiation], must be associated with all multiplexed RTP-based >> media >> descriptions within the BUNDLE group. >> >> This sounds pretty normative, so I think the following 2 references >> should be Normative: >> >> [I-D.ietf-mmusic-sdp-mux-attributes] Nandakumar, S., "A Framework >> for >> SDP Attributes when Multiplexing", >> draft-ietf-mmusic-sdp-mux-attributes- >> 12 (work in progress), January 2016. >> >> [I-D.ietf-mmusic-sdp-bundle-negotiation] Holmberg, C., Alvestrand, >> H., and C. Jennings, "Negotiating Media Multiplexing Using the >> Session Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- >> negotiation-31 (work in progress), June 2016. >> >> > > > Links: > > 1. mailto:aamelnikov@fastmail.fm > 2. mailto:iesg@ietf.org > 3. mailto:fandreas@cisco.com From nobody Thu Aug 4 08:19:39 2016 Return-Path: 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 C978C12D5F6; Thu, 4 Aug 2016 08:19:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 rn68mCvVuI8S; Thu, 4 Aug 2016 08:19:35 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E604A12D596; Thu, 4 Aug 2016 08:19:34 -0700 (PDT) X-AuditID: c1b4fb2d-fa6bb98000000190-5f-57a35d0405d2 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.183.84]) by (Symantec Mail Security) with SMTP id BD.2B.00400.40D53A75; Thu, 4 Aug 2016 17:19:33 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.142]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0301.000; Thu, 4 Aug 2016 17:19:31 +0200 From: Christer Holmberg To: Christer Holmberg , "Mirja Kuehlewind (IETF)" Thread-Topic: =?utf-8?B?TWlyamEgS8O8aGxld2luZCdzIE5vIE9iamVjdGlvbiBvbiBkcmFmdC1pZXRm?= =?utf-8?Q?-mmusic-mux-exclusive-09:_(with_COMMENT)?= Thread-Index: AQHR5oXUdmY3ZrAWz0ucUbQzbONunKAqrPng///sYQCAAfPZAIAMbEZQ Date: Thu, 4 Aug 2016 15:19:30 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4771F880@ESESSMB209.ericsson.se> References: <20160725150421.11530.97108.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B476E65EC@ESESSMB209.ericsson.se> <8FD87D38-D416-4A10-90E1-C156D4FB8E5D@kuehlewind.net> <7594FB04B1934943A5C02806D1A2204B476E8526@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B476E8526@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprCIsWRmVeSWpSXmKPExsUyM2J7iC5r7OJwg2+NjBaXt55itXh/Qddi xp+JzBYvrn9ktji/cz2TxdTlj1kc2Dym/N7I6rFkyU8mj5aPC1kDmKO4bFJSczLLUov07RK4 MpY3dbIVbFCouHP/HHMD4xH5LkZODgkBE4n+h/dZuxi5OIQE1jNKHHrcyQbhLGaU2HB+FlMX IwcHm4CFRPc/bZAGEYFMiScz94E1MAv8Y5S4NukGmCMs0MMocff9EzBHRKCXUeLMyj5GiBY3 iYnf1jCB2CwCKhKT2leygUzlFfCVeHNBBiQsJNDIJLF0fiiIzSngJ7Hu+wdmEJtRQEzi+ymI VmYBcYlbT+YzQZwtILFkz3lmCFtU4uXjf6wQtpLEiu2XGEHGMwtoSqzfpQ/RqigxpfshO4jN KyAocXLmE5YJjKKzkEydhdAxC0nHLCQdCxhZVjGKFqcWF+emGxnrpRZlJhcX5+fp5aWWbGIE xtXBLb91dzCufu14iFGAg1GJh1fBcFG4EGtiWXFl7iFGCQ5mJRHeKZGLw4V4UxIrq1KL8uOL SnNSiw8xSnOwKInz+r9UDBcSSE8sSc1OTS1ILYLJMnFwSjUwLlIWmRe4rndmWaa74r9Vzofu Mzr5i7Rkv74ruyZlwaXpsZc13tapL7x3Yub8v17/qq6/WzL1gNkd7tMipdqzJBZul+Xi1Wq1 n79G7NxEpXxBa98lwh3BHpcmCi9piLtdXOLvmrNhl8PGf5WK7Q0G3pOfHeJsPmmv3L3lNWs7 J9NvvrXTG+exKbEUZyQaajEXFScCAG0OGxynAgAA Archived-At: Cc: "fandreas@cisco.com" , "mmusic-chairs@ietf.org" , "mmusic@ietf.org" , The IESG , "draft-ietf-mmusic-mux-exclusive@ietf.org" Subject: Re: [MMUSIC] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-mmusic-mux-exclusive-09=3A_=28with_COMMENT=29?= X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2016 15:19:39 -0000 SGkgTWlyamEsDQoNCkkgc3VnZ2VzdCB0aGUgZm9sbG93aW5nIG1vZGlmaWVkIHRleHQgb2YgdGhl IEludHJvZHVjdGlvbi8zcmQgcGFyYWdyYXBoOg0KDQogICAiU29tZSBuZXdlciBhcHBsaWNhdGlv bnMgdGhhdCBkbyBub3QgcmVxdWlyZSBiYWNrd2FyZCBjb21wYXRpYmlsaXR5DQogICB3aXRoIHBl ZXJzIHRoYXQgY2Fubm90IG11bHRpcGxleCBSVENQIG1pZ2h0IGNob29zZSB0byBub3QgaW1wbGVt ZW50DQogICBzZXBhcmF0aW9uIG9mIFJUUCBhbmQgUlRDUC4gIEV4YW1wbGVzIG9mIHN1Y2ggYXBw bGljYXRpb25zIGFyZSBXM0MNCiAgIFdFQlJUQyBbVzNDLldELXdlYnJ0Yy0yMDEyMDIwOV0gYXBw bGljYXRpb25zLCB0aGF0IGFyZSBub3QgcmVxdWlyZWQNCiAgIHRvIGludGVyb3BlcmF0ZSB3aXRo IG5vbi1XRUJSVEMgY2xpZW50cy4gIEZvciBzdWNoIGFwcGxpY2F0aW9ucywgdGhpcw0KICAgZG9j dW1lbnQgZGVmaW5lcyBhbiBTRFAgYXR0cmlidXRlIHRvIHNpZ25hbCBpbnRlbnQgdG8gcmVxdWly ZQ0KICAgbXVsdGlwbGV4aW5nLiAgVGhlIHVzZSBvZiB0aGlzIGF0dHJpYnV0ZSBpbiBTRFAgb2Zm ZXJzIFtSRkMzMjY0XSBieQ0KICAgZW50aXRpZXMgdGhhdCBldmVyIG5lZWQgdG8gaW50ZXJvcGVy YXRlIHdpdGggcGVlcnMgdGhhdCBkbyBub3QNCiAgIHN1cHBvcnQgUlRDL1JUQ1AgbXVsdGlwbGV4 aW5nIG1heSBoYXJtIGludGVyb3BlcmFiaWxpdHkuICBBbHNvLCB3aGlsZQ0KICAgdGhlIFNEUCBh bnN3ZXJlciBbUkZDMzI2NF0gbWlnaHQgc3VwcG9ydCwgYW5kIHByZWZlciB1c2FnZSBvZiwNCiAg IGZhbGxiYWNrIHRvIG5vbi1tdWx0aXBsZXgsIHRoZSBhdHRyaWJ1dGUgaW5kaWNhdGVzIHRoYXQg ZmFsbGJhY2sgdG8NCiAgIG5vbi1tdWx0aXBsZXggY2Fubm90IGJlIGVuYWJsZWQuICBPbmUgZXhh bXBsZSBvZiB3aGVyZSBub24tbXVsdGlwbGV4DQogICBpcyBwcmVmZXJyZWQgaXMgd2hlcmUgYW4g ZW5kcG9pbnQgaXMgY29ubmVjdGVkIHRvIGEgcmFkaW8gaW50ZXJmYWNlLA0KICAgYW5kIHdhbnRz IHRvIHVzZSBkaWZmZXJlbnQgYmVhcmVycyAocG9zc2libHkgd2l0aCBkaWZmZXJlbnQgcXVhbGl0 eQ0KICAgY2hhcmFjdGVyaXN0aWNzKSBmb3IgUlRQIGFuZCBSVENQLiAgQW5vdGhlciBleGFtcGxl IGlzIHdoZXJlIHRoZSBvbmUNCiAgIGVuZHBvaW50IGlzIGFjdGluZyBhcyBhIGdhdGV3YXkgdG8g YSBuZXR3b3JrIHdoZXJlIFJUUC9SVENQDQogICBtdWx0aXBsZXhpbmcgY2Fubm90IGJlIHVzZWQu ICBJbiBzdWNoIGNhc2UgdGhlcmUgZW5kcG9pbnQgbWF5IHByZWZlcg0KICAgbm9uLW11bHRpcGxl eGluZyBhbHNvIHRvd2FyZHMgdGhlIG90aGVyIG5ldHdvcmsuICBPdGhlcndpc2UgdGhlDQogICBl bmRwb2ludCB3b3VsZCBoYXZlIHRvIHBlcmZvcm0gZGUtbXVsdGlwbGV4aW5nIG9mIFJUUCBhbmQg UlRDUC4iDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQpGcm9tOiBDaHJpc3RlciBIb2xtYmVyZyBbbWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVy aWNzc29uLmNvbV0gDQpTZW50OiAyNyBKdWx5IDIwMTYgMjA6MzcNClRvOiBNaXJqYSBLdWVobGV3 aW5kIChJRVRGKSA8aWV0ZkBrdWVobGV3aW5kLm5ldD4NCkNjOiBUaGUgSUVTRyA8aWVzZ0BpZXRm Lm9yZz47IGZhbmRyZWFzQGNpc2NvLmNvbTsgbW11c2ljLWNoYWlyc0BpZXRmLm9yZzsgZHJhZnQt aWV0Zi1tbXVzaWMtbXV4LWV4Y2x1c2l2ZUBpZXRmLm9yZzsgbW11c2ljQGlldGYub3JnDQpTdWJq ZWN0OiBSRTogTWlyamEgS8O8aGxld2luZCdzIE5vIE9iamVjdGlvbiBvbiBkcmFmdC1pZXRmLW1t dXNpYy1tdXgtZXhjbHVzaXZlLTA5OiAod2l0aCBDT01NRU5UKQ0KDQpIaSBNaXJqYSwNCg0KLi4u DQoNCj4+IFRoZXJlIGFyZSBuZXdlciBzeXN0ZW1zIHRoYXQgT05MWSBzdXBwb3J0IFJUUC9SVENQ IG11bHRpcGxleGluZyAtIA0KPj4gd2l0aG91dCBiZWluZyBhYmxlIHRvIGZhbGwgYmFjayB0byBu b24tbXV4LiBIb3dldmVyLCB0aGUgZXhpc3RpbmcgU0RQIA0KPj4gYXR0cmlidXRlIHRvIGluZGlj YXRlIHN1cHBvcnQgb2YgUlRQL1JUQ1AgbXVsdGlwbGV4aW5nIG1hbmRhdGVzIHRoZSBzZW5kZXIg dG8gYmUgYWJsZSB0byBmYWxsIGJhY2sgdG8gbm9uLW11eC4NCj4+IFRoZSBuZXcgU0RQIGF0dHJp YnV0ZSBpcyB1c2VkIHRvIGluZGljYXRlIHRoYXQgeW91IGNhbiBkbyBSVFAvUlRDUCBtdWx0aXBs ZXhpbmcgT05MWS4NCj4+IA0KPj4gT25lIHJlYXNvbiB3aHkgdGhlIHJlY2VpdmVyIG1heSBzdXBw b3J0IG11eCwgYnV0IHByZWZlcnMgdG8gZG8gDQo+PiBub24tbXV4IGlzIGJlY2F1c2UgaXQgaXMg Y29ubmVjdGVkIHRvIGEgcmFkaW8gaW50ZXJmYWNlIGFuZCB3YW50cyB0byANCj4+IHVzZSBkaWZm ZXJlbnQgYmVhcmVycyAocG9zc2libGUgd2l0aCBkaWZmZXJlbnQgcXVhbGl0eSBjaGFyYWN0ZXJp c3RpY3MpIGZvciBSVFAgYW5kIFJUQ1AuDQo+PiANCj4+IEFub3RoZXIgcmVhc29uIGlzIGlmIHRo ZSByZWNlaXZlciBpcyBhIGdhdGV3YXkgY29ubmVjdGVkIHRvIGEgbmV0d29yayANCj4+IHdoZXJl IFJUUC9SVENQIG11bHRpcGxleGluZyBpcyBub3QgdXNlZC4gSW4gc3VjaCBjYXNlIHRoZSBnYXRl d2F5IG1heSANCj4+IHByZWZlciB0byBub3QgdXNlIFJUUC9SVENQIG11eCBvbiBlaXRoZXIgInNp ZGUiLiBPdGhlcndpc2UgaXQgd291bGQgDQo+PiBoYXZlIHRvIHBlcmZvcm0gUlRQL1JUQ1AgZGVt dXhpbmcgKGJldHdlZW4gdGhlIGVuZHBvaW50IHRoYXQgdXNlcyBtdXggYW5kIHRoZSBlbmRwb2lu dCB0aGF0IGRvZXNuJ3QpLg0KPj4gDQo+PiBBbm90aGVyIHJlYXNvbiBpcyBpZiBhIGRldmljZSB3 aXNoZXMgdG8gaGFuZGxlIFJUUCBhbmQgUlRDUCBvbiBkaWZmZXJlbnQgaW50ZXJmYWNlcy9kZXZp Y2VzLg0KPg0KPiBPa2F5LCBub3cgbWFrZXMgc2Vuc2UuIE1heWJlIGFkZCB0aGVzZSBleGFtcGxl cyB0byB0aGUgZHJhZnQ/DQoNCkkgY2FuIGRvIHRoYXQuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVy DQoNCg== From nobody Mon Aug 8 06:58:06 2016 Return-Path: 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 3D50512D746 for ; Mon, 8 Aug 2016 06:58:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.849 X-Spam-Level: X-Spam-Status: No, score=-103.849 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.247, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no 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 N_XIw9BfNUHP for ; Mon, 8 Aug 2016 06:58:03 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C822C126D74 for ; Mon, 8 Aug 2016 06:58:03 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id A81C8B80D3F; Mon, 8 Aug 2016 06:58:03 -0700 (PDT) To: M.Handley@cs.ucl.ac.uk, van@packetdesign.com, csp@csperkins.org, ben@nostrum.com, alissa@cooperw.in, aamelnikov@fastmail.fm, fandreas@cisco.com, bo.burman@ericsson.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20160808135803.A81C8B80D3F@rfc-editor.org> Date: Mon, 8 Aug 2016 06:58:03 -0700 (PDT) Archived-At: Cc: rfc-editor@rfc-editor.org, mmusic@ietf.org, arkamar@atlas.cz Subject: [MMUSIC] [Technical Errata Reported] RFC4566 (4769) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2016 13:58:05 -0000 The following errata report has been submitted for RFC4566, "SDP: Session Description Protocol". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=4566&eid=4769 -------------------------------------- Type: Technical Reported by: Petr Vaněk Section: 5.3. Original Text ------------- 5.3. Session Name ("s=") s= The "s=" field is the textual session name. There MUST be one and only one "s=" field per session description. The "s=" field MUST NOT be empty and SHOULD contain ISO 10646 characters (but see also the "a=charset" attribute). If a session has no meaningful name, the value "s= " SHOULD be used (i.e., a single space as the session name). Corrected Text -------------- 5.3. Session Name ("s=") s= The "s=" field is the textual session name. There MUST be one and only one "s=" field per session description. The "s=" field MUST NOT be empty and SHOULD contain ISO 10646 characters (but see also the "a=charset" attribute). If a session has no meaningful name, the value "s=-" SHOULD be used (i.e., a single dash as the session name). Notes ----- In 3rd paragraph of section 5. is written: whitespace MUST NOT be used on either side of the "=" sign, which is incosistent with subsection 5.3. Therefore I suggest to use "-" (single dash) instead of " " (single space) for sessions without meaningful name. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC4566 (draft-ietf-mmusic-sdp-new-26) -------------------------------------- Title : SDP: Session Description Protocol Publication Date : July 2006 Author(s) : M. Handley, V. Jacobson, C. Perkins Category : PROPOSED STANDARD Source : Multiparty Multimedia Session Control RAI Area : Real-time Applications and Infrastructure Stream : IETF Verifying Party : IESG From nobody Mon Aug 8 07:18:34 2016 Return-Path: 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 03CDE12D0CB; Mon, 8 Aug 2016 07:18:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 dODCodrn0SXh; Mon, 8 Aug 2016 07:18:27 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E52AE12D5E7; Mon, 8 Aug 2016 07:18:26 -0700 (PDT) X-AuditID: c1b4fb25-ca31e98000001071-dc-57a894b1d5bc Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by (Symantec Mail Security) with SMTP id 51.89.04209.1B498A75; Mon, 8 Aug 2016 16:18:25 +0200 (CEST) Received: from ESESSMB208.ericsson.se ([169.254.8.233]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.03.0301.000; Mon, 8 Aug 2016 16:18:22 +0200 From: Christer Holmberg To: "Mirja Kuehlewind (IETF)" , Alexey Melnikov , "ben@nostrum.com" Thread-Topic: New version of draft-ietf-mmusic-mux-exclusive Thread-Index: AdHxf5UeLyacGkeYSRCbLdTmiR8KBQ== Date: Mon, 8 Aug 2016 14:18:17 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BBC1B48@ESESSMB208.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjkeLIzCtJLcpLzFFi42KZGbE9UHfjlBXhBl92C1vsf3+IyWJ+52l2 i8tbT7FavL+gazHjz0RmixfXPzJbnN+5nsli6vLHLA4cHlN+b2T12HnqAJvHkiU/mTxaPi5k 9Zi18wlLAGsUl01Kak5mWWqRvl0CV8bZw2tZCs6wVFzf08PawLiHpYuRk0NCwERi8YonzF2M XBxCAusZJS61n2aBcBYzSuzd2sXUxcjBwSZgIdH9TxskLiLQwigx+/BdsCJmgX+MEtcm3WAF KRIWMJf4vbAMZKqIgI3EtCOX2CBsPYnGSbfBtrEIqEicu7+CGaScV8BXouOHBkiYUUBM4vup NUwgNrOAuMStJ/OZII4TkFiy5zwzhC0q8fLxP1YIW0lixfZLjCBjmAU0Jdbv0odoVZSY0v2Q HcTmFRCUODnzCcsERuFZSKbOQuiYhaRjFpKOBYwsqxhFi1OLk3LTjYz1Uosyk4uL8/P08lJL NjECY+nglt+qOxgvv3E8xCjAwajEw6tQvjxciDWxrLgy9xCjBAezkghvTf+KcCHelMTKqtSi /Pii0pzU4kOM0hwsSuK8/i8Vw4UE0hNLUrNTUwtSi2CyTBycUg2MLC6pn8ULRO/MvPcmpqJT ZqLZ41lnV8htWco5Lf2jxLrXZ7auW1X4T2sp27yXZh8mxNq0zm2ex7BojcWU5ddv3ize8bfl l19tfPPXortX/zNFP0irD2v6H715v5DiSYHdjCtTbXpueKsf+3Vippgsf682lwgjW9Qfy5l6 C1kUw5876wr9nVhjqcRSnJFoqMVcVJwIAJu33pKhAgAA Archived-At: Cc: "fandreas@cisco.com" , "mmusic-chairs@ietf.org" , "mmusic@ietf.org" , The IESG , "draft-ietf-mmusic-mux-exclusive@ietf.org" Subject: [MMUSIC] New version of draft-ietf-mmusic-mux-exclusive X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2016 14:18:29 -0000 SGksDQoNCkJhc2VkIG9uIHRoZSBjb21tZW50cyBmcm9tIEFsZXhleSBhbmQgTWlyamEsIEkndmUg Y3JlYXRlZCBhIG5ldyB2ZXJzaW9uIG9mIHRoZSBkcmFmdC4NCg0KSSBoYXZlIG5vdCBzdWJtaXR0 ZWQgaXQgeWV0LCBidXQgaXQgY2FuIGJlIGZvdW5kIG9uIEdpdEh1YjoNCg0KaHR0cHM6Ly9naXRo dWIuY29tL2NkaDR1L2RyYWZ0LW11eC1leGNsdXNpdmUvYmxvYi9tYXN0ZXIvZHJhZnQtaWV0Zi1t bXVzaWMtbXV4LWV4Y2x1c2l2ZS50eHQNCg0KUGxlYXNlIHRha2UgYSBsb29rIGFuZCBzZWUgd2hl dGhlciB5b3VyIGNvbW1lbnRzL2lzc3VlcyBoYXZlIGJlZW4gcHJvcGVybHkgYWRkcmVzc2VkLg0K DQpCZW4sIHBsZWFzZSBsZXQgbWUga25vdyB3aGVuIEkgY2FuIHN1Ym1pdCB0aGUgbmV3IHZlcnNp b24uDQoNClRoYW5rcyENCg0KQ2hyaXN0ZXINCg== From nobody Mon Aug 8 08:16:07 2016 Return-Path: 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 E397012D860; Mon, 8 Aug 2016 08:16:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastmail.fm header.b=dL4igVmD; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=W7q0RLDh 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 jdkgi8qYVS6y; Mon, 8 Aug 2016 08:16:04 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A827128E19; Mon, 8 Aug 2016 08:16:04 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id C55DA20650; Mon, 8 Aug 2016 11:16:03 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute6.internal (MEProxy); Mon, 08 Aug 2016 11:16:03 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=xtxMDOHyChf9nGf1UKusT4/fynM=; b=dL4igV mDN9ta6UC9tzkb5uIF3Ll+j6flco2s8aSZr/m1tgtXCK3IK/NkkiyufgrhEOZz4K QtPov0uKUQhzL0j725JhlaGcvWhrJ2jaPgYiJbYlbPTfJcDB59soMe+8tcVdM81B GaDMlFbhkj48/KhTJg+FwEy7iQICm1giQbKRw= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=xtxMDOHyChf9nGf 1UKusT4/fynM=; b=W7q0RLDhclseldiSJbD4KjY98tvvVjIoKFRvZFTueISDkw1 wZJawCOw0+fwzM7znEfbfT1wcvbTASZDwE8y+ozKncRAnl0WbEG+fDa1bmWmfQ6j 9zQgVAx8FVGAwqjMxfilaMtl+N9/cBgXuA+EGul7TNWKEcgMdEZWkF3HqBgA= X-Sasl-enc: e5bwM5FvUJzGO/hb22hRwX9e3tS4ru39/gOwltH8wiMR 1470669363 Received: from [192.168.0.6] (cpc5-nmal20-2-0-cust24.19-2.cable.virginm.net [92.234.84.25]) by mail.messagingengine.com (Postfix) with ESMTPA id 3CE29CCDCF; Mon, 8 Aug 2016 11:16:03 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Alexey Melnikov X-Mailer: iPad Mail (13G34) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BBC1B48@ESESSMB208.ericsson.se> Date: Mon, 8 Aug 2016 16:27:27 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <20DB0CA3-F7A9-4924-BEDA-9CC722F6A53E@fastmail.fm> References: <7594FB04B1934943A5C02806D1A2204B4BBC1B48@ESESSMB208.ericsson.se> To: Christer Holmberg Archived-At: Cc: "ben@nostrum.com" , "draft-ietf-mmusic-mux-exclusive@ietf.org" , "mmusic-chairs@ietf.org" , "fandreas@cisco.com" , "Mirja Kuehlewind \(IETF\)" , The IESG , "mmusic@ietf.org" Subject: Re: [MMUSIC] New version of draft-ietf-mmusic-mux-exclusive X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2016 15:16:06 -0000 Hi Christer, > On 8 Aug 2016, at 15:18, Christer Holmberg wrote: >=20 > Hi, >=20 > Based on the comments from Alexey and Mirja, I've created a new version of= the draft. >=20 > I have not submitted it yet, but it can be found on GitHub: >=20 > https://github.com/cdh4u/draft-mux-exclusive/blob/master/draft-ietf-mmusic= -mux-exclusive.txt >=20 > Please take a look and see whether your comments/issues have been properly= addressed. This looks good to me! Thank you, Alexey >=20 > Ben, please let me know when I can submit the new version. >=20 > Thanks! >=20 > Christer From nobody Mon Aug 8 08:43:55 2016 Return-Path: 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 C672A12D633 for ; Mon, 8 Aug 2016 08:43:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.149 X-Spam-Level: X-Spam-Status: No, score=-3.149 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 nbi4RZJcz15J for ; Mon, 8 Aug 2016 08:43:51 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 616FD12D611 for ; Mon, 8 Aug 2016 08:43:51 -0700 (PDT) Received: (qmail 14300 invoked from network); 8 Aug 2016 17:43:48 +0200 Received: from p5dec22a4.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.34.164) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 8 Aug 2016 17:43:48 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: <20DB0CA3-F7A9-4924-BEDA-9CC722F6A53E@fastmail.fm> Date: Mon, 8 Aug 2016 17:43:47 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7594FB04B1934943A5C02806D1A2204B4BBC1B48@ESESSMB208.ericsson.se> <20DB0CA3-F7A9-4924-BEDA-9CC722F6A53E@fastmail.fm> To: Alexey Melnikov X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "ben@nostrum.com" , "draft-ietf-mmusic-mux-exclusive@ietf.org" , "mmusic-chairs@ietf.org" , "fandreas@cisco.com" , The IESG , Christer Holmberg , "mmusic@ietf.org" Subject: Re: [MMUSIC] New version of draft-ietf-mmusic-mux-exclusive X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2016 15:43:54 -0000 Thanks. Fine for me. > Am 08.08.2016 um 17:27 schrieb Alexey Melnikov = : >=20 > Hi Christer, >=20 >> On 8 Aug 2016, at 15:18, Christer Holmberg = wrote: >>=20 >> Hi, >>=20 >> Based on the comments from Alexey and Mirja, I've created a new = version of the draft. >>=20 >> I have not submitted it yet, but it can be found on GitHub: >>=20 >> = https://github.com/cdh4u/draft-mux-exclusive/blob/master/draft-ietf-mmusic= -mux-exclusive.txt >>=20 >> Please take a look and see whether your comments/issues have been = properly addressed. >=20 > This looks good to me! >=20 > Thank you, > Alexey >>=20 >> Ben, please let me know when I can submit the new version. >>=20 >> Thanks! >>=20 >> Christer >=20 From nobody Mon Aug 8 08:47:05 2016 Return-Path: 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 962DE12D611; Mon, 8 Aug 2016 08:47:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] autolearn=ham autolearn_force=no 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 unML6iJ9hTFh; Mon, 8 Aug 2016 08:47:03 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22DDB12B012; Mon, 8 Aug 2016 08:47:03 -0700 (PDT) Received: from [192.168.11.1] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u78FkroQ057866 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 8 Aug 2016 10:46:53 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [192.168.11.1] From: "Ben Campbell" To: "Christer Holmberg" Date: Mon, 08 Aug 2016 10:46:53 -0500 Message-ID: In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BBC1B48@ESESSMB208.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B4BBC1B48@ESESSMB208.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: "mmusic-chairs@ietf.org" , "mmusic@ietf.org" , Alexey Melnikov , "fandreas@cisco.com" , Mirja Kuehlewind , The IESG , "draft-ietf-mmusic-mux-exclusive@ietf.org" Subject: Re: [MMUSIC] New version of draft-ietf-mmusic-mux-exclusive X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2016 15:47:04 -0000 Please submit it at your earliest convenience. Thanks! Ben. On 8 Aug 2016, at 9:18, Christer Holmberg wrote: > Hi, > > Based on the comments from Alexey and Mirja, I've created a new = > version of the draft. > > I have not submitted it yet, but it can be found on GitHub: > > https://github.com/cdh4u/draft-mux-exclusive/blob/master/draft-ietf-mmu= sic-mux-exclusive.txt > > Please take a look and see whether your comments/issues have been = > properly addressed. > > Ben, please let me know when I can submit the new version. > > Thanks! > > Christer From nobody Mon Aug 8 09:57:31 2016 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7542D12D66F; Mon, 8 Aug 2016 09:57:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147067544647.22959.12371312416927433915.idtracker@ietfa.amsl.com> Date: Mon, 08 Aug 2016 09:57:26 -0700 Archived-At: Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-mux-exclusive-10.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2016 16:57:26 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control of the IETF. Title : Indicating Exclusive Support of RTP/RTCP Multiplexing using SDP Author : Christer Holmberg Filename : draft-ietf-mmusic-mux-exclusive-10.txt Pages : 12 Date : 2016-08-08 Abstract: This document defines a new SDP media-level attribute, 'rtcp-mux- only', that can be used by an endpoint to indicate exclusive support of RTP/RTCP multiplexing. The document also updates RFC 5761, by clarifying that an offerer can use a mechanism to indicate that it is not able to send and receive RTCP on separate ports. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-mux-exclusive/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mmusic-mux-exclusive-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-mux-exclusive-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Aug 8 09:58:41 2016 Return-Path: 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 4776C12D86A; Mon, 8 Aug 2016 09:58:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 leo9DtQAInx3; Mon, 8 Aug 2016 09:58:32 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B411712D869; Mon, 8 Aug 2016 09:58:31 -0700 (PDT) X-AuditID: c1b4fb2d-903ff700000019a3-91-57a8ba33731b Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by (Symantec Mail Security) with SMTP id 5F.5D.06563.33AB8A75; Mon, 8 Aug 2016 18:58:29 +0200 (CEST) Received: from ESESSMB208.ericsson.se ([169.254.8.233]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0301.000; Mon, 8 Aug 2016 18:58:26 +0200 From: Christer Holmberg To: Ben Campbell Thread-Topic: New version of draft-ietf-mmusic-mux-exclusive Thread-Index: AdHxf5UeLyacGkeYSRCbLdTmiR8KBf//93mA///KfVA= Date: Mon, 8 Aug 2016 16:58:27 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BBC338E@ESESSMB208.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B4BBC1B48@ESESSMB208.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrOIsWRmVeSWpSXmKPExsUyM2K7iq7prhXhBs+bNCz2vz/EZDG/8zS7 xeWtp1gt3l/QtZjxZyKzxYvrH5ktzu9cz2QxdfljFgcOjym/N7J67Dx1gM1jyZKfTB4tHxey esza+YQlgDWKyyYlNSezLLVI3y6BK+PahTMsBas4Ki6sdGlg/MjWxcjBISFgIvG/ybSLkYtD SGA9o8SJ/i6mLkZOIGcxo8SeqzIgNWwCFhLd/7RBwiICShLPm7eygNQzC1xikrhzbAs7SEJY wFpi+5GDzBBFNhLTjlxig7CtJHrvTmcBsVkEVCTa9veB2bwCvhJnth9khVjcxChxquUy2CBO AXuJHdc/gBUxCohJfD+1BuwgZgFxiVtP5oPZEgICEkv2nGeGsEUlXj7+xwphK0ksuv0Zql5H YsHuT2wQtrbEsoWvmSEWC0qcnPmEZQKj6CwkY2chaZmFpGUWkpYFjCyrGEWLU4uLc9ONjPVS izKTi4vz8/TyUks2MQKj7+CW37o7GFe/djzEKMDBqMTDq1C+PFyINbGsuDL3EKMEB7OSCG/h lhXhQrwpiZVVqUX58UWlOanFhxilOViUxHn9XyqGCwmkJ5akZqemFqQWwWSZODilGhi7407F 7rMVtlhm8sc05sbkWd+UJuS+ybRqbdj2JufWkcA1QgWVtzXLbVSYrh4223TmeMuBb3YX/n7l C1hiNdsyccXntmmn5Oq+i7cu3CB8tmtBum1Vdv0T9bdmP+4KLbTg0rwXEVv1+8unfZ375hpt ny/hOe/tnc63i1xdJqpJPO9nko5alaegxFKckWioxVxUnAgA1Xm+KboCAAA= Archived-At: Cc: "mmusic-chairs@ietf.org" , "mmusic@ietf.org" , Alexey Melnikov , "fandreas@cisco.com" , Mirja Kuehlewind , The IESG , "draft-ietf-mmusic-mux-exclusive@ietf.org" Subject: Re: [MMUSIC] New version of draft-ietf-mmusic-mux-exclusive X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2016 16:58:34 -0000 Done :) Regards, Christer -----Original Message----- From: Ben Campbell [mailto:ben@nostrum.com]=20 Sent: 08 August 2016 18:47 To: Christer Holmberg Cc: Mirja Kuehlewind ; Alexey Melnikov ; fandreas@cisco.com; mmusic-chairs@ietf.org; mmusic@ietf.org; The= IESG ; draft-ietf-mmusic-mux-exclusive@ietf.org Subject: Re: New version of draft-ietf-mmusic-mux-exclusive Please submit it at your earliest convenience. Thanks! Ben. On 8 Aug 2016, at 9:18, Christer Holmberg wrote: > Hi, > > Based on the comments from Alexey and Mirja, I've created a new=20 > version of the draft. > > I have not submitted it yet, but it can be found on GitHub: > > https://github.com/cdh4u/draft-mux-exclusive/blob/master/draft-ietf-mm > usic-mux-exclusive.txt > > Please take a look and see whether your comments/issues have been=20 > properly addressed. > > Ben, please let me know when I can submit the new version. > > Thanks! > > Christer From nobody Mon Aug 8 16:44:30 2016 Return-Path: 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 135E612B057; Mon, 8 Aug 2016 16:44:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.849 X-Spam-Level: X-Spam-Status: No, score=-103.849 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.247, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no 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 TIIAnx1bDYwl; Mon, 8 Aug 2016 16:44:27 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B83DF12B012; Mon, 8 Aug 2016 16:44:27 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id A51B1B80B48; Mon, 8 Aug 2016 16:44:27 -0700 (PDT) To: arkamar@atlas.cz, M.Handley@cs.ucl.ac.uk, van@packetdesign.com, csp@csperkins.org X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20160808234427.A51B1B80B48@rfc-editor.org> Date: Mon, 8 Aug 2016 16:44:27 -0700 (PDT) Archived-At: Cc: ben@nostrum.com, rfc-editor@rfc-editor.org, iesg@ietf.org, mmusic@ietf.org Subject: [MMUSIC] [Errata Rejected] RFC4566 (4769) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2016 23:44:29 -0000 The following errata report has been rejected for RFC4566, "SDP: Session Description Protocol". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=4566&eid=4769 -------------------------------------- Status: Rejected Type: Technical Reported by: Petr Van?k Date Reported: 2016-08-08 Rejected by: Ben Campbell (IESG) Section: 5.3. Original Text ------------- 5.3. Session Name ("s=") s= The "s=" field is the textual session name. There MUST be one and only one "s=" field per session description. The "s=" field MUST NOT be empty and SHOULD contain ISO 10646 characters (but see also the "a=charset" attribute). If a session has no meaningful name, the value "s= " SHOULD be used (i.e., a single space as the session name). Corrected Text -------------- 5.3. Session Name ("s=") s= The "s=" field is the textual session name. There MUST be one and only one "s=" field per session description. The "s=" field MUST NOT be empty and SHOULD contain ISO 10646 characters (but see also the "a=charset" attribute). If a session has no meaningful name, the value "s=-" SHOULD be used (i.e., a single dash as the session name). Notes ----- In 3rd paragraph of section 5. is written: whitespace MUST NOT be used on either side of the "=" sign, which is incosistent with subsection 5.3. Therefore I suggest to use "-" (single dash) instead of " " (single space) for sessions without meaningful name. --VERIFIER NOTES-- The mmusic working group is in the process of updating RFC 4566. If the issue applies to the updated text ( https://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc4566bis/ ), please send comments to mmusic@ietf.org rather than file errata reports against RFC 4566. -------------------------------------- RFC4566 (draft-ietf-mmusic-sdp-new-26) -------------------------------------- Title : SDP: Session Description Protocol Publication Date : July 2006 Author(s) : M. Handley, V. Jacobson, C. Perkins Category : PROPOSED STANDARD Source : Multiparty Multimedia Session Control RAI Area : Real-time Applications and Infrastructure Stream : IETF Verifying Party : IESG From nobody Tue Aug 9 02:26:44 2016 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CF4312D0AE; Tue, 9 Aug 2016 02:26:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147073479931.30576.8695339868538757945.idtracker@ietfa.amsl.com> Date: Tue, 09 Aug 2016 02:26:39 -0700 Archived-At: Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-trickle-ice-sip-05.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2016 09:26:39 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control of the IETF. Title : A Session Initiation Protocol (SIP) usage for Trickle ICE Authors : Emil Ivov Thomas Stach Enrico Marocco Christer Holmberg Filename : draft-ietf-mmusic-trickle-ice-sip-05.txt Pages : 37 Date : 2016-08-09 Abstract: The Interactive Connectivity Establishment (ICE) protocol describes a Network Address Translator (NAT) traversal mechanism for UDP-based multimedia sessions established with the Offer/Answer model. The ICE extension for Incremental Provisioning of Candidates (Trickle ICE) defines a mechanism that allows ICE agents to shorten session establishment delays by making the candidate gathering and connectivity checking phases of ICE non-blocking and by executing them in parallel. This document defines usage semantics for Trickle ICE with the Session Initiation Protocol (SIP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-trickle-ice-sip/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mmusic-trickle-ice-sip-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-trickle-ice-sip-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Aug 9 02:30:06 2016 Return-Path: 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 E3C2112B058 for ; Tue, 9 Aug 2016 02:30:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 u52j2DvbkQg6 for ; Tue, 9 Aug 2016 02:30:04 -0700 (PDT) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 050C712D0E6 for ; Tue, 9 Aug 2016 02:30:04 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id o80so21631082wme.1 for ; Tue, 09 Aug 2016 02:30:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=nysGoT69m5AGn77zw75rNNKwARepYqu1MUXGPRJhadk=; b=G2ZfNKg1LFhwowf8quYO2fqwoyvxeIC+FmU+6F2oGCH3UGfe3c1odx1qSyDj5ChFua d+fUJF128WXP+m8RZpo6gOQFm6HlmznENEl5lzI21J3KTTmbN9VsdAScrmu7MUuC0TBN 2l7NnUPKcLxThY14c6+7LYlmyeQ+pAURX3nzU0hVIELSz/bdX/fAx7lIQ+jWEwwdK1+l qw9tOBLn+eWzhAf+0d744g74OhyfCcryqlJ96Nd4Fa+Ij2LKpXtjT+OXQDPm8Z0XQEt+ WJa6qYw/+CyG19GDA3sFvZ9f0Fi0cYOyo/fX5YcfQ7iVl/6KaSyYP0jgooU28M3/FhcC gSOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=nysGoT69m5AGn77zw75rNNKwARepYqu1MUXGPRJhadk=; b=BgQq7D40t641UatA2QR1pOVKVSr2NZROxOXP/pB1xJ5CJvVH2Nk/NEL9hYs0gnBON4 c0AQsMLHcSP8Aq/aA4KLxnhtBJRkoyjZGbK6NvG+V6ya3PrZLqhCCCLovEbUHebEeEuS ZLzLPEODLupVXTdnA52Wiz1isZHZYk9nR9psXjjqfmIPo/RZBRNkktsdvaMys7+mg9bg rnCJi8Fun4Rk41mSq/JsWagrMrWBacrUfL97psPAns+J2RPWNu8ZD+ptb5t20d1Od5KT EokHLfcnet3ecLh1x8dA/qMmNvheTPKi+ms4E1qbzrFN6LSdIxXmD0UGxKFbExj7/iaw vRtg== X-Gm-Message-State: AEkooutEIa8vq0ewchgkphkdlRcq36FT5OEa4IOpJo8BXJEsJbJn8bIoJBWlxWuoTychTA== X-Received: by 10.194.85.97 with SMTP id g1mr85966720wjz.72.1470735002096; Tue, 09 Aug 2016 02:30:02 -0700 (PDT) Received: from [192.168.2.110] (d91-130-31-33.cust.tele2.at. [91.130.31.33]) by smtp.googlemail.com with ESMTPSA id f4sm2362433wmf.8.2016.08.09.02.30.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 Aug 2016 02:30:01 -0700 (PDT) To: MMUSIC , Emil Ivov , Enrico Marocco , Christer Holmberg References: <147073479941.30576.9583445596022715837.idtracker@ietfa.amsl.com> From: Thomas Stach Message-ID: <0fc842b1-c6a0-39fe-da0d-760d6e231bce@gmail.com> Date: Tue, 9 Aug 2016 11:29:57 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <147073479941.30576.9583445596022715837.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [MMUSIC] New Version Notification for draft-ietf-mmusic-trickle-ice-sip-05.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2016 09:30:06 -0000 All, among editorial stuff this update includes the following Changes from draft-ietf-mmusic-trickle-ice-sip-04 o considered comments from Christer Holmberg o corrected grammar for INFO package, such that ice-ufrag/pwd are also allowed on media-level as specified in [I-D.ietf-mmusic-ice-sip-sdp] o Added new ice-pacing-attribute fom [I-D.ietf-mmusic-ice-sip-sdp] o Added formal definition for the end-of-candidates attribute Comments and reviews appreciated Regards Thomas On 2016-08-09 11:26, internet-drafts@ietf.org wrote: > A new version of I-D, draft-ietf-mmusic-trickle-ice-sip-05.txt > has been successfully submitted by Thomas Stach and posted to the > IETF repository. > > Name: draft-ietf-mmusic-trickle-ice-sip > Revision: 05 > Title: A Session Initiation Protocol (SIP) usage for Trickle ICE > Document date: 2016-08-09 > Group: mmusic > Pages: 37 > URL: https://www.ietf.org/internet-drafts/draft-ietf-mmusic-trickle-ice-sip-05.txt > Status: https://datatracker.ietf.org/doc/draft-ietf-mmusic-trickle-ice-sip/ > Htmlized: https://tools.ietf.org/html/draft-ietf-mmusic-trickle-ice-sip-05 > Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-trickle-ice-sip-05 > > Abstract: > The Interactive Connectivity Establishment (ICE) protocol describes a > Network Address Translator (NAT) traversal mechanism for UDP-based > multimedia sessions established with the Offer/Answer model. The ICE > extension for Incremental Provisioning of Candidates (Trickle ICE) > defines a mechanism that allows ICE agents to shorten session > establishment delays by making the candidate gathering and > connectivity checking phases of ICE non-blocking and by executing > them in parallel. > > This document defines usage semantics for Trickle ICE with the > Session Initiation Protocol (SIP). > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > From nobody Tue Aug 9 05:46:22 2016 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D1A5312D7F5; Tue, 9 Aug 2016 05:46:13 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147074677383.30652.4668619248071076758.idtracker@ietfa.amsl.com> Date: Tue, 09 Aug 2016 05:46:13 -0700 Archived-At: Cc: ben@nostrum.com, mmusic@ietf.org, mmusic-chairs@ietf.org, Flemming Andreasen , The IESG , draft-ietf-mmusic-mux-exclusive@ietf.org, rfc-editor@rfc-editor.org Subject: [MMUSIC] Protocol Action: 'Indicating Exclusive Support of RTP/RTCP Multiplexing using SDP' to Proposed Standard (draft-ietf-mmusic-mux-exclusive-10.txt) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2016 12:46:14 -0000 The IESG has approved the following document: - 'Indicating Exclusive Support of RTP/RTCP Multiplexing using SDP' (draft-ietf-mmusic-mux-exclusive-10.txt) as Proposed Standard This document is the product of the Multiparty Multimedia Session Control Working Group. The IESG contact persons are Alexey Melnikov, Ben Campbell and Alissa Cooper. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-mux-exclusive/ Technical Summary This document defines a new SDP media-level attribute, 'rtcp-mux-only', that can be used by an endpoint to indicate exclusive support of RTP/RTCP multiplexing. The document also updates RFC 5761, by clarifying that an offerer can use a mechanism to indicate that it is not able to send and receive RTCP on separate ports. Working Group Summary A WGLC was originally issued on the -03 version, which led to a couple of WG participants questioning the need for the mechanism (https://mailarchive.ietf.org/arch/msg/mmusic/7fcpfQWcfV8qkWFyAaaVl_2xBGA). After considerable discussion and discussion at IETF95, there was WG consensus to continue with the solution (https://mailarchive.ietf.org/arch/msg/mmusic/5OWNyDa4PpLbeX5mZ77zYMjqsBA). The consensus was confirmed on the mailing list with several indications of support and no objections. Document Quality At least two major browser vendors have indicated that their intention is to only support multiplexed RTP/RTCP for their WebRTC support. At least one WebRTC gateway vendor has indicated that they will support the protocol, in order to recognize WebRTC entities that only support multiplexed RTP/RTCP. The protocol has been adopted by 3GPP, and is mandatory to implement within the eP-CSCF function, which contains e.g. WebRTC gateway functionality. Reviewers that merit special mention are Roman Shpount, Paul Kyzivat and Martin Thomson. Personnel Flemming Andreasen is the Document Shepherd and Ben Campbell is the Responsible AD. From arkamar@atlas.cz Tue Aug 9 01:51:42 2016 Return-Path: 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 886B612D188 for ; Tue, 9 Aug 2016 01:51:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=atlas.cz 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 iA5NgzLDYrDr for ; Tue, 9 Aug 2016 01:51:40 -0700 (PDT) Received: from gmmr1.centrum.cz (gmmr1.centrum.cz [IPv6:2a00:da80:0:502::2]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D61F812D558 for ; Tue, 9 Aug 2016 01:51:38 -0700 (PDT) Received: from gm-as3.cent (unknown [10.255.254.13]) by gmmr1.centrum.cz (Postfix) with ESMTP id C036A8000241 for ; Tue, 9 Aug 2016 10:51:35 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=atlas.cz; s=mail; t=1470732695; bh=Ho3Tj+ZB2ztH6f4GFOyWuH+T+Zzny42hmOZBfOhSLdc=; h=Date:From:To:Subject:From; b=DPk3szP4zstnflblwPWlVG1BIkUV6ZT3VSGCvAfZh3a51rJBMOdUusynXf54OoLCK ycpxw6h3YWXx+KE/0goZOwD0AKepd3W8mluOX3OXQjfAanR8ZrxUHXdrjE8DDVrnmC I3vieXGAEstR6l4Sr4BPn2uI0JJqy8kgBYyWfrWc= Received: by gm-as3.cent (Postfix, from userid 65534) id BB3A6443AEF; Tue, 9 Aug 2016 10:51:35 +0200 (CEST) X-Original-From: arkamar@atlas.cz X-Envelope-To: mmusic@ietf.org X-Original-IP: 78.102.43.52 Received: from localhost (unknown [78.102.43.52]) by gm-smtp2.centrum.cz (Postfix) with ESMTPX id 7E190D14472 for ; Tue, 9 Aug 2016 10:51:35 +0200 (CEST) Date: Tue, 9 Aug 2016 10:51:50 +0200 From: Petr =?utf-8?B?VmFuxJtr?= To: mmusic@ietf.org Message-ID: <20160809085150.GC20739@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: X-Mailman-Approved-At: Tue, 09 Aug 2016 06:33:43 -0700 Subject: [MMUSIC] White space inconsistency in draft-ietf-mmusic-rfc4556bis X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2016 08:54:33 -0000 Hello, I found an inconsistency in https://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc4566bis, where in 3rd paragraph of section 5. SDP Specification is written: Whitespace MUST NOT be used on either side of the "=" sign. However, in subsection 5.3. Session Name ("s=") is the 'MUST NOT' violated by definition of session without meaningful name: If a session has no meaningful name, the value "s= " SHOULD be used (i.e., a single space as the session name). Therefore I suggest to use "-" (single dash) instead of " " (single space) to fix this issue: If a session has no meaningful name, the value "s=-" SHOULD be used (i.e., a single dash as the session name). Regards, Petr Vaněk From nobody Tue Aug 9 07:43:20 2016 Return-Path: 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 C1D0312D876 for ; Tue, 9 Aug 2016 07:43:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 a8BZvazMonQa for ; Tue, 9 Aug 2016 07:43:17 -0700 (PDT) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DF8112D837 for ; Tue, 9 Aug 2016 07:43:17 -0700 (PDT) Received: by mail-oi0-x234.google.com with SMTP id f189so20170962oig.3 for ; Tue, 09 Aug 2016 07:43:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vnpay4bkTb1InkGF2pe2AZ8EmGCfJYxJXpdcuISqR50=; b=o95+B4MFpw5Q6HbH2eXcZRazJv53iaQ1xtumHGEyM/gtEh/sqzCHse0zLeC9GyjODp MSc/LdJKbyNJgSWqpF2jQrxb3PMLAhoNCjaCquxi1haQmw32jaK//cZKvoCkbmBQQcli 2ywzBF9eGVvHLlfYkIcclUhIZoTFTIcgbmPvjsHWg+fD2ktQhZPQ53YVH3H/eKt1WE2X dgeIf9lTj+hx92zHtqL8ggWpl+5XNLT5aCRekWEORLg6PvPkwaW8m/ViJFpQsXhoLw1A tfbRvb+FoJUubfvVVycDxXu7yFBDuX1X+aOqpDffKHVG7FoAkJF1IrDMvWUG9EhO1PuV MvWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vnpay4bkTb1InkGF2pe2AZ8EmGCfJYxJXpdcuISqR50=; b=SN4E2IdJph/t5qaIhIazGJdPDdNNrbHsGRYQgKfbWcTgYSu09sQOzPZ7QvICfiCm6H B3e9EcWykNMPurex/Ynyr53vn3B2b+nVsy2Yijrz018peC03KRj7j7eVMCZS+MxWNomd 22BD3D2LuqC0KCoje9cakY+bbjd+YjJpHoPg37ML8seioBfm9NqCTt2odAHsNuZ0yXjF 92pCRyKGH0lgCuTH9DOGBovygtfmt4AN7aWxH3DUjjVu6tq7suZPAWGrzkpx9CLx/mQ1 LGWJZvtfMQgqrbpyB0sSQCg8IZ7BtkSzOUtFL030IcamvSaoLQpVJ8CagevafgXyFq0M mQoQ== X-Gm-Message-State: AEkoouu8/qJT6F3cRwj5LmMo6Wx5+xb/FLRy1YPlkRFxv18Fq1ioFoqdoTLASa7RyafV+QcJbe92rH7y1oXAmg== X-Received: by 10.202.50.139 with SMTP id y133mr52327122oiy.46.1470753796468; Tue, 09 Aug 2016 07:43:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.182.86 with HTTP; Tue, 9 Aug 2016 07:43:15 -0700 (PDT) In-Reply-To: <20160809085150.GC20739@localhost> References: <20160809085150.GC20739@localhost> From: "Ali C. Begen" Date: Tue, 9 Aug 2016 17:43:15 +0300 Message-ID: To: =?UTF-8?Q?Petr_Van=C4=9Bk?= Content-Type: multipart/alternative; boundary=001a113cf21e97353d0539a48d66 Archived-At: Cc: "mmusic \(E-mail\)" Subject: Re: [MMUSIC] White space inconsistency in draft-ietf-mmusic-rfc4556bis X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2016 14:43:19 -0000 --001a113cf21e97353d0539a48d66 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable This makes sense to me, and we can fix this in 4566bis. -acbegen On Tue, Aug 9, 2016 at 11:51 AM, Petr Van=C4=9Bk wrote: > Hello, > > I found an inconsistency in > https://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc4566bis, where in > 3rd paragraph of section 5. SDP Specification is written: > > Whitespace MUST NOT be used on either side of the "=3D" sign. > > However, in subsection 5.3. Session Name ("s=3D") is the 'MUST NOT' > violated by definition of session without meaningful name: > > If a session has no meaningful name, the value "s=3D " SHOULD be = used > (i.e., a single space as the session name). > > Therefore I suggest to use "-" (single dash) instead of " " (single > space) to fix this issue: > > If a session has no meaningful name, the value "s=3D-" SHOULD be = used > (i.e., a single dash as the session name). > > > Regards, > > Petr Van=C4=9Bk > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --001a113cf21e97353d0539a48d66 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This makes sense to me, and we can fix this in 4566bis.
-acbegen

On Tue, Aug 9, 2016 at 11:51 AM, Petr Van=C4=9Bk <arkam= ar@atlas.cz> wrote:
Hello,<= br>
I found an inconsistency in
https://datatracker.ietf.org/doc/d= raft-ietf-mmusic-rfc4566bis, where in
3rd paragraph of section 5. SDP Specification is written:

=C2=A0 =C2=A0Whitespace MUST NOT be used on either side of the "=3D&qu= ot; sign.

However, in subsection 5.3. Session Name ("s=3D") is the 'MUS= T NOT'
violated by definition of session without meaningful name:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 If a session has no meaningful name, the value = "s=3D " SHOULD be used
=C2=A0 =C2=A0 =C2=A0 =C2=A0 (i.e., a single space as the session name).

Therefore I suggest to use "-" (single dash) instead of " &q= uot; (single
space) to fix this issue:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 If a session has no meaningful name, the value = "s=3D-" SHOULD be used
=C2=A0 =C2=A0 =C2=A0 =C2=A0 (i.e., a single dash as the session name).


Regards,

Petr Van=C4=9Bk

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic

--001a113cf21e97353d0539a48d66-- From nobody Tue Aug 9 08:08:39 2016 Return-Path: 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 7571112D846 for ; Tue, 9 Aug 2016 08:08:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no 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 GH2iJjbo5WrH for ; Tue, 9 Aug 2016 08:08:35 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C592012D82C for ; Tue, 9 Aug 2016 08:08:35 -0700 (PDT) Received: from [130.209.157.55] (port=44618 helo=glaroam2-137-139.wireless.gla.ac.uk) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1bX8dj-0006Uu-OB; Tue, 09 Aug 2016 16:08:28 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_CC7DB840-B276-4AD9-9804-A4E5061CFBE5" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Colin Perkins In-Reply-To: Date: Tue, 9 Aug 2016 16:08:14 +0100 Message-Id: References: <20160809085150.GC20739@localhost> To: "Ali C. Begen" X-Mailer: Apple Mail (2.3124) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: Cc: "mmusic \(E-mail\)" , =?utf-8?Q?Petr_Van=C4=9Bk?= Subject: Re: [MMUSIC] White space inconsistency in draft-ietf-mmusic-rfc4556bis X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2016 15:08:37 -0000 --Apple-Mail=_CC7DB840-B276-4AD9-9804-A4E5061CFBE5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 We made this change in draft-ietf-mmusic-sdp-new-04, the draft that = eventually became RFC 4566, back in November 2001, and reverted it in = the -05 version. The rationale at the time for using =E2=80=9Cs=3D =E2=80=9C was to match = the offer/answer spec, and because that was what SIP clients expected = (see the mail thread following = http://mailarchive.ietf.org/arch/msg/mmusic/TsJjXeiCa0pIIGI2XTee773ckzc = = from the MMUSIC mailing list in Feb 2002). Whether that argument is = still valid, I don=E2=80=99t know (this was while RFC3264 was still = under development). Colin > On 9 Aug 2016, at 15:43, Ali C. Begen wrote: >=20 > This makes sense to me, and we can fix this in 4566bis. >=20 > -acbegen >=20 > On Tue, Aug 9, 2016 at 11:51 AM, Petr Van=C4=9Bk > wrote: > Hello, >=20 > I found an inconsistency in > https://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc4566bis = , where = in > 3rd paragraph of section 5. SDP Specification is written: >=20 > Whitespace MUST NOT be used on either side of the "=3D" sign. >=20 > However, in subsection 5.3. Session Name ("s=3D") is the 'MUST NOT' > violated by definition of session without meaningful name: >=20 > If a session has no meaningful name, the value "s=3D " SHOULD = be used > (i.e., a single space as the session name). >=20 > Therefore I suggest to use "-" (single dash) instead of " " (single > space) to fix this issue: >=20 > If a session has no meaningful name, the value "s=3D-" SHOULD = be used > (i.e., a single dash as the session name). >=20 >=20 > Regards, >=20 > Petr Van=C4=9Bk >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic = >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic --=20 Colin Perkins https://csperkins.org/ --Apple-Mail=_CC7DB840-B276-4AD9-9804-A4E5061CFBE5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 We made this change in draft-ietf-mmusic-sdp-new-04, the = draft that eventually became RFC 4566, back in November 2001, and = reverted it in the -05 version.

The rationale at the time for using =E2=80=9Cs=3D =E2=80=9C = was to match the offer/answer spec, and because that was what SIP = clients expected (see the mail thread following http://mailarchive.ietf.org/arch/msg/mmusic/TsJjXeiCa0pIIGI2XTe= e773ckzc from the MMUSIC mailing list in Feb 2002). Whether = that argument is still valid, I don=E2=80=99t know (this was while = RFC3264 was still under development).

Colin



On 9 Aug 2016, at 15:43, Ali C. Begen <acbegen@gmail.com> = wrote:

This makes sense to me, and we can fix this in = 4566bis.

-acbegen

On Tue, Aug 9, 2016 at 11:51 AM, = Petr Van=C4=9Bk <arkamar@atlas.cz> wrote:
Hello,

I found an inconsistency in
https://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc4566bis, where = in
3rd paragraph of section 5. SDP Specification is written:

   Whitespace MUST NOT be used on either side of the "=3D" = sign.

However, in subsection 5.3. Session Name ("s=3D") is the 'MUST NOT'
violated by definition of session without meaningful name:

        If a session has no meaningful name, the = value "s=3D " SHOULD be used
        (i.e., a single space as the session = name).

Therefore I suggest to use "-" (single dash) instead of " " (single
space) to fix this issue:

        If a session has no meaningful name, the = value "s=3D-" SHOULD be used
        (i.e., a single dash as the session = name).


Regards,

Petr Van=C4=9Bk

_______________________________________________
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



-- 
Colin Perkins
https://csperkins.org/



= --Apple-Mail=_CC7DB840-B276-4AD9-9804-A4E5061CFBE5-- From nobody Tue Aug 9 08:34:09 2016 Return-Path: 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 4615212D5D6 for ; Tue, 9 Aug 2016 08:34:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.83 X-Spam-Level: X-Spam-Status: No, score=-1.83 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 DKIw3bhbM_YH for ; Tue, 9 Aug 2016 08:34:06 -0700 (PDT) Received: from mx0a-00198e01.pphosted.com (mx0a-00198e01.pphosted.com [67.231.149.202]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDB1512B030 for ; Tue, 9 Aug 2016 08:34:06 -0700 (PDT) Received: from pps.filterd (m0073109.ppops.net [127.0.0.1]) by mx0a-00198e01.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id u79FVIIZ026762; Tue, 9 Aug 2016 11:33:58 -0400 Received: from mail.vidyo.com ([162.209.16.214]) by mx0a-00198e01.pphosted.com with ESMTP id 24ka60kxcq-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 09 Aug 2016 11:33:58 -0400 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0195.001; Tue, 9 Aug 2016 10:33:57 -0500 From: Jonathan Lennox To: "Ali C. Begen" Thread-Topic: [MMUSIC] White space inconsistency in draft-ietf-mmusic-rfc4556bis Thread-Index: AQHR8k9iDSz2JgkRZ0eH5O+PYWaTkaBBFhQA Date: Tue, 9 Aug 2016 15:33:57 +0000 Message-ID: References: <20160809085150.GC20739@localhost> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [160.79.219.114] Content-Type: multipart/alternative; boundary="_000_E58A61CCAAC244A79A8E2C7D37541A97vidyocom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.15.96, 1.0.3, 0.0.0000 definitions=2016-08-09_05:2016-08-09,2016-08-09,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1603290000 definitions=main-1608090159 Archived-At: Cc: mmusic , =?utf-8?B?UGV0ciBWYW7Em2s=?= Subject: Re: [MMUSIC] White space inconsistency in draft-ietf-mmusic-rfc4556bis X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2016 15:34:08 -0000 --_000_E58A61CCAAC244A79A8E2C7D37541A97vidyocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB0aGluayB3aGF0IG5lZWRzIHRvIGJlIGZpeGVkIGlzIHRoZSB3b3JkaW5nIG9mIFNlY3Rpb24g NSBwYXJhZ3JhcGggMy4gIFNlY3Rpb24gNS4zIHNob3VsZG7igJl0IG5lZWQgdG8gYmUgY2hhbmdl ZC4NCg0KV2hhdCBpdOKAmXMgaW50ZW5kaW5nIHRvIHNheSBpcyB0aGF0IHRoZXJlIE1VU1QgTk9U IGJlIHdoaXRlc3BhY2UgKnNlcGFyYXRvcnMqIGFyb3VuZCB0aGUg4oCcPeKAnSBzaWduLCBpLmUu IOKAnHYgPSAw4oCdIGlzbuKAmXQgdmFsaWQuDQoNCkhvd2V2ZXIsIGlmIHRoZSB2YWx1ZSBvZiB0 aGUgbGluZSBjYW4gY29udGFpbiBsZWFkaW5nIHdoaXRlc3BhY2UgYXMgcGFydCBvZiBpdHMgc3lu dGF4LCB0aGF04oCZcyBmaW5lLCBhbmQgdGhhdCB3aGl0ZXNwYWNlIGlzIHBhcnQgb2YgdGhlIGxp bmXigJlzIHZhbHVlIChub3QgYSBzZXBhcmF0b3IpLg0KDQpBcyBJIHJlYWQgdGhlIEJORiwgSSB0 aGluayB0aGUgbGluZXMgd2hvc2UgdmFsdWVzIGNhbiB2YWxpZGx5IHN0YXJ0IHdpdGggd2hpdGVz cGFjZSBhcmUgcz0sIGk9LCBhbmQgKHNsaWdodGx5IG1vcmUgb2JzY3VyZWx5KSBlPS4NCg0KSeKA mW0gcHJldHR5IHN1cmUgdGhpcyBpcyBob3cgbW9zdCBleGlzdGluZyBpbXBsZW1lbnRhdGlvbnMg YmVoYXZlIChpbnNvZmFyIGFzIHRoZXkgcGF5IGF0dGVudGlvbiB0byB0aG9zZSBsaW5lcyBhdCBh bGwpLg0KDQpPbiBBdWcgOSwgMjAxNiwgYXQgMTA6NDMgQU0sIEFsaSBDLiBCZWdlbiA8YWNiZWdl bkBnbWFpbC5jb208bWFpbHRvOmFjYmVnZW5AZ21haWwuY29tPj4gd3JvdGU6DQoNClRoaXMgbWFr ZXMgc2Vuc2UgdG8gbWUsIGFuZCB3ZSBjYW4gZml4IHRoaXMgaW4gNDU2NmJpcy4NCg0KLWFjYmVn ZW4NCg0KT24gVHVlLCBBdWcgOSwgMjAxNiBhdCAxMTo1MSBBTSwgUGV0ciBWYW7Em2sgPGFya2Ft YXJAYXRsYXMuY3o8bWFpbHRvOmFya2FtYXJAYXRsYXMuY3o+PiB3cm90ZToNCkhlbGxvLA0KDQpJ IGZvdW5kIGFuIGluY29uc2lzdGVuY3kgaW4NCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWlldGYtbW11c2ljLXJmYzQ1NjZiaXMsIHdoZXJlIGluDQozcmQgcGFyYWdyYXBo IG9mIHNlY3Rpb24gNS4gU0RQIFNwZWNpZmljYXRpb24gaXMgd3JpdHRlbjoNCg0KICAgV2hpdGVz cGFjZSBNVVNUIE5PVCBiZSB1c2VkIG9uIGVpdGhlciBzaWRlIG9mIHRoZSAiPSIgc2lnbi4NCg0K SG93ZXZlciwgaW4gc3Vic2VjdGlvbiA1LjMuIFNlc3Npb24gTmFtZSAoInM9IikgaXMgdGhlICdN VVNUIE5PVCcNCnZpb2xhdGVkIGJ5IGRlZmluaXRpb24gb2Ygc2Vzc2lvbiB3aXRob3V0IG1lYW5p bmdmdWwgbmFtZToNCg0KICAgICAgICBJZiBhIHNlc3Npb24gaGFzIG5vIG1lYW5pbmdmdWwgbmFt ZSwgdGhlIHZhbHVlICJzPSAiIFNIT1VMRCBiZSB1c2VkDQogICAgICAgIChpLmUuLCBhIHNpbmds ZSBzcGFjZSBhcyB0aGUgc2Vzc2lvbiBuYW1lKS4NCg0KVGhlcmVmb3JlIEkgc3VnZ2VzdCB0byB1 c2UgIi0iIChzaW5nbGUgZGFzaCkgaW5zdGVhZCBvZiAiICIgKHNpbmdsZQ0Kc3BhY2UpIHRvIGZp eCB0aGlzIGlzc3VlOg0KDQogICAgICAgIElmIGEgc2Vzc2lvbiBoYXMgbm8gbWVhbmluZ2Z1bCBu YW1lLCB0aGUgdmFsdWUgInM9LSIgU0hPVUxEIGJlIHVzZWQNCiAgICAgICAgKGkuZS4sIGEgc2lu Z2xlIGRhc2ggYXMgdGhlIHNlc3Npb24gbmFtZSkuDQoNCg0KUmVnYXJkcywNCg0KUGV0ciBWYW7E m2sNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1t dXNpYyBtYWlsaW5nIGxpc3QNCm1tdXNpY0BpZXRmLm9yZzxtYWlsdG86bW11c2ljQGlldGYub3Jn Pg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVzaWMNCg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1tdXNpYyBtYWlsaW5n IGxpc3QNCm1tdXNpY0BpZXRmLm9yZzxtYWlsdG86bW11c2ljQGlldGYub3JnPg0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVzaWMNCg0K --_000_E58A61CCAAC244A79A8E2C7D37541A97vidyocom_ Content-Type: text/html; charset="utf-8" Content-ID: <7DE57E9BDF086D4CA58FB827C8A50C06@vidyo.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5JIHRoaW5r IHdoYXQgbmVlZHMgdG8gYmUgZml4ZWQgaXMgdGhlIHdvcmRpbmcgb2YgU2VjdGlvbiA1IHBhcmFn cmFwaCAzLiAmbmJzcDtTZWN0aW9uIDUuMyBzaG91bGRu4oCZdCBuZWVkIHRvIGJlIGNoYW5nZWQu PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij5XaGF0IGl04oCZcyBpbnRlbmRpbmcgdG8gc2F5IGlzIHRoYXQgdGhlcmUgTVVTVCBOT1QgYmUg d2hpdGVzcGFjZSAqc2VwYXJhdG9ycyogYXJvdW5kIHRoZSDigJw94oCdIHNpZ24sIGkuZS4g4oCc diA9IDDigJ0gaXNu4oCZdCB2YWxpZC48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIi Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkhvd2V2ZXIsIGlmIHRoZSB2YWx1ZSBvZiB0aGUgbGlu ZSBjYW4gY29udGFpbiBsZWFkaW5nIHdoaXRlc3BhY2UgYXMgcGFydCBvZiBpdHMgc3ludGF4LCB0 aGF04oCZcyBmaW5lLCBhbmQgdGhhdCB3aGl0ZXNwYWNlIGlzIHBhcnQgb2YgdGhlIGxpbmXigJlz IHZhbHVlIChub3QgYSBzZXBhcmF0b3IpLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9 IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+QXMgSSByZWFkIHRoZSBCTkYsIEkgdGhpbmsgdGhl IGxpbmVzIHdob3NlIHZhbHVlcyBjYW4gdmFsaWRseSBzdGFydCB3aXRoIHdoaXRlc3BhY2UgYXJl IHM9LCBpPSwgYW5kIChzbGlnaHRseSBtb3JlIG9ic2N1cmVseSkgZT0uPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5J4oCZbSBwcmV0dHkg c3VyZSB0aGlzIGlzIGhvdyBtb3N0IGV4aXN0aW5nIGltcGxlbWVudGF0aW9ucyBiZWhhdmUgKGlu c29mYXIgYXMgdGhleSBwYXkgYXR0ZW50aW9uIHRvIHRob3NlIGxpbmVzIGF0IGFsbCkuPC9kaXY+ DQo8YnIgY2xhc3M9IiI+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+ DQo8ZGl2IGNsYXNzPSIiPk9uIEF1ZyA5LCAyMDE2LCBhdCAxMDo0MyBBTSwgQWxpIEMuIEJlZ2Vu ICZsdDs8YSBocmVmPSJtYWlsdG86YWNiZWdlbkBnbWFpbC5jb20iIGNsYXNzPSIiPmFjYmVnZW5A Z21haWwuY29tPC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hh bmdlLW5ld2xpbmUiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSIiPlRo aXMgbWFrZXMgc2Vuc2UgdG8gbWUsIGFuZCB3ZSBjYW4gZml4IHRoaXMgaW4gNDU2NmJpcy4NCjxk aXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPi1hY2JlZ2Vu PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj48YnIgY2xhc3M9IiI+DQo8 ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gVHVlLCBBdWcgOSwgMjAxNiBhdCAxMTo1MSBBTSwg UGV0ciBWYW7Em2sgPHNwYW4gZGlyPSJsdHIiIGNsYXNzPSIiPg0KJmx0OzxhIGhyZWY9Im1haWx0 bzphcmthbWFyQGF0bGFzLmN6IiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+YXJrYW1hckBhdGxh cy5jejwvYT4mZ3Q7PC9zcGFuPiB3cm90ZTo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSBjbGFz cz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHgg I2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCkhlbGxvLDxiciBjbGFzcz0iIj4NCjxiciBj bGFzcz0iIj4NCkkgZm91bmQgYW4gaW5jb25zaXN0ZW5jeSBpbjxiciBjbGFzcz0iIj4NCjxhIGhy ZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbW11c2ljLXJm YzQ1NjZiaXMiIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvPHdiciBjbGFzcz0iIj5kb2MvZHJhZnQtaWV0Zi1tbXVz aWMtPHdiciBjbGFzcz0iIj5yZmM0NTY2YmlzPC9hPiwgd2hlcmUgaW48YnIgY2xhc3M9IiI+DQoz cmQgcGFyYWdyYXBoIG9mIHNlY3Rpb24gNS4gU0RQIFNwZWNpZmljYXRpb24gaXMgd3JpdHRlbjo8 YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7V2hpdGVzcGFjZSBNVVNU IE5PVCBiZSB1c2VkIG9uIGVpdGhlciBzaWRlIG9mIHRoZSAmcXVvdDs9JnF1b3Q7IHNpZ24uPGJy IGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KSG93ZXZlciwgaW4gc3Vic2VjdGlvbiA1LjMuIFNl c3Npb24gTmFtZSAoJnF1b3Q7cz0mcXVvdDspIGlzIHRoZSAnTVVTVCBOT1QnPGJyIGNsYXNzPSIi Pg0KdmlvbGF0ZWQgYnkgZGVmaW5pdGlvbiBvZiBzZXNzaW9uIHdpdGhvdXQgbWVhbmluZ2Z1bCBu YW1lOjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyBJZiBhIHNlc3Npb24gaGFzIG5vIG1lYW5pbmdmdWwgbmFtZSwgdGhlIHZhbHVlICZxdW90 O3M9ICZxdW90OyBTSE9VTEQgYmUgdXNlZDxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAoaS5lLiwgYSBzaW5nbGUgc3BhY2UgYXMgdGhlIHNlc3Npb24gbmFtZSkuPGJy IGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KVGhlcmVmb3JlIEkgc3VnZ2VzdCB0byB1c2UgJnF1 b3Q7LSZxdW90OyAoc2luZ2xlIGRhc2gpIGluc3RlYWQgb2YgJnF1b3Q7ICZxdW90OyAoc2luZ2xl PGJyIGNsYXNzPSIiPg0Kc3BhY2UpIHRvIGZpeCB0aGlzIGlzc3VlOjxiciBjbGFzcz0iIj4NCjxi ciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBJZiBhIHNlc3Npb24gaGFz IG5vIG1lYW5pbmdmdWwgbmFtZSwgdGhlIHZhbHVlICZxdW90O3M9LSZxdW90OyBTSE9VTEQgYmUg dXNlZDxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAoaS5lLiwgYSBz aW5nbGUgZGFzaCBhcyB0aGUgc2Vzc2lvbiBuYW1lKS48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9 IiI+DQo8YnIgY2xhc3M9IiI+DQpSZWdhcmRzLDxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4N ClBldHIgVmFuxJtrPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPHdiciBjbGFzcz0iIj5fX19fX19fX19fX19fX19fXzxiciBjbGFzcz0i Ij4NCm1tdXNpYyBtYWlsaW5nIGxpc3Q8YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJtYWlsdG86bW11 c2ljQGlldGYub3JnIiBjbGFzcz0iIj5tbXVzaWNAaWV0Zi5vcmc8L2E+PGJyIGNsYXNzPSIiPg0K PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVzaWMiIHJl bD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vPHdiciBjbGFzcz0iIj5saXN0aW5mby9tbXVzaWM8L2E+PGJyIGNsYXNzPSIi Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyIGNsYXNzPSIiPg0KbW11 c2ljIG1haWxpbmcgbGlzdDxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Im1haWx0bzptbXVzaWNAaWV0 Zi5vcmciIGNsYXNzPSIiPm1tdXNpY0BpZXRmLm9yZzwvYT48YnIgY2xhc3M9IiI+DQpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNpYzxiciBjbGFzcz0iIj4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2JvZHk+DQo8L2h0bWw+ DQo= --_000_E58A61CCAAC244A79A8E2C7D37541A97vidyocom_-- From nobody Thu Aug 11 03:50:17 2016 Return-Path: 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 9BBC112B016 for ; Thu, 11 Aug 2016 03:50:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 l2XmVRCODeoO for ; Thu, 11 Aug 2016 03:50:10 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83A71120727 for ; Thu, 11 Aug 2016 03:50:10 -0700 (PDT) X-AuditID: c1b4fb2d-903ff700000019a3-b1-57ac585f9979 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.183.51]) by (Symantec Mail Security) with SMTP id 95.FC.06563.F585CA75; Thu, 11 Aug 2016 12:50:08 +0200 (CEST) Received: from ESESSMB208.ericsson.se ([169.254.8.233]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0301.000; Thu, 11 Aug 2016 12:50:06 +0200 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: BUNDLE: Removal of Design Considerations appendix? Thread-Index: AQHR874engXYrQ1yg0C3QI8WD5ZWgg== Date: Thu, 11 Aug 2016 10:50:06 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.5.160527 x-originating-ip: [153.88.183.20] Content-Type: multipart/alternative; boundary="_000_D3D233EDC6D8christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLLMWRmVeSWpSXmKPExsUyM2K7sW5CxJpwg2eHlCymLn/M4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujPfz1jAWbOOtmH3oGmMD41buLkZODgkBE4k1G9+ydDFycQgJ rGeUeP1sIxOEs4RR4tqZi2xdjBwcbAIWEt3/tEEaRATUJb7u7WEGsYUFrCW+31nBDlIiIuAg 8awpFKJET+L+6u1gJSwCqhINN04xgdi8AlYSn/bsZAWxGQXEJL6fWgMWZxYQl7j1ZD4TxD0C Ekv2nGeGsEUlXj7+B1YvCjTz+9fZUHFFiavTl0P1xkvM2DuDHWK+oMTJmU9YJjAKzUIydhaS sllIyiDiBhLvz81nhrC1JZYtfA1l60ts/HKWEcK2llh4aAcrspoFjByrGEWLU4uLc9ONjPVS izKTi4vz8/TyUks2MQIj5eCW37o7GFe/djzEKMDBqMTDuyB7dbgQa2JZcWXuIUYJDmYlEV6f sDXhQrwpiZVVqUX58UWlOanFhxilOViUxHn9XyqGCwmkJ5akZqemFqQWwWSZODilGhj5p7Fs ZG4Xbaiaelx7ZWaC7k3Bxy3yR4x/uR24dcLssqDf/S9yK4N4+Zuvv+Zn8gleo3Zf9fDvx2rb wqfW6Px+lZebKcI7+W2/l+WMb+LL+fbqMVfdCDoSnpB4m/Xs9fnK1s49Z2qC7mitl9gpoPji 6da5h+Y6mj1JWHpYQtSgQSL43r6EA/ZKLMUZiYZazEXFiQAcsQJQkAIAAA== Archived-At: Subject: [MMUSIC] BUNDLE: Removal of Design Considerations appendix? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2016 10:50:14 -0000 --_000_D3D233EDC6D8christerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi BUNDLE lovers, In draft-bundle, we have an =93Design Considerations=94 appendix (Appendix = A). The appendix contains a note, saying that the appendix might be removed bef= ore the publication of the RFC. I=92d now like to make the decision whether we=92ll remove the appendix or = not. My suggestion is that we DO remove it. Please indicate if you don=92t agree= . Regards, Christer --_000_D3D233EDC6D8christerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <7E22F576A195B5429002BB5C85C98828@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi BUNDLE lovers,

In draft-bundle, we have an =93Design Considerations=94 appendix (Appe= ndix A).

The appendix contains a note, saying that the appendix might be remove= d before the publication of the RFC.

I=92d now like to make the decision whether we=92ll remove the appendi= x or not.

My suggestion is that we DO remove it. Please indicate if you don=92t = agree.

Regards,

Christer
--_000_D3D233EDC6D8christerholmbergericssoncom_-- From nobody Thu Aug 11 06:50:36 2016 Return-Path: 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 0F5C812D6B9; Thu, 11 Aug 2016 06:50:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 aDJODTSy41jE; Thu, 11 Aug 2016 06:50:33 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2E0D12D73A; Thu, 11 Aug 2016 06:50:29 -0700 (PDT) X-AuditID: c1b4fb3a-c7bff700000009bd-f9-57ac82a241c4 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.183.72]) by (Symantec Mail Security) with SMTP id A9.5D.02493.2A28CA75; Thu, 11 Aug 2016 15:50:27 +0200 (CEST) Received: from ESESSMB208.ericsson.se ([169.254.8.233]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0301.000; Thu, 11 Aug 2016 15:50:26 +0200 From: Christer Holmberg To: Christer Holmberg , Magnus Westerlund , Flemming Andreasen , Jonathan Lennox , mmusic Thread-Topic: [MMUSIC] avtext-sdes-hdr-ext has been approved, BUNDLE should probably be changed to use it. Thread-Index: AQHRyw/UIl1SwULpvEegDZi1VKrJPJ/zxX8AgAAHmQCAADXYgP//3U+AgAArneCAAQZQAIAANGeAgE7juQA= Date: Thu, 11 Aug 2016 13:50:25 +0000 Message-ID: References: <0226C238-6410-4864-BA9D-8071B23F5373@vidyo.com> <92229887-fd53-4859-1369-60059c9352b7@cisco.com> <558b361f-43e6-ee2c-e346-22448a6eddb5@ericsson.com> <7594FB04B1934943A5C02806D1A2204B380F9149@ESESSMB209.ericsson.se> <7ddcd953-d670-44fc-e5ce-83f2626d5382@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.5.160527 x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrDIsWRmVeSWpSXmKPExsUyM2K7h+7ipjXhBj+WaltMn/WOzeL9BV2L /YvPM1tMXf6YxYHFY8rvjaweS5b8ZPJoe3aHPYA5issmJTUnsyy1SN8ugStj2pXr7AW3eSu+ roprYHzI1cXIySEhYCIx++sPxi5GLg4hgfWMEptOzmCDcJYwSrxZuJ65i5GDg03AQqL7nzZI g4jAdUaJvmMRIDazQK7Exjc32UFsYYFsia7Jy9gganIkZuztZIGwkyR6ntwEi7MIqEqsfnoG rJ5XwEpi8u1LrBC7tjNLNB07DdbAKWAtcXrZWbAGRgExie+n1jBBLBOXuPVkPhPE1QISS/ac Z4awRSVePv7HCmKLCuhJfP86GyquJPFjwyUWiF49iRtTp7CB/MIMNP/cJ1uIsLbEsoWvmSHu EZQ4OfMJywRG8VlIts1C0j0LoXsWku5ZSLoXMLKuYhQtTi0uzk03MtJLLcpMLi7Oz9PLSy3Z xAiMw4NbflvtYDz43PEQowAHoxIP74PFq8OFWBPLiitzDzFKcDArifC2N6wJF+JNSaysSi3K jy8qzUktPsQozcGiJM7r/1IxXEggPbEkNTs1tSC1CCbLxMEp1cDoX7jq4wnvwqN3NGcx75SM qJ7XxK8jN6l230qP9njDHy+XTcpgY50vpj0xOXjy2RaGUy5RVTFPPDKvzv7ksfn6y9jfcoYM CafsLtwIWSbp11on9v/QJ6kjk/jmPvo2uejcOb+Jdne8Lzhcvb09Vv55w+RX95RnXjn85fSr /X6aOj7Lw9QKdj7xU2Ipzkg01GIuKk4EAAnhVZO/AgAA Archived-At: Cc: "draft-ietf-mmusic-sdp-bundle-negotiation@ietf.org" Subject: Re: [MMUSIC] avtext-sdes-hdr-ext has been approved, BUNDLE should probably be changed to use it. X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2016 13:50:35 -0000 Hi, I=B9ve created a pull request that adds a reference to draft-avtext-sdes-hdr-ext, and extends the RTP SDES header extension for carrying the MID. As requested by Magnus, I also added a few more words on why it is needed, and some security/privacy text. https://github.com/cdh4u/draft-sdp-bundle/pull/4 Regards, Christer On 22/06/16 12:06, "Christer Holmberg" wrote: >Hi, > >... > >>>Also, if we update BUNDLE (if something needs to be updated) I assume >>> the text talking about the MID SDES item will be removed from >>> avtext-sdes-hdr-ext? >>> >> >>I think the only text in SDES header ext document about BUNDLE is the >>following: >> >> The ongoing work on bundling SDP media descriptions >> [I-D.ietf-mmusic-sdp-bundle-negotiation] has identified a new SDES >> item that can benefit from timely delivery. A corresponding RTP SDES >> compact header extension is therefore also defined and registered in >> that document: >> >> MID: This is a media description identifier that matches the value >> of the Session Description Protocol (SDP) [RFC4566] a=3Dmid >> attribute [RFC5888], to associate RTP streams multiplexed on the >> same transport with their respective SDP media description. >> >>All I can see that is does is saying. Hey, there is this other document >>that also have a SDES item that needs a header extension. Here is the >>abstract what it does. Go read the bundle draft for the details. >> >>I don't see an issue with leaving that in. Do you? Or have I forgotten >>about some other text about bundle? > > >No, you are correct. It can be left in the document. > >Regards, > >Christer > > From nobody Thu Aug 11 07:18:10 2016 Return-Path: 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 B19F212D727 for ; Thu, 11 Aug 2016 07:18:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no 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 ldGbiRJdtDah for ; Thu, 11 Aug 2016 07:18:06 -0700 (PDT) Received: from resqmta-ch2-07v.sys.comcast.net (resqmta-ch2-07v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:39]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9FA612D778 for ; Thu, 11 Aug 2016 07:15:08 -0700 (PDT) Received: from resomta-ch2-08v.sys.comcast.net ([69.252.207.104]) by resqmta-ch2-07v.sys.comcast.net with SMTP id XqkMbHOmnff8qXqlHbDuDG; Thu, 11 Aug 2016 14:15:07 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by comcast with SMTP id XqlHbkZaPS9gdXqlHbZbtr; Thu, 11 Aug 2016 14:15:07 +0000 To: mmusic@ietf.org References: From: Paul Kyzivat Message-ID: <819c9b98-4ade-4b5f-b53d-9c01b06780cf@alum.mit.edu> Date: Thu, 11 Aug 2016 10:15:06 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfIeguvMimRq8bcjxuWjiScA5KR/ZIaN1kMwDX/VrvPZVl0wZvPN4WxW2V5shd9rcSEm1tRQAY3mhyTU6NI0swkxxkqw3PVqwtQMYviIdwykJKcvTaNow 2E4xCXxG7EUYoCrMo51sr6LSr1CllIvds8YWvj9+C5qq+xE7t46NV81G7+INGt4/ZcHDF3WMbB5qug== Archived-At: Subject: Re: [MMUSIC] BUNDLE: Removal of Design Considerations appendix? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2016 14:18:10 -0000 I won't *object* to its removal, but I do think there is some value in retaining it. Once this becomes an RFC there won't otherwise be clear documentation of the rationales present in this appendix. I think it will help in answering future questions and objections from people implementing bundle. Thanks, Paul On 8/11/16 6:50 AM, Christer Holmberg wrote: > Hi BUNDLE lovers, > > In draft-bundle, we have an “Design Considerations” appendix (Appendix A). > > The appendix contains a note, saying that the appendix might be removed > before the publication of the RFC. > > I’d now like to make the decision whether we’ll remove the appendix or not. > > My suggestion is that we DO remove it. Please indicate if you don’t agree. > > Regards, > > Christer > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From nobody Mon Aug 15 13:12:30 2016 Return-Path: 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 C718E12D0AC for ; Mon, 15 Aug 2016 13:12:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no 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 n7btnijuXoR9 for ; Mon, 15 Aug 2016 13:12:28 -0700 (PDT) Received: from resqmta-po-07v.sys.comcast.net (resqmta-po-07v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:166]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 042D712D09A for ; Mon, 15 Aug 2016 13:12:27 -0700 (PDT) Received: from resomta-po-11v.sys.comcast.net ([96.114.154.235]) by resqmta-po-07v.sys.comcast.net with SMTP id ZOEubVMBnqbrLZOFHbaHis; Mon, 15 Aug 2016 20:12:27 +0000 Received: from hobgoblin.ariadne.com ([73.100.16.189]) by resomta-po-11v.sys.comcast.net with SMTP id ZOFFbYeOY2OVwZOFGb8V72; Mon, 15 Aug 2016 20:12:27 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u7FKCPXn011639; Mon, 15 Aug 2016 16:12:25 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u7FKCPow011635; Mon, 15 Aug 2016 16:12:25 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Paul Kyzivat In-Reply-To: <819c9b98-4ade-4b5f-b53d-9c01b06780cf@alum.mit.edu> (pkyzivat@alum.mit.edu) Sender: worley@ariadne.com (Dale R. Worley) Date: Mon, 15 Aug 2016 16:12:24 -0400 Message-ID: <87y43x23mf.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfIaoPPBWXMkNL1mLXIEIQEheEWUCoT4Nq/PdaN05NtWoa3EuViNwkxVn9ZaLD4TJLblkZG8HfHA1RsRlfHFpqD+K96E8SkSqWxLmdlkPayIkR4+z+GaY GVF2+J3xCDDRUFqHrXx7hAYBjdC9YSkzmBKsKVaBeeeY728dihyZsSkEM6ewhXk/02wCpvMg8DKq545JCGDhiiRvcJxijS7k5bk= Archived-At: Cc: mmusic@ietf.org Subject: Re: [MMUSIC] BUNDLE: Removal of Design Considerations appendix? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2016 20:12:29 -0000 Paul Kyzivat writes: > I won't *object* to its removal, but I do think there is some value in > retaining it. Once this becomes an RFC there won't otherwise be clear > documentation of the rationales present in this appendix. I think it > will help in answering future questions and objections from people > implementing bundle. I've always thought that more documentation is better than less. Dale From nobody Tue Aug 16 03:28:47 2016 Return-Path: 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 1351712D0A9 for ; Tue, 16 Aug 2016 03:28:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 Z-ymI1MgpI3m for ; Tue, 16 Aug 2016 03:28:44 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8190612B035 for ; Tue, 16 Aug 2016 03:28:44 -0700 (PDT) X-AuditID: c1b4fb3a-c7bff700000009bd-4f-57b2ead8694f Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by (Symantec Mail Security) with SMTP id 94.6B.02493.8DAE2B75; Tue, 16 Aug 2016 12:28:42 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.179]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0301.000; Tue, 16 Aug 2016 12:28:40 +0200 From: Christer Holmberg To: "Dale R. Worley" , Paul Kyzivat Thread-Topic: [MMUSIC] BUNDLE: Removal of Design Considerations appendix? Thread-Index: AQHR9zFcX6EtDcA+QkKl4DhDuVFOnqBLY0Qg Date: Tue, 16 Aug 2016 10:28:40 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BC128BC@ESESSMB209.ericsson.se> References: <819c9b98-4ade-4b5f-b53d-9c01b06780cf@alum.mit.edu> (pkyzivat@alum.mit.edu) <87y43x23mf.fsf@hobgoblin.ariadne.com> In-Reply-To: <87y43x23mf.fsf@hobgoblin.ariadne.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphkeLIzCtJLcpLzFFi42KZGbFdRffWq03hBt8uWVhMXf6YxWLFhgOs Fi9PlDkwe/x9/4HJY/L+r8weS5b8ZApgjuKySUnNySxLLdK3S+DKeDF5HmvBco6KYzNWsTYw fmDrYuTkkBAwkdj25RFTFyMXh5DAekaJLR0rWUESQgJLGCVaZhh1MXJwsAlYSHT/0wYJiwgE SmzrOs0KEmYWUJe4ujgIJCws4CHx4sxVNogST4mG+dPZIWwjiS/H3jOC2CwCqhK7H91kBrF5 BXwlns1axgKxtoFR4tS2brAGTgFjidX7PoMVMQqISXw/tYYJxGYWEJe49WQ+E8TNAhJL9pxn hrBFJV4+/scKYStJNC55wgpRryOxYPcnNghbW2LZwtdQiwUlTs58wjKBUXQWkrGzkLTMQtIy C0nLAkaWVYyixanFxbnpRkZ6qUWZycXF+Xl6eaklmxiBcXNwy2+rHYwHnzseYhTgYFTi4VVg 3hQuxJpYVlyZe4hRgoNZSYT36kugEG9KYmVValF+fFFpTmrxIUZpDhYlcV7/l4rhQgLpiSWp 2ampBalFMFkmDk6pBkYNiYjTR2ybsibrrzzI1X/o2+RDE2++spi1+fv11RkKMWI3Zxhtjn3r LP3u/ZJXfUeknsQ5XbR+dH7hT52FX4TtlxcHCQgVbTAyvPp2Kkstg+ymotVL8p9dWhQdsbqx Mnk5Q0hfj8o7Xa2pEqciwkUkAlYryH19+zrHJ3nVI0HXHWnrvjiEaesqsRRnJBpqMRcVJwIA gGe7qZcCAAA= Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE: Removal of Design Considerations appendix? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2016 10:28:46 -0000 Ok, I haven't heard anyone saying that we should remove the appendix, so I = suggest we keep it (and remove the note saying the we need to decide on wha= t to do with the appendix). Regards, Christer -----Original Message----- From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Dale R. Worley Sent: 15 August 2016 23:12 To: Paul Kyzivat Cc: mmusic@ietf.org Subject: Re: [MMUSIC] BUNDLE: Removal of Design Considerations appendix? Paul Kyzivat writes: > I won't *object* to its removal, but I do think there is some value in=20 > retaining it. Once this becomes an RFC there won't otherwise be clear=20 > documentation of the rationales present in this appendix. I think it=20 > will help in answering future questions and objections from people=20 > implementing bundle. I've always thought that more documentation is better than less. Dale _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From nobody Wed Aug 17 03:58:55 2016 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E5AE12D0A5; Wed, 17 Aug 2016 03:58:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147143153218.12177.9662819775537166637.idtracker@ietfa.amsl.com> Date: Wed, 17 Aug 2016 03:58:52 -0700 Archived-At: Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-bundle-negotiation-32.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 10:58:52 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control of the IETF. Title : Negotiating Media Multiplexing Using the Session Description Protocol (SDP) Authors : Christer Holmberg Harald Tveit Alvestrand Cullen Jennings Filename : draft-ietf-mmusic-sdp-bundle-negotiation-32.txt Pages : 54 Date : 2016-08-17 Abstract: This specification defines a new Session Description Protocol (SDP) Grouping Framework extension, 'BUNDLE'. The extension can be used with the SDP Offer/Answer mechanism to negotiate the usage of a single address:port combination (BUNDLE address) for receiving media, referred to as bundled media, specified by multiple SDP media descriptions ("m=" lines). To assist endpoints in negotiating the use of bundle this specification defines a new SDP attribute, 'bundle-only', which can be used to request that specific media is only used if bundled. The specification also updates RFC 3264, to allow usage of zero port values without meaning that media is rejected. There are multiple ways to correlate the bundled RTP packets with the appropriate media descriptions. This specification defines a new Real-time Transport Protocol (RTP) source description (SDES) item and a new RTP header extension that provides an additional way to do this correlation by using them to carry a value that associates the RTP/ RTCP packets with a specific media description. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-bundle-negotiation/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation-32 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sdp-bundle-negotiation-32 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Aug 17 04:02:05 2016 Return-Path: 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 137DE12D0E6; Wed, 17 Aug 2016 04:02:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 Z5VzXJNhSdvD; Wed, 17 Aug 2016 04:02:02 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5518712B014; Wed, 17 Aug 2016 04:02:02 -0700 (PDT) X-AuditID: c1b4fb30-ad3ff700000009f9-f2-57b4442703b7 Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.183.60]) by (Symantec Mail Security) with SMTP id 17.2D.02553.72444B75; Wed, 17 Aug 2016 13:02:00 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.179]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.03.0301.000; Wed, 17 Aug 2016 13:01:59 +0200 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: Draft new version: BUNDLE-32 Thread-Index: AQHR+HbGlH7g1sLD5EGTdHNd1CeDRw== Date: Wed, 17 Aug 2016 11:01:59 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.5.160527 x-originating-ip: [153.88.183.146] Content-Type: multipart/alternative; boundary="_000_D3DA1FC7CC9Fchristerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphkeLIzCtJLcpLzFFi42KZGbHdRlfDZUu4wb5Huhbnd65nspi6/DGL A5PHkiU/mQIYo7hsUlJzMstSi/TtErgy3ixZxVIwS7JiwaVPLA2MU8S6GDk5JARMJNasfM3c xcjFISSwnlFi27dTTBDOEkaJfXMPsHUxcnCwCVhIdP/TBmkQEVCX+Lq3hxnEZhYwlXj4ag0j SImwgKpE1/tCiBItibk3F7FB2HoSu16cYQexWYBKDv46CRbnFbCSmPLkG9gYRgExie+n1jBB jBSXuPVkPhPEbQISS/acZ4awRSVePv7HCmKLAs38/nU2VFxJ4seGSywgJzALxEt8b06CGC8o cXLmE5YJjMKzkEydhVA1C0kVRImBxPtz85khbG2JZQtfQ9n6Ehu/nGWEsK0lPmzbiqJmASPH KkbR4tTipNx0IyO91KLM5OLi/Dy9vNSSTYzAODq45bfBDsaXzx0PMQpwMCrx8C4I2RwuxJpY VlyZe4hRgoNZSYR3gdOWcCHelMTKqtSi/Pii0pzU4kOM0hwsSuK8/i8Vw4UE0hNLUrNTUwtS i2CyTBycUg2MLS9UdDIXaZ9bI2Tz+aRisOjfqzN4eiybmc68Wzt7Qe9Bue2WzOnObPPU13+M VYlTcamz8Yo22NVxoH7y2/4dbmkHuiU/nV9+f2Jozq/rt38pHb67JOBc4jTWiQUdvgysR378 MVqfemdZ4pzO5hsxKm8XMdos6TmSmKSf6nqyzqB6Zpq93POdSizFGYmGWsxFxYkAxFaHBJ8C AAA= Archived-At: Cc: "mmusic-chairs@ietf.org" Subject: [MMUSIC] Draft new version: BUNDLE-32 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 11:02:04 -0000 --_000_D3DA1FC7CC9Fchristerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, I=92ve submitted a new version (-32) of BUNDLE. - It now references draft-ietf-avt-rtp-hdrext for the RTP SDES header exten= sion. - The note whether we are going to keep the Design Considerations appendix = is removed, and the appendix itself is kept - Editorial fixes and clarifications based on comments from different indiv= iduals Happy reading! :) Regards, Christer --_000_D3DA1FC7CC9Fchristerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi,

I=92ve submitted a new version (-32) of BUNDLE.

- It now references draft-ietf-avt-rtp-hdrext for the RTP SDES header extension.
- The note whether w= e are going to keep the Design Considerations appendix is removed, and the = appendix itself is kept
- Editorial fixes and clarifications bas= ed on comments from differ= ent individuals

Happy reading! :)

Regards,

Christer
--_000_D3DA1FC7CC9Fchristerholmbergericssoncom_-- From nobody Tue Aug 23 06:41:55 2016 Return-Path: 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 E9D5E12D1BC; Tue, 23 Aug 2016 06:41:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 Lkv7P3_pHIzG; Tue, 23 Aug 2016 06:41:44 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C15012D1C1; Tue, 23 Aug 2016 06:41:38 -0700 (PDT) X-AuditID: c1b4fb3a-c91fe700000009bd-f9-57bc528fc481 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by (Symantec Mail Security) with SMTP id 76.A9.02493.F825CB75; Tue, 23 Aug 2016 15:41:37 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.179]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0301.000; Tue, 23 Aug 2016 15:41:35 +0200 From: Christer Holmberg To: =?iso-8859-1?Q?Mirja_K=FChlewind?= Thread-Topic: =?iso-8859-1?Q?Mirja_K=FChlewind's_No_Objection_on_draft-ietf-mmusic-mux-?= =?iso-8859-1?Q?exclusive-09:_(with_COMMENT)?= Thread-Index: AQHR5oXUdmY3ZrAWz0ucUbQzbONunKAqrPng///sYQCAAfPZAIAMbEZQgB2fIICAADRxgA== Date: Tue, 23 Aug 2016 13:41:34 +0000 Message-ID: References: <20160725150421.11530.97108.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B476E65EC@ESESSMB209.ericsson.se> <8FD87D38-D416-4A10-90E1-C156D4FB8E5D@kuehlewind.net> <7594FB04B1934943A5C02806D1A2204B476E8526@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4771F880@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.5.160527 x-originating-ip: [153.88.183.147] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <51D78703F7AED64EB7D6976C9F58D17D@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrJIsWRmVeSWpSXmKPExsUyM2K7ou7EoD3hBhtnM1lc3nqK1eL9BV2L GX8mMlu8uP6R2eL8zvVMFlOXP2ZxYPOY8nsjq8eSJT+ZPFo+LmQNYI7isklJzcksSy3St0vg yuj9/5ax4KZUxbVD39gbGA+IdjFycEgImEj0H4rvYuTkEBJYzygx42lwFyMXkL2EUaK34zsb SA2bgIVE9z9tkBoRARuJ8ycnM4PUMAv8Aao/18YI4ggLdDBK3F55HswREehklFjVsJ8ZoiVM Yv7FY0wgNouAqsSE7s1gcV4BK4kzT/4yQaz7yyTxctcGsCJOASeJ629fsILYjAJiEt9PrQGL MwuIS9x6Mh/MlhAQkFiy5zwzhC0q8fLxP7B6UQE9ie9fZzNDvKYkMW1rGkSrnsSNqVPYIGxr iS/vnjNC2NoSyxa+hrpHUOLkzCcsExjFZyHZNgtJ+ywk7bOQtM9C0r6AkXUVo2hxanFxbrqR kV5qUWZycXF+nl5easkmRmCEHtzy22oH48HnjocYBTgYlXh4F9juDhdiTSwrrsw9xCjBwawk wns2cE+4EG9KYmVValF+fFFpTmrxIUZpDhYlcV7/l4rhQgLpiSWp2ampBalFMFkmDk6pBsb0 ldMigywfh+ekcdy2VZjOyvfk2Gv19T9mvJf3rJLe0vxYP4t/48TTeRmm7GUTNHQVdymt8viZ 8ZFN5Oyx0ms/peJKWA7x7jQIMSt9vUzv+XmP298kNgXkvVJnuqPZExYXGGFY8+L4J+3wt1Vz tncabOdivM72p9v533Wp3Vu6w7+kHzt7UFOJpTgj0VCLuag4EQAqCO3OzAIAAA== Archived-At: Cc: "fandreas@cisco.com" , "mmusic-chairs@ietf.org" , "draft-ietf-mmusic-mux-exclusive@ietf.org" , "mmusic@ietf.org" , The IESG Subject: Re: [MMUSIC] =?iso-8859-1?q?Mirja_K=FChlewind=27s_No_Objection_on_dra?= =?iso-8859-1?q?ft-ietf-mmusic-mux-exclusive-09=3A_=28with_COMMENT=29?= X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2016 13:41:51 -0000 > >I've just realized I never answer to this mail. Thanks! Text looks good >and=20 >is helpful, I think! Great! Thanks! :) Regards, Christer >On 04.08.2016 17:19, Christer Holmberg wrote: >> Hi Mirja, >> >> I suggest the following modified text of the Introduction/3rd paragraph: >> >> "Some newer applications that do not require backward compatibility >> with peers that cannot multiplex RTCP might choose to not implement >> separation of RTP and RTCP. Examples of such applications are W3C >> WEBRTC [W3C.WD-webrtc-20120209] applications, that are not required >> to interoperate with non-WEBRTC clients. For such applications, this >> document defines an SDP attribute to signal intent to require >> multiplexing. The use of this attribute in SDP offers [RFC3264] by >> entities that ever need to interoperate with peers that do not >> support RTC/RTCP multiplexing may harm interoperability. Also, while >> the SDP answerer [RFC3264] might support, and prefer usage of, >> fallback to non-multiplex, the attribute indicates that fallback to >> non-multiplex cannot be enabled. One example of where non-multiplex >> is preferred is where an endpoint is connected to a radio interface, >> and wants to use different bearers (possibly with different quality >> characteristics) for RTP and RTCP. Another example is where the one >> endpoint is acting as a gateway to a network where RTP/RTCP >> multiplexing cannot be used. In such case there endpoint may prefer >> non-multiplexing also towards the other network. Otherwise the >> endpoint would have to perform de-multiplexing of RTP and RTCP." >> >> Regards, >> >> Christer >> >> -----Original Message----- >> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >> Sent: 27 July 2016 20:37 >> To: Mirja Kuehlewind (IETF) >> Cc: The IESG ; fandreas@cisco.com; >>mmusic-chairs@ietf.org; draft-ietf-mmusic-mux-exclusive@ietf.org; >>mmusic@ietf.org >> Subject: RE: Mirja K=FChlewind's No Objection on >>draft-ietf-mmusic-mux-exclusive-09: (with COMMENT) >> >> Hi Mirja, >> >> ... >> >>>> There are newer systems that ONLY support RTP/RTCP multiplexing - >>>> without being able to fall back to non-mux. However, the existing SDP >>>> attribute to indicate support of RTP/RTCP multiplexing mandates the >>>>sender to be able to fall back to non-mux. >>>> The new SDP attribute is used to indicate that you can do RTP/RTCP >>>>multiplexing ONLY. >>>> >>>> One reason why the receiver may support mux, but prefers to do >>>> non-mux is because it is connected to a radio interface and wants to >>>> use different bearers (possible with different quality >>>>characteristics) for RTP and RTCP. >>>> >>>> Another reason is if the receiver is a gateway connected to a network >>>> where RTP/RTCP multiplexing is not used. In such case the gateway may >>>> prefer to not use RTP/RTCP mux on either "side". Otherwise it would >>>> have to perform RTP/RTCP demuxing (between the endpoint that uses mux >>>>and the endpoint that doesn't). >>>> >>>> Another reason is if a device wishes to handle RTP and RTCP on >>>>different interfaces/devices. >>> >>> Okay, now makes sense. Maybe add these examples to the draft? >> >> I can do that. >> >> Regards, >> >> Christer >> From nobody Tue Aug 23 06:45:07 2016 Return-Path: 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 4B2A212D191 for ; Tue, 23 Aug 2016 06:45:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no 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 9NyAbpiR4mqW for ; Tue, 23 Aug 2016 06:45:02 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB11112D1C1 for ; Tue, 23 Aug 2016 06:45:01 -0700 (PDT) Received: (qmail 30252 invoked from network); 23 Aug 2016 15:38:15 +0200 Received: from nb-10510.ethz.ch (HELO ?82.130.103.143?) (82.130.103.143) by kuehlewind.net with ESMTPSA (DHE-RSA-AES128-SHA encrypted, authenticated); 23 Aug 2016 15:38:15 +0200 To: Christer Holmberg References: <20160725150421.11530.97108.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B476E65EC@ESESSMB209.ericsson.se> <8FD87D38-D416-4A10-90E1-C156D4FB8E5D@kuehlewind.net> <7594FB04B1934943A5C02806D1A2204B476E8526@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4771F880@ESESSMB209.ericsson.se> From: =?UTF-8?Q?Mirja_K=c3=bchlewind?= Message-ID: Date: Tue, 23 Aug 2016 15:38:09 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4771F880@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "fandreas@cisco.com" , "mmusic-chairs@ietf.org" , "draft-ietf-mmusic-mux-exclusive@ietf.org" , "mmusic@ietf.org" , The IESG Subject: Re: [MMUSIC] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-mmusic-mux-exclusive-09=3A_=28with_COMMENT=29?= X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2016 13:45:04 -0000 Hi Christer, I've just realized I never answer to this mail. Thanks! Text looks good and is helpful, I think! Mirja On 04.08.2016 17:19, Christer Holmberg wrote: > Hi Mirja, > > I suggest the following modified text of the Introduction/3rd paragraph: > > "Some newer applications that do not require backward compatibility > with peers that cannot multiplex RTCP might choose to not implement > separation of RTP and RTCP. Examples of such applications are W3C > WEBRTC [W3C.WD-webrtc-20120209] applications, that are not required > to interoperate with non-WEBRTC clients. For such applications, this > document defines an SDP attribute to signal intent to require > multiplexing. The use of this attribute in SDP offers [RFC3264] by > entities that ever need to interoperate with peers that do not > support RTC/RTCP multiplexing may harm interoperability. Also, while > the SDP answerer [RFC3264] might support, and prefer usage of, > fallback to non-multiplex, the attribute indicates that fallback to > non-multiplex cannot be enabled. One example of where non-multiplex > is preferred is where an endpoint is connected to a radio interface, > and wants to use different bearers (possibly with different quality > characteristics) for RTP and RTCP. Another example is where the one > endpoint is acting as a gateway to a network where RTP/RTCP > multiplexing cannot be used. In such case there endpoint may prefer > non-multiplexing also towards the other network. Otherwise the > endpoint would have to perform de-multiplexing of RTP and RTCP." > > Regards, > > Christer > > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: 27 July 2016 20:37 > To: Mirja Kuehlewind (IETF) > Cc: The IESG ; fandreas@cisco.com; mmusic-chairs@ietf.org; draft-ietf-mmusic-mux-exclusive@ietf.org; mmusic@ietf.org > Subject: RE: Mirja Kühlewind's No Objection on draft-ietf-mmusic-mux-exclusive-09: (with COMMENT) > > Hi Mirja, > > ... > >>> There are newer systems that ONLY support RTP/RTCP multiplexing - >>> without being able to fall back to non-mux. However, the existing SDP >>> attribute to indicate support of RTP/RTCP multiplexing mandates the sender to be able to fall back to non-mux. >>> The new SDP attribute is used to indicate that you can do RTP/RTCP multiplexing ONLY. >>> >>> One reason why the receiver may support mux, but prefers to do >>> non-mux is because it is connected to a radio interface and wants to >>> use different bearers (possible with different quality characteristics) for RTP and RTCP. >>> >>> Another reason is if the receiver is a gateway connected to a network >>> where RTP/RTCP multiplexing is not used. In such case the gateway may >>> prefer to not use RTP/RTCP mux on either "side". Otherwise it would >>> have to perform RTP/RTCP demuxing (between the endpoint that uses mux and the endpoint that doesn't). >>> >>> Another reason is if a device wishes to handle RTP and RTCP on different interfaces/devices. >> >> Okay, now makes sense. Maybe add these examples to the draft? > > I can do that. > > Regards, > > Christer > From nobody Wed Aug 24 12:53:38 2016 Return-Path: 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 0B1A012D76C for ; Wed, 24 Aug 2016 12:53:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.068 X-Spam-Level: X-Spam-Status: No, score=-15.068 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.548, 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 NyJ3J1F-Aufi for ; Wed, 24 Aug 2016 12:53:35 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C06812B02C for ; Wed, 24 Aug 2016 12:53:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9421; q=dns/txt; s=iport; t=1472068415; x=1473278015; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=lN2tYk5hC4zwbLCtfbrEAQCCtTQ+XmPvnk8qRkzsy+U=; b=XeaK5PjrlwvkO4kDZDbFOFuivLxvxKL2l0/4wBRq7dYiKBTVM/J9LDf+ PNmUApyVnpKIbEuuhqp+CD7rJADTW6QvTe6ar+H5G6hUcG9kD1VN2XSSm 8ji1fKuk6wKaROeCQxevnwyfklrZgEV/23RSQZ8WQ1YcVEMglFJ0GISB/ Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DXBgCD+r1X/5tdJa1cgykBAQEBAR5WK?= =?us-ascii?q?lKrYIcmhQiBfiSFL0oCgU05EwIBAQEBAQEBXieEYgEFAQEhSwsQCQIYJwMCAiE?= =?us-ascii?q?GHxEGAQwGAgEBiBQDFw6SBJ0ihROGYAUIhAgBAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEXBYYtgXiCVYJDhH+CWgWGEIgPhWKFEzSGIIV3Q4JIgW2HbCOFVIg3hAmDeR8?= =?us-ascii?q?BNIQZIDSIVwEBAQ?= X-IronPort-AV: E=Sophos;i="5.28,572,1464652800"; d="scan'208,217";a="314909655" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Aug 2016 19:53:34 +0000 Received: from [10.98.149.203] (bxb-fandreas-88110.cisco.com [10.98.149.203]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u7OJrXEp020118; Wed, 24 Aug 2016 19:53:33 GMT To: Jonathan Lennox , "Ali C. Begen" References: <20160809085150.GC20739@localhost> From: Flemming Andreasen Message-ID: <77f38ad1-8d92-c0c3-e3eb-b34264d6e9e7@cisco.com> Date: Wed, 24 Aug 2016 15:53:33 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------274D126267BFFB56EBE41F02" Archived-At: Cc: mmusic , =?UTF-8?Q?Petr_Van=c4=9bk?= Subject: Re: [MMUSIC] White space inconsistency in draft-ietf-mmusic-rfc4556bis X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2016 19:53:37 -0000 This is a multi-part message in MIME format. --------------274D126267BFFB56EBE41F02 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit I agree with Jonathan. Thanks -- Flemming (as individual) On 8/9/16 11:33 AM, Jonathan Lennox wrote: > I think what needs to be fixed is the wording of Section 5 paragraph > 3. Section 5.3 shouldn’t need to be changed. > > What it’s intending to say is that there MUST NOT be whitespace > *separators* around the “=†sign, i.e. “v = 0†isn’t valid. > > However, if the value of the line can contain leading whitespace as > part of its syntax, that’s fine, and that whitespace is part of the > line’s value (not a separator). > > As I read the BNF, I think the lines whose values can validly start > with whitespace are s=, i=, and (slightly more obscurely) e=. > > I’m pretty sure this is how most existing implementations behave > (insofar as they pay attention to those lines at all). > >> On Aug 9, 2016, at 10:43 AM, Ali C. Begen > > wrote: >> >> This makes sense to me, and we can fix this in 4566bis. >> >> -acbegen >> >> On Tue, Aug 9, 2016 at 11:51 AM, Petr Vaněk > > wrote: >> >> Hello, >> >> I found an inconsistency in >> https://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc4566bis >> , >> where in >> 3rd paragraph of section 5. SDP Specification is written: >> >> Whitespace MUST NOT be used on either side of the "=" sign. >> >> However, in subsection 5.3. Session Name ("s=") is the 'MUST NOT' >> violated by definition of session without meaningful name: >> >> If a session has no meaningful name, the value "s= " >> SHOULD be used >> (i.e., a single space as the session name). >> >> Therefore I suggest to use "-" (single dash) instead of " " (single >> space) to fix this issue: >> >> If a session has no meaningful name, the value "s=-" >> SHOULD be used >> (i.e., a single dash as the session name). >> >> >> Regards, >> >> Petr Vaněk >> >> _______________________________________________ >> 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 mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic --------------274D126267BFFB56EBE41F02 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit I agree with Jonathan.

Thanks

-- Flemming (as individual)

On 8/9/16 11:33 AM, Jonathan Lennox wrote:
I think what needs to be fixed is the wording of Section 5 paragraph 3.  Section 5.3 shouldn’t need to be changed.

What it’s intending to say is that there MUST NOT be whitespace *separators* around the “=†sign, i.e. “v = 0†isn’t valid.

However, if the value of the line can contain leading whitespace as part of its syntax, that’s fine, and that whitespace is part of the line’s value (not a separator).

As I read the BNF, I think the lines whose values can validly start with whitespace are s=, i=, and (slightly more obscurely) e=.

I’m pretty sure this is how most existing implementations behave (insofar as they pay attention to those lines at all).

On Aug 9, 2016, at 10:43 AM, Ali C. Begen <acbegen@gmail.com> wrote:

This makes sense to me, and we can fix this in 4566bis.

-acbegen

On Tue, Aug 9, 2016 at 11:51 AM, Petr Vaněk <arkamar@atlas.cz> wrote:
Hello,

I found an inconsistency in
https://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc4566bis, where in
3rd paragraph of section 5. SDP Specification is written:

   Whitespace MUST NOT be used on either side of the "=" sign.

However, in subsection 5.3. Session Name ("s=") is the 'MUST NOT'
violated by definition of session without meaningful name:

        If a session has no meaningful name, the value "s= " SHOULD be used
        (i.e., a single space as the session name).

Therefore I suggest to use "-" (single dash) instead of " " (single
space) to fix this issue:

        If a session has no meaningful name, the value "s=-" SHOULD be used
        (i.e., a single dash as the session name).


Regards,

Petr Vaněk

_______________________________________________
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 mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic

--------------274D126267BFFB56EBE41F02-- From nobody Thu Aug 25 08:21:43 2016 Return-Path: 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 8598812D0E2 for ; Thu, 25 Aug 2016 08:21:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.069 X-Spam-Level: X-Spam-Status: No, score=-115.069 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] 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 FkUZwoD9jMfM for ; Thu, 25 Aug 2016 08:21:41 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97F6B12D142 for ; Thu, 25 Aug 2016 08:21:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=807; q=dns/txt; s=iport; t=1472138501; x=1473348101; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=gErkkwTAf11UbXa+doQ4T5YbcEvcPc56SuhvYCcGSIo=; b=H3bEpDr2zpoHwnaZzPsxFK1pKx6zcEvkM/Mi18/+QuDxeavSA/sLW/nS Ryb1Sm5l0SjPyKXR2f7wsWVcorAFbFG+ZN6+IwVHH9OgcXL3jjGdXZc8D zWrM7TIKJyjL+N+6C+U9gxvHXFLp9KqCsU8IqWNFu2cu0mt3foe3zqP/j g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BYAgD4C79X/5ldJa1dgykBAQEBAR6BW?= =?us-ascii?q?aNzlB2BfId5OBQCAQEBAQEBAV4nhGg6UQE+QicEiEWgPJ9KAQEBAQEFAQEBAQE?= =?us-ascii?q?BAQEBHogmCIo6gi8FmUoBgTiNbQqBY41khmqJTwEeNoN9hnJ/AQEB?= X-IronPort-AV: E=Sophos;i="5.28,576,1464652800"; d="scan'208";a="139842229" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Aug 2016 15:21:40 +0000 Received: from XCH-RTP-001.cisco.com (xch-rtp-001.cisco.com [64.101.220.141]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u7PFLefE019445 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 25 Aug 2016 15:21:40 GMT Received: from xch-rtp-004.cisco.com (64.101.220.144) by XCH-RTP-001.cisco.com (64.101.220.141) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 25 Aug 2016 11:21:39 -0400 Received: from xch-rtp-004.cisco.com ([64.101.220.144]) by XCH-RTP-004.cisco.com ([64.101.220.144]) with mapi id 15.00.1210.000; Thu, 25 Aug 2016 11:21:39 -0400 From: "Cullen Jennings (fluffy)" To: mmusic WG Thread-Topic: Concern with status of draft-ietf-mmusic-4572-update Thread-Index: AQHR/uRgZTFAAGlQikCvT4xqxMTFcg== Date: Thu, 25 Aug 2016 15:21:39 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.20.249.165] Content-Type: text/plain; charset="us-ascii" Content-ID: <8989A5679EC9024AAF08CD615D1A5649@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [MMUSIC] Concern with status of draft-ietf-mmusic-4572-update X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2016 15:21:42 -0000 I do not think that draft-ietf-mmusic-4572-update can should be an "update"= to 4572. RFC 4572 is widely deployed and the deployments are not going to = be changed to incorporate this update. Having customers tell me equipment i= s not 4572 compliant because it does not implement this is not good. It wil= l lead to interoperability problems where some people do this and others do= not. For example, a 4572 is unlikely to include a SHA-256 fingerprint yet = someone reading this update might make there systeme require the SHA-256 si= nce this says it is a MUST.=20 Instead I think this should be written as an extension to 4572 and JSEP and= WebRTC should normatively reference it.=20 For backwards compatibility, I think that including SHA-1 as wells as SHA-= 256 should be a MUST From nobody Thu Aug 25 08:52:50 2016 Return-Path: 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 801FE12D84E for ; Thu, 25 Aug 2016 08:52:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 J_qJMvZyxUul for ; Thu, 25 Aug 2016 08:52:47 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0507812D516 for ; Thu, 25 Aug 2016 08:52:24 -0700 (PDT) X-AuditID: c1b4fb25-8bfff70000001071-0f-57bf143668f2 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by (Symantec Mail Security) with SMTP id 55.AA.04209.6341FB75; Thu, 25 Aug 2016 17:52:24 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.211]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0301.000; Thu, 25 Aug 2016 17:52:22 +0200 From: Christer Holmberg To: "Cullen Jennings (fluffy)" , mmusic WG Thread-Topic: Concern with status of draft-ietf-mmusic-4572-update Thread-Index: AQHR/uRgZTFAAGlQikCvT4xqxMTFcqBZ0G8g Date: Thu, 25 Aug 2016 15:52:22 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BC61E27@ESESSMB209.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDLMWRmVeSWpSXmKPExsUyM2K7ma6FyP5wg7sNehYdk9kspi5/zOLA 5DHl90ZWjyVLfjIFMEVx2aSk5mSWpRbp2yVwZXzfXVFwh7/i/+fFjA2Mz3i6GDk5JARMJKb0 72YCsYUE1jNKNLxR6mLkArKXMEpsOT+RtYuRg4NNwEKi+582iCki4CfxeF8NSLmwgKPEnv1X GEFsEQEnif1fTkLZRhJf/sxlA7FZBFQlZjesZgexeQV8JR6sfAe1ykbi0MRbYDangK3EnD9b WEBsRgExie+n1oDFmQXEJW49mc8EcaaAxJI955khbFGJl4//sULYShIrtl9ihKjXkViw+xMb hK0tsWzha2aIvYISJ2c+YZnAKDILydhZSFpmIWmZhaRlASPLKkbR4tTipNx0I2O91KLM5OLi /Dy9vNSSTYzAODi45bfqDsbLbxwPMQpwMCrx8C54sDdciDWxrLgy9xCjBAezkgjvLaH94UK8 KYmVValF+fFFpTmpxYcYpTlYlMR5/V8qhgsJpCeWpGanphakFsFkmTg4pRoY66sTjjMHZr/J fDF55pzkG4fM6wt2bZJQ7vZojdQRe6Cn8fbnxcOZje33fP5ZM2VMe/rtRt4V+eDCe3MD9q1N 45Kc/PX5zJcvuAIerevIf/LgAatq2dJtuXortgmeDhK8375guobGjO9lnSybSlrDTtcxSD0s UVpdKvDv8gbGxO7zN1cbn3lVqMRSnJFoqMVcVJwIADasGfB/AgAA Archived-At: Subject: Re: [MMUSIC] Concern with status of draft-ietf-mmusic-4572-update X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2016 15:52:49 -0000 Define "extension". Does that mean we need a way to indicate support of tha= t extension too? Some people claimed that there are already implementations using multiple f= ingerprints, and one of the purposes of the draft is to clarify the rules a= nd semantics of that, in order to give people a common understanding of the= semantics of multiple fingerprints.=20 And, things will still work even if some existing implementations only look= at one of the fingerprints. There were quite extensive list discussions, especially between Roman S and= Martin T, in order to get everything right, so I REALLY think we should ke= ep it as it is. Also, WGLC ended 19th June, and the WG that you are co-chai= ring have asked for this (among others) documents to be finalized :) Regards, Christer -----Original Message----- From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Cullen Jennings = (fluffy) Sent: 25 August 2016 18:22 To: mmusic WG Subject: [MMUSIC] Concern with status of draft-ietf-mmusic-4572-update I do not think that draft-ietf-mmusic-4572-update can should be an "update"= to 4572. RFC 4572 is widely deployed and the deployments are not going to = be changed to incorporate this update. Having customers tell me equipment i= s not 4572 compliant because it does not implement this is not good. It wil= l lead to interoperability problems where some people do this and others do= not. For example, a 4572 is unlikely to include a SHA-256 fingerprint yet = someone reading this update might make there systeme require the SHA-256 si= nce this says it is a MUST.=20 Instead I think this should be written as an extension to 4572 and JSEP and= WebRTC should normatively reference it.=20 For backwards compatibility, I think that including SHA-1 as wells as SHA-= 256 should be a MUST _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From nobody Fri Aug 26 10:36:56 2016 Return-Path: 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 0B72A12D192; Fri, 26 Aug 2016 10:36:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 T268DdnoEu1L; Fri, 26 Aug 2016 10:36:47 -0700 (PDT) Received: from mail-yb0-x231.google.com (mail-yb0-x231.google.com [IPv6:2607:f8b0:4002:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDFCF12D16D; Fri, 26 Aug 2016 10:36:43 -0700 (PDT) Received: by mail-yb0-x231.google.com with SMTP id h3so8211825ybi.2; Fri, 26 Aug 2016 10:36:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Ub09fJ9UDV3ogJXAH0GRE6Y9c3r/l0YGNBIoE2sq8S8=; b=SE1kzV/nbnY9yTAwSJ3ZaldQ0YVnBwq+hXZHqLX7aqNfxr2svIJkges7Ix8WwiWnb0 BjZIQXb1TsCNU4OnGA7oPwIxtFVJNlQzEjg1ggArmF+49MT5SYzfRBBCHtsmuXmb+D1o eAsweBuTmcKDUkacaSB0Y3SudLxumQexiZrq+4FH8ren8sTEHdhwHUQqNW0fIPLErXPf tQzlDgUWdFMGoX5ochbCuLqwNeCRZQcOqqAyQtSGCNpVy4xDmkOMSNJS+e0L9oa3P6LT /jIWddH+26JN07eQiDxXomOaj9s7BdClJhxddYEC5ovB9zQaDcud8PcCnGumitdyP1YL l2gg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Ub09fJ9UDV3ogJXAH0GRE6Y9c3r/l0YGNBIoE2sq8S8=; b=TB8WjlPsbglhA7HhFsNKj591+Oe49xrilbrOk5U7JiyvkvN/ZzwuY5Qg9AhGSqhpz6 +nqWoIqyX+6AphHW+AkFa1cbmOlGbrpUCJTtLX7GXnJmwdy1OSFq092+9Cgf9XTx+MSg zntB/BdZb6DmsA9I8BtIsV4gd24hl7BBMPX6L7fz3kov+FDRw1OMEiuRCXDdNzE8oETz wQfnQV54TiRAyZu1bmGdQpfuef1No7cRpf46YFqrIcRdk1xjZDhIva+cChguQdYK65oA PfxWmOWpkk2QWq6fUp+eIKz0AwFQgE67xssMP0zp5jYjgt76JeI3bHzlYsgamBpEFugl yB/g== X-Gm-Message-State: AE9vXwPksPebIOJlgyASbKFtYwMtOC2XPY9VM/w5cP1EvxbsxKr9Nx49zZ2oE8ywCrZQrWVx7i4GfWiMGkdDyg== X-Received: by 10.37.230.75 with SMTP id d72mr3886344ybh.171.1472233002975; Fri, 26 Aug 2016 10:36:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.121.3 with HTTP; Fri, 26 Aug 2016 10:36:42 -0700 (PDT) In-Reply-To: <20160713161804.16141.52470.idtracker@ietfa.amsl.com> References: <20160713161804.16141.52470.idtracker@ietfa.amsl.com> From: Suhas Nandakumar Date: Fri, 26 Aug 2016 10:36:42 -0700 Message-ID: To: ietf@ietf.org, dromasca@gmail.com Content-Type: multipart/alternative; boundary=94eb2c0a88122b4d3b053afcf5e3 Archived-At: Cc: Ben Campbell , draft-ietf-mmusic-sdp-mux-attributes@ietf.org, mmusic WG , IETF-Announce , mmusic-chairs@ietf.org Subject: Re: [MMUSIC] Last Call: (A Framework for SDP Attributes when Multiplexing) to Proposed Standard X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2016 17:36:49 -0000 --94eb2c0a88122b4d3b053afcf5e3 Content-Type: text/plain; charset=UTF-8 Hello All As part of GEN-ART review for draft-ietf-mmusic-sdp-mux-attributes-13 there were few points discussed that calls for a wider attention before rolling out the next draft update. Here is the summary of the review comments and subsequent changes that will be planned in the next version of the draft GEN-ART Review by Dan Romanscanu ------------------------------------------------------- 1. Process to register new Multiplexing Categories: Today the draft says any new category is registered based on "first-come first-serve basis" and the proposed update is to following RFC5226 "Standards Action" procedures for registering new multiplexing categories in the future. 2. Process to update the "Mux Category" Column Values in the registry for a given SDP attribute: The draft says such an update requires a new specification. The update plan will be on the lines "Updates to the Mux Category column values will follow the existing registration policy of the affected table" This aligns with the Section 8.2.4.2 of draft-ietf-mmusic-rfc4566bis-17 3. Process to add entry to the "Mux Category" column for a new SDP attribute: Again following steps similar to point 2, the plan is to align it to Section 8.2.4.1 of draft-ietf-mmusic-rfc4566bis-17 Please let us know your inputs/concerns on the above changes. Thanks Suhas Nandakumar On Wed, Jul 13, 2016 at 9:18 AM, The IESG wrote: > > The IESG has received a request from the Multiparty Multimedia Session > Control WG (mmusic) to consider the following document: > - 'A Framework for SDP Attributes when Multiplexing' > as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. The last call is extended due to crossing > an IETF meeting, and due to the length of the draft. Please send > substantive comments to the ietf@ietf.org mailing lists by 2016-08-10. > Exceptionally, comments may be sent to iesg@ietf.org instead. > In either case, please retain the beginning of the Subject line to > allow automated sorting. > > Abstract > > > The purpose of this specification is to provide a framework for > analyzing the multiplexing characteristics of Session Description > Protocol (SDP) attributes when SDP is used to negotiate the usage of > single 5-tuple for sending and receiving media associated with > multiple media descriptions. > > This specification also categorizes the existing SDP attributes based > on the framework described herein. > > > > > The file can be obtained via > https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-mux-attributes/ > > IESG discussion can be tracked via > https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-mux-a > ttributes/ballot/ > > > No IPR declarations have been submitted directly on this I-D. > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --94eb2c0a88122b4d3b053afcf5e3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello All

=C2=A0 =C2=A0 As part of GEN-= ART review for draft-ietf-mmusic-sdp-mux-attributes-13 there were few = points discussed that calls for a wider attention before rolling out the ne= xt draft update.
=C2=A0
Here is the summary of the revi= ew comments and subsequent changes that will be planned in the next version= of the draft



GEN-AR= T Review by=C2=A0Dan Romanscanu
-----------------= --------------------------------------

1. Process = to register new Multiplexing Categories:

=C2=A0 = =C2=A0Today the draft says any new category is registered based on =C2=A0&q= uot;first-come first-serve basis" and the proposed update is to follow= ing RFC5226 "Standards Action" procedures for registering new mul= tiplexing categories in the future.

2. Process to = update the "Mux Category" Column Values in the registry for a giv= en SDP attribute:

=C2=A0The draft says such an upd= ate requires a new specification. The update plan will be on the lines=C2= =A0
<snip>
=C2=A0"Updates to th= e Mux Category column values will follow the existing=C2=A0= registration policy of the affected table"=C2=A0
</snip>

This aligns with the Section 8.2.4.2 of=C2=A0draft-ietf-mmusic-rfc4566bi= s-17

3. Process to add entry to the "Mux Category" col= umn =C2=A0for a new SDP attribute:

=C2=A0 A= gain following steps similar to point 2, the plan is to align it to Section= 8.2.4.1 of=C2=A0draft-ietf-mmusic-rfc4566bis-17

<= br>
Please let us know your inputs/concerns on the above changes.=



Thanks=C2=A0
<= div>Suhas Nandakumar


On Wed, Jul 13, 2016 at 9:18 AM, The IESG <i= esg-secretary@ietf.org> wrote:

The IESG has received a request from the Multiparty Multimedia Session
Control WG (mmusic) to consider the following document:
- 'A Framework for SDP Attributes when Multiplexing'
=C2=A0 <draft-ietf-mmusic-sdp-mux-attributes-13.txt> as Proposed= Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. The last call is extended due to crossing an IETF meeting, and due to the length of the draft. Please send
substantive comments to the ietf@ietf.org mailing lists by 2016-08-10.
Exceptionally, comments may be sent to iesg@ietf.org instead.
In either case, please retain the beginning of the Subject line to
=C2=A0allow automated sorting.

Abstract


=C2=A0 =C2=A0The purpose of this specification is to provide a framework fo= r
=C2=A0 =C2=A0analyzing the multiplexing characteristics of Session Descript= ion
=C2=A0 =C2=A0Protocol (SDP) attributes when SDP is used to negotiate the us= age of
=C2=A0 =C2=A0single 5-tuple for sending and receiving media associated with=
=C2=A0 =C2=A0multiple media descriptions.

=C2=A0 =C2=A0This specification also categorizes the existing SDP attribute= s based
=C2=A0 =C2=A0on the framework described herein.




The file can be obtained via
https://datatracker.ietf.org/d= oc/draft-ietf-mmusic-sdp-mux-attributes/

IESG discussion can be tracked via
https://datatracker.iet= f.org/doc/draft-ietf-mmusic-sdp-mux-attributes/ballot/


No IPR declarations have been submitted directly on this I-D.


_______________________________________________
mmusic mailing list
mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic

--94eb2c0a88122b4d3b053afcf5e3-- From nobody Sat Aug 27 09:59:01 2016 Return-Path: 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 E0BCC12D0CB for ; Sat, 27 Aug 2016 09:58:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 Wux9oPyXSq4d for ; Sat, 27 Aug 2016 09:58:57 -0700 (PDT) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED64F12B008 for ; Sat, 27 Aug 2016 09:58:56 -0700 (PDT) Received: by mail-yw0-x233.google.com with SMTP id z8so65466361ywa.1 for ; Sat, 27 Aug 2016 09:58:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=lGT4H7FpzWmVdPioiu6TY9b92Doxl8TnHcH8Deg3GIE=; b=O75NrAK8snSlaCGRsoR9GWPIYvWl5G3s651Tt2eIg1rI4pcPiWG5rEidvKF1mNnx+2 zKXZR+eymNjwFG6caXntAKIycRJUM4GkyYUnKqrz+z1OOa8iZIwoAtfIb4kLadEBxYmL D8WfDU0/MLaaMBEdTNCBYck358TPdRUemjwKQTkaAsnNWelJAQL0IA61/TT+RoDd+Ub8 DjMpqqDhlCceg2NtYM6rvj/vISjGw7eiqPUo/7/LkLKY7+IBT0I35i+kxnqenWmcWhNI sFaDWsso/l+TKsUeH8Dr9f7fHNB3imwNWXlZe375JAIASPVkMLjbd4OLt93K9IbnUUcl u2pw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=lGT4H7FpzWmVdPioiu6TY9b92Doxl8TnHcH8Deg3GIE=; b=JxMB6ifyD7KDyKQHC6WobCeOlFCsJHsu1JuI2rCTXRNZoSzETdnWoIWGQ195g/OavX jJjIgTWkiwaFMo2GniDQJIhjw84HbtKfzTBk/NcofhRW0PKfnE0f7xRnyqgF9meuKwp2 dKiyDzHG9Q8loo2wC1LzA8Zkqly8ldUKkCfOvukjfk5+LKw5xF+bOyLg9Tn75FxSeSgB Fsj0D1/qkQLXzrD4AH33Dhy+8cb7G907+bN9kMQ15OYH13i7JJret2vGlQKcV3wmcX3M +Vb+UhrsiaXDtQuLqZLHXUiNOu6NpV6MrIodTZM7n1GNgQ02MhxB/t01pXwIcSmHQSC/ 46dg== X-Gm-Message-State: AE9vXwOD+l93xxW38J7gLMcqqRd/yE7oN95yiPGNhDAH1UkYDK9f4iU5c7vqN9aQEGYux1xONcGHTKMWwKTkBg== X-Received: by 10.13.221.198 with SMTP id g189mr8281035ywe.93.1472317135907; Sat, 27 Aug 2016 09:58:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.48.193 with HTTP; Sat, 27 Aug 2016 09:58:15 -0700 (PDT) From: Eric Rescorla Date: Sat, 27 Aug 2016 09:58:15 -0700 Message-ID: To: mmusic WG Content-Type: multipart/alternative; boundary=94eb2c0779cee222fb053b108bd7 Archived-At: Subject: [MMUSIC] Review of draft-ietf-mmusic-sdp-bundle-negotiation-32 (Part I) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Aug 2016 16:58:59 -0000 --94eb2c0779cee222fb053b108bd7 Content-Type: text/plain; charset=UTF-8 I have reviewed the first half of this document (up through the examples). The following comments apply only to that. OVERALL The overall framing of this document as being about attaching multiple m= sections to a single "shared address" is extremely problematic, for two reasons: - With ICE there isn't actually any notion of a shared address except in some vague sense. I suppose you could argue that because with ICE you are required to specify a port on the m= line then you still have a concept of an address, but that's not true in trickle ICE, where the port is 9, so all m= lines share the same address/port. So, actually when you use trickle a whole bunch of the statements in this document are wrong. - A lot more is being overloaded here than addresses. In fact, a whole pile of semantics are being overloaded, so the way to think about this is actually as gluing a whole bunch of m= lines together at the transport level. I think the right concept here is not "shared address" but "bundle group" and the document should be written in that way, namely that there are a bunch of m= lines in a bundle group and the one with the bundle tag is the one that sets all the shared parameters. The document is badly in need of some overall framing that explains what we are trying to accomplish and the rationale for why any particular m= section property needs to be the same for all members of a bundle group and why other ones do not. I'm not saying it's necessarily bad to be explicit in (for instance Sections 11 and 12) but it would be better if it were clear where these rules come from. One way to deal with this would be to simply defer this to the mux-attributes draft. I'll just note again that I find the overloading of "associated" makes this document very hard to read. At minimum it would be best to talk about an m= line as "belonging" to a BUNDLE group. If others agree I would be happy to provide a PR that cleans this up. MAJOR TECHNICAL Maybe I missed this, but I don't see any requirement that m= lines appear in the a=group:BUNDLE line in the order they appear in the SDP. That would make life a lot easier. DETAILED COMMENTS (MIXED EDITORIAL/TECHNICAL) S 1. This really needs some explanation of why you would want this feature. S 2; Initial offer. "The first offer, within" . This comma is superfluous. S 5. The first three grafs of this section seem to duplicate the intro and the abstract. Also, this claim about sharing a 5-tuple is not quite right with ICE because ICE can switch 5-tuples during aggressive nomination. S 6. The usage of the 'bundle-only' attribute is only defined for a bundled "m=" line with a zero port value, within an offer. Other usage is unspecified. It would probably be better to actually forbid this, because it seems like an interop problem if you somehow were to introduce it later. S 8. Nit: List the forward references in section order. S 8.1. This seems like a key concept: there are a number of different categories of attributes and some are shared with all members of a bundle group and some are not. To what extent is this draft just duplicative of those listed in the mux-attributes draft? S 8.2 and following Really would be useful to have some examples here to make it less abstract. S 8.3.3. It seems like the implication here is that an answerer cannot debundle something that was bundled in a previous o/a transaction. Can you make that point clearly? S 8.5. How does this interact with ICE Restart? S 8.5.2 When you say "extend" do you mean "add to the end"? S 10.1 In this first bullet is "if" "iff"? S 10.3.1.1. When an offerer generates an initial offer, the offerer MUST associate either an SDP 'rtcp-mux' attribute [RFC5761] or an SDP 'rtcp-mux-only' attribute [I-D.ietf-mmusic-mux-exclusive] with each bundled RTP-based "m=" line in the offer. The offerer MUST associate an SDP 'rtcp-mux-only' attribute with each bundle-only "m=" line. If the offerer associates a 'rtcp-mux-only' attribute with an "m=" line, the offerer may also associate a 'rtcp-mux' attribute with the same "m=" line, as described in [I-D.ietf-mmusic-mux-exclusive]. This is a particularly egregious case of associate disease that could be easily solved by using "add" when referring to the attributes you put in the m= section. S 11.1 When an offerer associates a unique address with a bundled "m=" line (excluding any bundle-only "m=" line), the offerer MUST associate SDP 'candidate' attributes (and other applicable ICE-related media-level SDP attributes), containing unique ICE properties (candidates etc), with the "m=" line, according to the procedures in [I-D.ietf-mmusic-ice-sip-sdp]. Here is an example of where the "address" framing doesn't work, if you are using trickle. --94eb2c0779cee222fb053b108bd7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have reviewed the first half of this document (up t= hrough the examples).
The following comments apply only to that.<= /div>

OVERALL
The overall framing of this docu= ment as being about attaching multiple
m=3D sections to a single = "shared address" is extremely problematic,
for two reas= ons:

- With ICE there isn't actually any notio= n of a shared address except
=C2=A0 in some vague sense. I suppos= e you could argue that because with
=C2=A0 ICE you are required t= o specify a port on the m=3D line then you
=C2=A0 still have a co= ncept of an address, but that's not true in
=C2=A0 trickle IC= E, where the port is 9, so all m=3D lines share the same
=C2=A0 a= ddress/port. So, actually when you use trickle a whole bunch of
= =C2=A0 the statements in this document are wrong.

= - A lot more is being overloaded here than addresses. In fact, a whole
=C2=A0 pile of semantics are being overloaded, so the way to think ab= out
=C2=A0 this is actually as gluing a whole bunch of m=3D lines= together at
=C2=A0 the transport level.

I think the right concept here is not "shared address" but "= ;bundle group"
and the document should be written in that wa= y, namely that there are
a =C2=A0bunch of m=3D lines in a bundle = group and the one with the bundle tag
is the one that sets all th= e shared parameters.



The document is badly in need of some overall framing that explains
<= div>what we are trying to accomplish and the rationale for why any
particular m=3D section property needs to be the same for all members of<= /div>
a bundle group and why other ones do not. I'm not saying it&#= 39;s
necessarily bad to be explicit in (for instance Sections 11 = and 12)
but it would be better if it were clear where these rules= come
from. One way to deal with this would be to simply defer th= is to the
mux-attributes draft.


I'll just note again that I find the overloading of "associ= ated" makes this
document very hard to read. At minimum it w= ould be best to talk about
an m=3D line as "belonging" = to a BUNDLE group. If others agree I would
be happy to provide a = PR that cleans this up.


MAJOR TECHN= ICAL
Maybe I missed this, but I don't see any requirement tha= t m=3D lines
appear in the a=3Dgroup:BUNDLE line in the order the= y appear in the
SDP. That would make life a lot easier.


DETAILED COMMENTS (MIXED EDITORIAL/TECHNICAL= )
S 1.
This really needs some explanation of why you wo= uld want this feature.

S 2; Initial offer.
"The first offer, within" . This comma is superfluous.

S 5.
The first three grafs of this section seem= to duplicate the intro
and the abstract.

Also, this claim about sharing a 5-tuple is not quite right with ICE
because ICE can switch 5-tuples during aggressive nomination.


S 6.
=C2=A0 =C2=A0The usage of t= he 'bundle-only' attribute is only defined for a
=C2=A0 = =C2=A0bundled "m=3D" line with a zero port value, within an offer= .=C2=A0 Other
=C2=A0 =C2=A0usage is unspecified.

It would probably be better to actually forbid this, because it se= ems
like an interop problem if you somehow were to introduce it l= ater.


S 8.
Nit:
List the forward references in section order.

S 8.1.
This seems like a key concept: there are a num= ber of different categories
of attributes and some are shared wit= h all members of a bundle group
and some are not. To what extent = is this draft just duplicative of those
listed in the mux-attribu= tes draft?


S 8.2 and following
Really would be useful to have some examples here to make it less
abstract.


S 8.3.3.
It seems like the implication here is that an answerer cannot debundle
something that was bundled in a previous o/a transaction. Can you
make that point clearly?


S = 8.5.
How does this interact with ICE Restart?

S 8.5.2
When you say "extend" do you mean "a= dd to the end"?

S 10.1
In this firs= t bullet is "if" "iff"?


S 10.3.1.1.
=C2=A0 =C2=A0When an offerer generates an in= itial offer, the offerer MUST
=C2=A0 =C2=A0associate either an SD= P 'rtcp-mux' attribute [RFC5761] or an SDP
=C2=A0 =C2=A0&= #39;rtcp-mux-only' attribute [I-D.ietf-mmusic-mux-exclusive] with each<= /div>
=C2=A0 =C2=A0bundled RTP-based "m=3D" line in the offer= .=C2=A0 The offerer MUST associate
=C2=A0 =C2=A0an SDP 'rtcp-= mux-only' attribute with each bundle-only "m=3D" line.=C2=A0 = If
=C2=A0 =C2=A0the offerer associates a 'rtcp-mux-only' = attribute with an "m=3D" line,
=C2=A0 =C2=A0the offerer= may also associate a 'rtcp-mux' attribute with the same
= =C2=A0 =C2=A0"m=3D" line, as described in [I-D.ietf-mmusic-mux-ex= clusive].

This is a particularly egregious case of= associate disease that could
be easily solved by using "add= " when referring to the attributes
you put in the m=3D secti= on.


S 11.1
=C2=A0 =C2=A0W= hen an offerer associates a unique address with a bundled "m=3D" = line
=C2=A0 =C2=A0(excluding any bundle-only "m=3D" lin= e), the offerer MUST associate SDP
=C2=A0 =C2=A0'candidate= 9; attributes (and other applicable ICE-related media-level
=C2= =A0 =C2=A0SDP attributes), containing unique ICE properties (candidates etc= ),
=C2=A0 =C2=A0with the "m=3D" line, according to the = procedures in
=C2=A0 =C2=A0[I-D.ietf-mmusic-ice-sip-sdp].

Here is an example of where the "address" frami= ng doesn't work, if you
are using trickle.

--94eb2c0779cee222fb053b108bd7-- From nobody Mon Aug 29 12:54:47 2016 Return-Path: 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 8B6E512D870 for ; Mon, 29 Aug 2016 12:54:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 iVAZewISeNph for ; Mon, 29 Aug 2016 12:54:33 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 268EC12D86D for ; Mon, 29 Aug 2016 12:54:32 -0700 (PDT) X-AuditID: c1b4fb2d-917ff700000019a3-58-57c492f43593 Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.183.30]) by (Symantec Mail Security) with SMTP id 8B.6D.06563.4F294C75; Mon, 29 Aug 2016 21:54:31 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.211]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.03.0301.000; Mon, 29 Aug 2016 21:54:27 +0200 From: Christer Holmberg To: Eric Rescorla , mmusic WG Thread-Topic: [MMUSIC] Review of draft-ietf-mmusic-sdp-bundle-negotiation-32 (Part I) Thread-Index: AQHSAc2sXYvXe1Yg9UqTnzo8t0FYbQ== Date: Mon, 29 Aug 2016 19:54:27 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BC722B7@ESESSMB209.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.5.160527 x-originating-ip: [153.88.183.150] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B4BC722B7ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrIIsWRmVeSWpSXmKPExsUyM2K7nO73SUfCDXbPE7BY8focu8XU5Y9Z HJg8liz5yeQx+XEbcwBTFJdNSmpOZllqkb5dAldG38QJbAXzvzFVzG1oZWpg3HmGqYuRg0NC wERi3l2nLkYuDiGB9YwSh1/sY4dwljBKnPp2hx2kiE3AQqL7n3YXIyeHiICtRE/vEUYQW1gg TGLihpNMEPFwicNP/0PZehJnrm1mBrFZBFQlPj85yAZi8wr4SvzZeokdxBYSCJDo+j+DFcTm FAiUOHL3GVgvo4CYxPdTa8BsZgFxiVtP5oPZEgICEkv2nGeGsEUlXj7+B9YrCrTr+9fZUHEl iRXbLzFC9OZLvHn4mhlir6DEyZlPWCYwisxCMnYWkrJZSMog4joSC3Z/YoOwtSWWLYSoAbHP HHgM1WstMWPLDkZkNQsYOVYxihanFhfnphsZ66UWZSYXF+fn6eWllmxiBEbcwS2/dXcwrn7t eIhRgINRiYdXoeJIuBBrYllxZe4hRgkOZiUR3vkTgUK8KYmVValF+fFFpTmpxYcYpTlYlMR5 /V8qhgsJpCeWpGanphakFsFkmTg4pRoYoxQF58RqZlUYOClvrchqPyYz8cv2PWvqzBUtvOZs uFCi+oc/702GdUjjfP6F9XeO1zoovFy13+3fYtkNDieM3Aqk3/7qyVdzi3ilvlbz/S1t70ub PYqtzuuI2TAqy/Ap7XumdmWiWPbL9V9qH+0pm9CSlKDf9+RtpfLlB6sEq5muPHhzuMJQiaU4 I9FQi7moOBEA+vRns7QCAAA= Archived-At: Subject: Re: [MMUSIC] Review of draft-ietf-mmusic-sdp-bundle-negotiation-32 (Part I) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2016 19:54:42 -0000 --_000_7594FB04B1934943A5C02806D1A2204B4BC722B7ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ekr, Thanks for the comments! Please see inline. OVERALL >The overall framing of this document as being about attaching multiple >m=3D sections to a single "shared address" is extremely problematic, >for two reasons: > >- With ICE there isn't actually any notion of a shared address except > in some vague sense. I suppose you could argue that because with > ICE you are required to specify a port on the m=3D line then you > still have a concept of an address, but that's not true in > trickle ICE, where the port is 9, so all m=3D lines share the same > address/port. So, actually when you use trickle a whole bunch of > the statements in this document are wrong. > >- A lot more is being overloaded here than addresses. In fact, a whole > pile of semantics are being overloaded, so the way to think about > this is actually as gluing a whole bunch of m=3D lines together at > the transport level. > > I think the right concept here is not "shared address" but "bundle group" > and the document should be written in that way, namely that there are > a bunch of m=3D lines in a bundle group and the one with the bundle tag > is the one that sets all the shared parameters. It is true that the actual port value in the m- line, and the IP address in= the c- line address, represent the address that is actually being used. But, even with ICE there is a shared address, isn't there? Yes, that shared= address may change, but at any given time there will be one address that i= s shared among the media streams within the BUNDLE group. Or? > The document is badly in need of some overall framing that explains > what we are trying to accomplish and the rationale for why any > particular m=3D section property needs to be the same for all members of > a bundle group and why other ones do not. I'm not saying it's > necessarily bad to be explicit in (for instance Sections 11 and 12) > but it would be better if it were clear where these rules come > from. One way to deal with this would be to simply defer this to the > mux-attributes draft. Ok, I'll look into that. People are also welcome to provide text suggestion= s. > I'll just note again that I find the overloading of "associated" makes th= is > document very hard to read. At minimum it would be best to talk about > an m=3D line as "belonging" to a BUNDLE group. If others agree I would > be happy to provide a PR that cleans this up. The intention is to say "m=3D line within a BUNDLE group". If there are ins= tances of "associated" I am happy to fix that. MAJOR TECHNICAL > Maybe I missed this, but I don't see any requirement that m=3D lines > appear in the a=3Dgroup:BUNDLE line in the order they appear in the > SDP. That would make life a lot easier. There is no such requirement. AFAIR, it was discussed at some point, but it was agreed to not mandate m- = lines to be listed in the order of preference (as far as selecting the BUND= LE address is concerned). Also, if you mid-session adds a new m- line, and wants that to represent th= e new BUNDLE address you have to place the new m- line after the existing m= - lines, but you have to place it first in the a=3Dgroup:BUNDLE attribute l= ist. DETAILED COMMENTS (MIXED EDITORIAL/TECHNICAL) >S 1. >This really needs some explanation of why you would want this feature. You represent the community that wants the feature, so feel free to suggest= some text explaining why you want it :) >S 2; Initial offer. >"The first offer, within" . This comma is superfluous. Will be fixed. >S 5. >The first three grafs of this section seem to duplicate the intro >and the abstract. > >Also, this claim about sharing a 5-tuple is not quite right with ICE >because ICE can switch 5-tuples during aggressive nomination. Yes. But, at any given time there will only be one 5-tuple, won't it? >S 6. > The usage of the 'bundle-only' attribute is only defined for a > bundled "m=3D" line with a zero port value, within an offer. Other > usage is unspecified. > > It would probably be better to actually forbid this, because it seems > like an interop problem if you somehow were to introduce it later. Ok, I'll look into that. >S 8. >Nit: >List the forward references in section order. Will be fixed. >S 8.1. >This seems like a key concept: there are a number of different categories >of attributes and some are shared with all members of a bundle group >and some are not. To what extent is this draft just duplicative of those >listed in the mux-attributes draft? Not sure I understand the question. >S 8.2 and following >Really would be useful to have some examples here to make it less >abstract. You don't think the examples in section 17 are enough? You want examples in= the normative sections describing how to create offers, answers etc? >S 8.3.3. >It seems like the implication here is that an answerer cannot debundle >something that was bundled in a previous o/a transaction. Can you >make that point clearly? Ok, I'll look into that. >S 8.5. >How does this interact with ICE Restart? >From a pure ICE Restart perspective, I don't see any conflict. ICE Restart = is triggered by changing the user name and password, and the text does not = forbid that. If you also want to change the BUNDLE address, you follow the rules in sect= ion 8.5.1. >S 8.5.2 >When you say "extend" do you mean "add to the end"? Yes. I can fix that. >S 10.1 >In this first bullet is "if" "iff"? "iff"? >S 10.3.1.1. > When an offerer generates an initial offer, the offerer MUST > associate either an SDP 'rtcp-mux' attribute [RFC5761] or an SDP > 'rtcp-mux-only' attribute [I-D.ietf-mmusic-mux-exclusive] with each > bundled RTP-based "m=3D" line in the offer. The offerer MUST associate > an SDP 'rtcp-mux-only' attribute with each bundle-only "m=3D" line. If > the offerer associates a 'rtcp-mux-only' attribute with an "m=3D" line, > the offerer may also associate a 'rtcp-mux' attribute with the same > "m=3D" line, as described in [I-D.ietf-mmusic-mux-exclusive]. > > This is a particularly egregious case of associate disease that could > be easily solved by using "add" when referring to the attributes > you put in the m=3D section. People have previously said that you don't "add" attributes to m- lines: yo= u add port values etc, but not attributes. This is an example of where I've had to re-write big parts of the documents= a number of times already, because every time someone else reads the docum= ent he/she is not happy with the terminology. I just don't want to do it ag= ain. >S 11.1 > When an offerer associates a unique address with a bundled "m=3D" line > (excluding any bundle-only "m=3D" line), the offerer MUST associate SDP > 'candidate' attributes (and other applicable ICE-related media-level > SDP attributes), containing unique ICE properties (candidates etc), > with the "m=3D" line, according to the procedures in > [I-D.ietf-mmusic-ice-sip-sdp]. > > Here is an example of where the "address" framing doesn't work, if you > are using trickle. See top of e-mail. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B4BC722B7ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-ID: <0AF2320DA5C3354DBF596821DF7D3C2E@ericsson.com> Content-Transfer-Encoding: quoted-printable

Hi Ekr,

 

Thanks for the comments! Please see inl= ine.

 

OVERALL

 

>The overall framing of this documen= t as being about attaching multiple

>m=3D sections to a single "sha= red address" is extremely problematic,

>for two reasons:<= /p>

> 

>- With ICE there isn't actually any= notion of a shared address except

>  in some vague sense. I suppo= se you could argue that because with

>  ICE you are required to spec= ify a port on the m=3D line then you

>  still have a concept of an a= ddress, but that's not true in

>  trickle ICE, where the port = is 9, so all m=3D lines share the same

>  address/port. So, actually w= hen you use trickle a whole bunch of

>  the statements in this docum= ent are wrong.

> 

>- A lot more is being overloaded he= re than addresses. In fact, a whole

>  pile of semantics are being = overloaded, so the way to think about

>  this is actually as gluing a= whole bunch of m=3D lines together at

>  the transport level.

> 

> I think the right concept here is = not "shared address" but "bundle group"

> and the document should be written= in that way, namely that there are

> a  bunch of m=3D lines in a b= undle group and the one with the bundle tag

> is the one that sets all the share= d parameters.

 

It is true that the actual port value i= n the m- line, and the IP address in the c- line address, represent the add= ress that is actually being used.

 

But, even with ICE there is a shared ad= dress, isn’t there? Yes, that shared address may change, but at any g= iven time there will be one address that is shared among the media streams within the BUNDLE group. Or?

 

 

> The document is badly in need of s= ome overall framing that explains

> what we are trying to accomplish a= nd the rationale for why any

> particular m=3D section property n= eeds to be the same for all members of

> a bundle group and why other ones = do not. I'm not saying it's

> necessarily bad to be explicit in = (for instance Sections 11 and 12)

> but it would be better if it were = clear where these rules come

> from. One way to deal with this wo= uld be to simply defer this to the

> mux-attributes draft.

 

Ok, I’ll look into that. People a= re also welcome to provide text suggestions.

 

 

> I'll just note again that I find t= he overloading of "associated" makes this

> document very hard to read. At min= imum it would be best to talk about

> an m=3D line as "belonging&qu= ot; to a BUNDLE group. If others agree I would

> be happy to provide a PR that clea= ns this up.

 

The intention is to say “m=3D lin= e within a BUNDLE group”. If there are instances of “associated= ” I am happy to fix that.

 

 

 

MAJOR TECHNICAL

 

> Maybe I missed this, but I don't s= ee any requirement that m=3D lines

> appear in the a=3Dgroup:BUNDLE lin= e in the order they appear in the

> SDP. That would make life a lot ea= sier.

 

There is no such requirement.

 

AFAIR, it was discussed at some point, = but it was agreed to not mandate m- lines to be listed in the order of pref= erence (as far as selecting the BUNDLE address is concerned).

 

Also, if you mid-session adds a new m- = line, and wants that to represent the new BUNDLE address you have to place = the new m- line after the existing m- lines, but you have to place it first in the a=3Dgroup:BUNDLE attribute list.

 

 

 

DETAILED COMMENTS (MIXED EDITORIAL/TECH= NICAL)

 

>S 1.

>This really needs some explanation = of why you would want this feature.

 

You represent the community that wants = the feature, so feel free to suggest some text explaining why you want it := )

 

 

>S 2; Initial offer.

>"The first offer, within"= . This comma is superfluous.

 

Will be fixed.

 

 

>S 5.

>The first three grafs of this secti= on seem to duplicate the intro

>and the abstract.=

> 

>Also, this claim about sharing a 5-= tuple is not quite right with ICE

>because ICE can switch 5-tuples dur= ing aggressive nomination.

 

Yes. But, at any given time there will = only be one 5-tuple, won’t it?

 

 

>S 6.

>   The usage of the 'bundle-on= ly' attribute is only defined for a

>   bundled "m=3D" li= ne with a zero port value, within an offer.  Other

>   usage is unspecified.<= /o:p>

> 

> It would probably be better to act= ually forbid this, because it seems

> like an interop problem if you som= ehow were to introduce it later.

 

Ok, I’ll look into that.

 

 

>S 8.

>Nit:

>List the forward references in sect= ion order.

 

Will be fixed.

 

 

>S 8.1.

>This seems like a key concept: ther= e are a number of different categories

>of attributes and some are shared w= ith all members of a bundle group

>and some are not. To what extent is= this draft just duplicative of those

>listed in the mux-attributes draft?=

 

Not sure I understand the question.

 

 

>S 8.2 and following

>Really would be useful to have some= examples here to make it less

>abstract.

 

You don’t think the examples in s= ection 17 are enough? You want examples in the normative sections describin= g how to create offers, answers etc?

 

 

>S 8.3.3.

>It seems like the implication here = is that an answerer cannot debundle

>something that was bundled in a pre= vious o/a transaction. Can you

>make that point clearly?=

 

Ok, I’ll look into that.

 

 

>S 8.5.

>How does this interact with ICE Res= tart?

 

From a pure ICE Restart perspective, I = don’t see any conflict. ICE Restart is triggered by changing the user= name and password, and the text does not forbid that.

 

If you also want to change the BUNDLE a= ddress, you follow the rules in section 8.5.1.

 

 

>S 8.5.2

>When you say "extend" do = you mean "add to the end"?

 

Yes. I can fix that.<= /p>

 

 

>S 10.1

>In this first bullet is "if&qu= ot; "iff"?

 

“iff”?

 

 

>S 10.3.1.1.

>   When an offerer generates a= n initial offer, the offerer MUST

>   associate either an SDP 'rt= cp-mux' attribute [RFC5761] or an SDP

>   'rtcp-mux-only' attribute [= I-D.ietf-mmusic-mux-exclusive] with each

>   bundled RTP-based "m= =3D" line in the offer.  The offerer MUST associate

>   an SDP 'rtcp-mux-only' attr= ibute with each bundle-only "m=3D" line.  If

>   the offerer associates a 'r= tcp-mux-only' attribute with an "m=3D" line,

>   the offerer may also associ= ate a 'rtcp-mux' attribute with the same

>   "m=3D" line, as d= escribed in [I-D.ietf-mmusic-mux-exclusive].

> 

> This is a particularly egregious c= ase of associate disease that could

> be easily solved by using "ad= d" when referring to the attributes

> you put in the m=3D section.<= /o:p>

 

People have previously said that you do= n’t “add” attributes to m- lines: you add port values etc= , but not attributes.

 

This is an example of where I’ve = had to re-write big parts of the documents a number of times already, becau= se every time someone else reads the document he/she is not happy with the terminology. I just don’t want to do it again.=

 

 

>S 11.1

>   When an offerer associates = a unique address with a bundled "m=3D" line

>   (excluding any bundle-only = "m=3D" line), the offerer MUST associate SDP

>   'candidate' attributes (and= other applicable ICE-related media-level

>   SDP attributes), containing= unique ICE properties (candidates etc),

>   with the "m=3D" l= ine, according to the procedures in

>   [I-D.ietf-mmusic-ice-sip-sd= p].

> 

> Here is an example of where the &q= uot;address" framing doesn't work, if you

> are using trickle.

 

See top of e-mail.

 

 

Regards,

 

Christer

 

--_000_7594FB04B1934943A5C02806D1A2204B4BC722B7ESESSMB209erics_-- From nobody Tue Aug 30 05:26:54 2016 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E93412D0EC; Tue, 30 Aug 2016 05:26:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.31.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147256001324.23793.13439162063923402996.idtracker@ietfa.amsl.com> Date: Tue, 30 Aug 2016 05:26:53 -0700 Archived-At: Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sctp-sdp-17.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2016 12:26:53 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control of the IETF. Title : Stream Control Transmission Protocol (SCTP)-Based Media Transport in the Session Description Protocol (SDP) Authors : Christer Holmberg Salvatore Loreto Gonzalo Camarillo Filename : draft-ietf-mmusic-sctp-sdp-17.txt Pages : 24 Date : 2016-08-30 Abstract: The Stream Control Transmission Protocol (SCTP) is a transport protocol used to establish associations between two endpoints. This specification describes how to describe SCTP associations using the Session Description Protocol (SDP), and defines the following new SDP Media Description protocol identifiers (proto values):'SCTP', 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP'. The specification also describes how to use the new proto values together with the SDP Offer/Answer mechanism in order to negotiate and establish SCTP associations, and how to indicate the SCTP application usage. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-sctp-sdp/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mmusic-sctp-sdp-17 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sctp-sdp-17 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Aug 30 05:37:05 2016 Return-Path: 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 0911F12D1D1; Tue, 30 Aug 2016 05:37:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 BYSlljnaWlI0; Tue, 30 Aug 2016 05:37:02 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F14C412D1AE; Tue, 30 Aug 2016 05:37:01 -0700 (PDT) X-AuditID: c1b4fb2d-cf87d980000019a3-6b-57c57dec08d6 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by (Symantec Mail Security) with SMTP id 9F.1E.06563.CED75C75; Tue, 30 Aug 2016 14:37:00 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.211]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0301.000; Tue, 30 Aug 2016 14:36:35 +0200 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: Draft new version: draft-ietf-mmusic-sctp-sdp-17 Thread-Index: AQHSArskDEPPt5KrhkOvoRUsLMd3vQ== Date: Tue, 30 Aug 2016 12:36:34 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.5.160527 x-originating-ip: [153.88.183.18] Content-Type: multipart/alternative; boundary="_000_D3EB5997E33Fchristerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnkeLIzCtJLcpLzFFi42KZGbFdS/dN7dFwgxUbRS3O71zPZDF1+WMW ByaPJUt+MgUwRnHZpKTmZJalFunbJXBl3Pp+m7ngmVLFtWdf2BsYe2W7GDk5JARMJOa3NrN0 MXJxCAmsZ5ToerwaylnCKLF4yhH2LkYODjYBC4nuf9ogDSIC6hJf9/Ywg9jMAqYSD1+tYQSx hQUsJZ7t6maBqLGT2DltByOErSfxeMYUsHoWAVWJpQuusYHYvAJWEs+fTmACsRkFxCS+n1rD BDFTXOLWk/lMEMcJSCzZc54ZwhaVePn4HyuILQo08/vX2VBxRYmPr/YxQvTGSzycNJ0FYr6g xMmZT1gmMArPQjJ2FpKyWUjKIOIGEu/PzWeGsLUlli18DWXrS2z8cpYRwraW+PCwjQlZzQJG jlWMosWpxcW56UbGeqlFmcnFxfl5enmpJZsYgdF0cMtv3R2Mq187HmIU4GBU4uFVqDgSLsSa WFZcmXuIUYKDWUmE91fN0XAh3pTEyqrUovz4otKc1OJDjNIcLErivP4vFcOFBNITS1KzU1ML UotgskwcnFINjMuWf41f+jHiXEOA+f4UQ/OD65XZ3Jcvj5JzCPWYdyHV6FSXp0tp0v740PD5 Ezml9bXndfFf5ox+xeDgMHOa4zf2z9GdfK8dbmu6T5KYepZr3rHe6Ffp3CG7Nj/pnGSkbz4n jH12bEUA58ld+q+nl5dVCCYKCb3I3iEw+fLxayxLmD+JqqwSUGIpzkg01GIuKk4EAG4dTzii AgAA Archived-At: Cc: "mmusic-chairs@ietf.org" Subject: [MMUSIC] Draft new version: draft-ietf-mmusic-sctp-sdp-17 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2016 12:37:04 -0000 --_000_D3EB5997E33Fchristerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, The new version (-17) of draft-ietf-mmusic-sctp-sdp has finally been submit= ted. -The draft now takes draft-dtls-sdp and draft-4572-update into consideratio= n. -The procedures associated with SCTP/DTLS (DTLS over SCTP) have been remove= d, as nobody indicated a need to keep them. When it comes to the management of SCTP associations, DTLS associations and= TCP connections, the previous version of the draft took an approach from a= n SDP attribute perspective. In the new version, the draft takes an approac= h from an association/connection perspective, describes how each layer is m= anaged and how/if/which SDP attribute impact the association/connection. Th= e text also clarifies that each association/connection is managed independe= ntly of each other. For example, it is possible to re-establish an DTLS ass= ociation without touching the overlaying SCTP association, etc. NOTE: The draft now says that, since each SCTP endpoint is always =91active= =92, and both establish the SCTP association, the SDP =91setup=92 attribute= is not used for SCTP. IF someone thinks there is a use-case where a separa= tion of active and passive SCTP endpoint is needed, please bring it to the = list. There are no changes to how the SDP setup attribute impact the DTLS r= oles (client/server) and the TCP roles (active/passive). The draft was previously already in WGLC, but due to the changes in the lat= est version we should probably wait a bit before we continue the WGLC. I en= courage everyone to take a look =96 especially the browser/JSEP folks. I=92d like to give a special Thank You to Roman Shpount, for the input and = feedback he has given off-line. Regards, Christer --_000_D3EB5997E33Fchristerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi,

The new version (-17) of draft-ietf-mmusic-sctp-sdp has finally b= een submitted.

-The draft now takes draft-dtls-sdp and draft-4572-update into conside= ration.
-The procedures associated with SCTP/DTLS (DTLS over SCTP) have been r= emoved, as nobody indicated a need to keep them. 

When it comes to the management of SCTP associations, DTLS association= s and TCP connections, the previous version of the draft took an approach f= rom an SDP attribute perspective. In the new version, the draft takes an ap= proach from an association/connection perspective, describes how each layer is managed and how/if/which SDP attr= ibute impact the association/connection. The text also clarifies that each = association/connection is managed independently of each other. For example,= it is possible to re-establish an DTLS association without touching the overlaying SCTP association, etc.=

NOTE: The draft now says that, since each SCTP endpoint is always =91a= ctive=92, and both establish the SCTP association, the SDP =91setup=92 attr= ibute is not used for SCTP. IF someone thinks there is a use-case where a s= eparation of active and passive SCTP endpoint is needed, please bring it to the list. There are no changes to how the SD= P setup attribute impact the DTLS roles  (client/server) and the TCP r= oles (active/passive).

The draft was previously already in WGLC, but due to the changes in th= e latest version we should probably wait a bit before we continue the WGLC.= I encourage everyone to take a look =96 especially the browser/JSEP folks.=

I=92d like to give a special Thank You to Roman Shpount, for the input= and feedback he has given off-line.

Regards,

Christer 
--_000_D3EB5997E33Fchristerholmbergericssoncom_-- From nobody Tue Aug 30 15:54:59 2016 Return-Path: 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 0061912D833 for ; Tue, 30 Aug 2016 15:54:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.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 nMDTUoPIMSnm for ; Tue, 30 Aug 2016 15:54:52 -0700 (PDT) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2271412D74E for ; Tue, 30 Aug 2016 15:54:52 -0700 (PDT) Received: by mail-it0-x233.google.com with SMTP id n75so13900987ith.1 for ; Tue, 30 Aug 2016 15:54:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to:cc; bh=XshMkqMod9U8Lvfa1S+jlzxMsIHtv/qiD7Q98rTq/+w=; b=m+weqNSq5JvztqXnxw/BbcnX9TwXMwi0JkChwOWrbB3dERIJWw5+ctVnXA2IOXS83f TMxCjkTEKRAi8vm+YWrQVFeMSEBlyrM020brZJ7mAmpZYIttuoZIRpqAMjUucwY1uIaf owqTP7UHG4/cGWEFrS8l32YbrVLvuHwuFSnXqFIwdpPnHT3QfVVdIsGLFNjhINknVZyx SHH1vWEnRC2zkP49jW6hXSCra5XdbWeAXY2NWr0uCiFzU/ld2qkwXrecJno3JY7OIu3B AzJmGafAlQGSUazz2dWsfbF4jubvn4EqMNwHJ18qpUYHF9nLQAAWYhU6ZVyTCY9Zkcku 6TFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=XshMkqMod9U8Lvfa1S+jlzxMsIHtv/qiD7Q98rTq/+w=; b=muh9NIO4Vb545+FqGUcxrG1NunrhR5/MUWdQuRIwpoWz2ZUqGeloJznTiA2oxtpLcQ tA7Nv0hw1z9dQu28+jNhRM0H5fnMl8faFzXscpq80V9ryv1DsmaMij1yYst84u/N29M1 oPMGlLAjg1yPsQT8Xlb7d9So86IzG+ynE/549nxRN1NVhtWFLKVByk6Vr5y4/P+BArmT OLQVCB8anxMEoyyguqPwfCtakBDd5P3wDqIaSTSLwS/+yzbp7aBVuGuBavUMaZjWaCzS GyOj/rC9zORGel+7ZFpCpatbhaUkUupezvRjfwO1MUHgeTIgq7C3qKlVhB9Y1K1z/Coj HTOw== X-Gm-Message-State: AE9vXwOiQToS7gYAsTMurjpvb4W9xTWiMEoextN1rGsxSW9eHu8D9hs/e812NkWnfzgsag== X-Received: by 10.36.155.213 with SMTP id o204mr9176716itd.96.1472597691357; Tue, 30 Aug 2016 15:54:51 -0700 (PDT) Received: from mail-it0-f48.google.com (mail-it0-f48.google.com. [209.85.214.48]) by smtp.gmail.com with ESMTPSA id 28sm581846iok.32.2016.08.30.15.54.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 Aug 2016 15:54:51 -0700 (PDT) Received: by mail-it0-f48.google.com with SMTP id g62so65578827ith.1; Tue, 30 Aug 2016 15:54:51 -0700 (PDT) X-Received: by 10.107.20.151 with SMTP id 145mr2001407iou.70.1472597688657; Tue, 30 Aug 2016 15:54:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.14.11 with HTTP; Tue, 30 Aug 2016 15:54:48 -0700 (PDT) From: Roman Shpount Date: Tue, 30 Aug 2016 18:54:48 -0400 X-Gmail-Original-Message-ID: Message-ID: To: "rtcweb@ietf.org" , "mmusic@ietf.org" Content-Type: multipart/alternative; boundary=001a114fa8ea2131be053b51de4c Archived-At: Cc: Christer Holmberg Subject: [MMUSIC] SDP attribute setup=holdconn X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2016 22:54:54 -0000 --001a114fa8ea2131be053b51de4c Content-Type: text/plain; charset=UTF-8 Hi All, When discussing draft-ietf-mmusic-sctp-sdp with Christer we came up with a question regarding handling setup=holdconn. In case of TCP/DTLS/SCTP, the value of setup attribute is shared between TCP and DTLS. Per RFC 4145, TCP defines a use case for setup=holdconn. At the same time per draft-ietf-mmusic-dtls-sdp, setup=hodlconn must not be used. So, we have two options here: 1. Forbid using setup=holdconn with TCP/DTLS/SCTP in draft-ietf-mmusic-sctp-sdp 2. Define what setup=holdconn means for DTLS in draft-ietf-mmusic-dtls-sdp To provide the original background, in case of TCP, setup=holdconn essentially means that new TCP connection cannot be established as a result of this offer/answer exchange, no matter what other value has changed. It is used to differentiate the case when connection=existing is used with a passive TCP end point which wants to reuse existing connection and is not ready to accept a new TCP connection. In other words, when passive end point is ready to accept new TCP connection, the offer is sent with connection=existing and setup=passive. When no accept method was issued on the listening socket or if listening socket was already closed, the offer is sent with connection=existing and setup=holdconn. Since in case of DTLS, no accept method needs to be called on the socket before sending an offer and no extra resources are needed to accept new connection, I thought setup=holdconn was not necessary. This is why it was specified in draft-ietf-mmusic-dtls-sdp, that setup=holdconn must not be used. On the other hand there is no harm from setup=hodlconn. Furthermore there are certain aesthetic benefits when setup=holdconn is used with ICE and DTLS. When sending an update offer without ICE restart, specifying setup=holdconn can be used to indicate that answerer is not allowed to start a new DTLS association during this offer/answer exchange. So, once again, what should we do with setup=holdconn? Update draft-ietf-mmusic-dtls-sdp to define handling of setup=holdconn or prohibit setup=holdconn with TCP/DTLS/SCTP in draft-ietf-mmusic-sctp-sdp? Regards, _____________ Roman Shpount --001a114fa8ea2131be053b51de4c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi All,

When discussing draft-ietf-mmus= ic-sctp-sdp with Christer we came up with a question regarding handling set= up=3Dholdconn. In case of TCP/DTLS/SCTP,=C2=A0the value of setup attribute = is shared between TCP and DTLS. Per RFC 4145, TCP defines a use case for se= tup=3Dholdconn. At the same time per draft-ietf-mmusic-dtls-sdp, setup=3Dho= dlconn must not be used. So, we have two options here:

=
1. Forbid using setup=3Dholdconn with=C2=A0TCP/DTLS/SCTP in draft-ietf= -mmusic-sctp-sdp
2. Define what=C2=A0setup=3Dholdconn means for D= TLS in=C2=A0draft-ietf-mmusic-dtls-sdp

To provide the original background, in case = of TCP,=C2=A0=C2=A0setup=3Dholdconn essentially means that new TCP connecti= on cannot be established as a result of this offer/answer exchange, no matt= er what other value has changed. It is used to differentiate the case when = connection=3Dexisting is used with a passive TCP end point which wants to r= euse existing connection and is not ready to accept a new TCP connection. I= n other words, when passive end point is ready to accept new TCP connection= , the offer is sent with connection=3Dexisting and setup=3Dpassive. When no= accept method was issued on the listening socket or if listening socket wa= s already closed, the offer is sent with connection=3Dexisting and setup=3D= holdconn.

Since in case of DTLS, no accept method needs to be called on the socke= t before sending an offer and no extra resources are needed to accept new c= onnection, I thought setup=3Dholdconn was not necessary. This is why it was= specified in=C2=A0draft-ietf-mmusic-dtls-sdp, that setup=3Dholdconn must n= ot be used.=C2=A0On the other hand there is no harm from setup=3Dhodlconn. = Furthermore there are certain aesthetic benefits when setup=3Dholdconn is u= sed with ICE and DTLS. When sending an update offer without ICE restart, sp= ecifying=C2=A0setup=3Dholdconn can be used to indicate that answerer is not= allowed to start a new DTLS association during this offer/answer exchange.=

So, o= nce again, what should we do with setup=3Dholdconn? Update draft-ietf-mmusi= c-dtls-sdp to define handling of setup=3Dholdconn or prohibit =C2=A0setup= =3Dholdconn with=C2=A0TCP/DTLS/SCTP in=C2=A0draft-ietf-mmusic-sctp-sdp?

Regards,<= /div>
_______= ______
Roman Shpount
--001a114fa8ea2131be053b51de4c-- From nobody Wed Aug 31 02:58:18 2016 Return-Path: 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 717C012DA93; Wed, 31 Aug 2016 02:58:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 Zzwauqy-D1oW; Wed, 31 Aug 2016 02:58:14 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6452B12DA91; Wed, 31 Aug 2016 02:58:13 -0700 (PDT) X-AuditID: c1b4fb30-ea88e980000009f9-4f-57c6aa33a05e Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.183.78]) by (Symantec Mail Security) with SMTP id 70.58.02553.33AA6C75; Wed, 31 Aug 2016 11:58:11 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.80) with Microsoft SMTP Server id 14.3.301.0; Wed, 31 Aug 2016 11:58:09 +0200 To: "mmusic (E-mail)" , "draft-ietf-mmusic-sdp-bundle-negotiation@ietf.org" From: Magnus Westerlund Message-ID: Date: Wed, 31 Aug 2016 11:58:07 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupkluLIzCtJLcpLzFFi42KZGbHdT9d41bFwg4uftSymz3rHZjF1+WMW ByaPJUt+MgUwRnHZpKTmZJalFunbJXBlfPp8kr3gqVLFkj/P2RoYJ0p3MXJySAiYSLw9N42t i5GLQ0hgPaPEvZZ/jBDOckaJC0sXs4FUiQhMYZSYNNEQxGYTsJC4+aMRLC4sYCex6MVSJhCb V8Beom9BP1icRUBVYv23i+xdjBwcogIxEuv7EiBKBCVOznzCAhJmBip/sLUMJMwsIC/RvHU2 M4gtJKAt0dDUwTqBkXcWko5ZCB2zkHQsYGRexShanFqclJtuZKSXWpSZXFycn6eXl1qyiREY QAe3/DbYwfjyueMhRgEORiUe3oUnj4YLsSaWFVfmHmKU4GBWEuH1WXksXIg3JbGyKrUoP76o NCe1+BCjNAeLkjiv/0vFcCGB9MSS1OzU1ILUIpgsEwenVAPj3KrrvJoHs+d75XbNfdFdedaw zPFPeEu6X93OI8+UP246daldQGUXQ+NTxoZlG6PUJpy+OcPL62iqg9/X7Z4JOlsC9ZvdNe6Y ruPPmbZtz+yDlx/n+f3esMtSZ866tSc/ND4OjxM+b6Xvct3cKfBWruVHed0U3hm7VvZZOnsz ae8+IpM2Yam0EktxRqKhFnNRcSIAgxSTkhwCAAA= Archived-At: Subject: [MMUSIC] Review of draft-ietf-mmusic-sdp-bundle-negotiation-32 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2016 09:58:16 -0000 Hi, As I promised in Berlin I have done a review of BUNDLE. 1. Section 1: The update allows an answerer to assign a non-zero port value to an "m=" line in an SDP answer, even if the "m=" line in the associated SDP offer contained a zero port value. I think this sentence could be more explicit that this is allowed given that the Offer included this "m=" line in an bundle group. 2. Section 8.5.2: o Assign the previously selected offerer BUNDLE address to the added "m=" line; or Two things. A. Should "previously" be "currently"? B. Add an "also" to the above sentence to make it clearer that it is for the added m= line. o Assign the currently selected offerer BUNDLE address also to the added "m=" line; or 3. Section 9: This document describes a mechanism to identify the protocol of received data among the STUN, DTLS and SRTP protocols (in any combination), when UDP is used as transport-layer protocol, but does not describe how to identify different protocols transported on DTLS. While the mechanism is generally applicable to other protocols and transport-layer protocols, any such use requires further specification around how to multiplex multiple protocols on a given transport-layer protocol, and how to associate received data with the correct protocols. I note that this formulation when it comes to other protocols results that there is no BUNDLE demultiplexing defined for transports that are not UDP but has a datagram semantics. I note that this is do effect WebRTC as there is a definition for using RFC 4571 framing over TCP for all type of protocols. See Section 3.4 of https://datatracker.ietf.org/doc/draft-ietf-rtcweb-transports/?include_text=1 If TCP connections are used, RTP framing according to [RFC4571] MUST be used for all packets. This includes the RTP packets, DTLS packets used to carry data channels, and STUN connectivity check packets. From BUNDLEs perspective, such a framing will behave equivalent to UDP when it comes to demultiplexing. Thus my question is if TCP with RFC4571 framing also should be defined? Otherwise we will end up with an feature mismatch in regards to BUNDLE depending on transport layer. 4. Section 10.1: o The RTP MID header extension MUST be enabled, by associating an SDP 'extmap' attribute [RFC5285], with a 'urn:ietf:params:rtp- hdrext:sdes:mid' URI value, with each bundled RTP-based "m=" line in every offer and answer. I think the list is missing a bullet prior to the above one: * The MID SDES item MUST periodically be sent in RTCP SDES items for any SSRC originating from a "m=" line that is part of any BUNDLE group. What I see is the important goal here is that BUNDLE supporting implementations also support the MID SDES item in RTCP, not only the header extension. 5. Section 15.2: The SDES item does not reveal privacy information about the users. It is simply used to associate RTP-based media with the correct SDP media description (m- line) in the SDP used to negotiate the media. I do not fully agree with this statement. As the MIDs are transmitted over the RTP/RTCP channel the actual used values as well as the implementation algorithm for creating such IDs are exposed. This can allow for tracking of instances if they have unusual combinations of media streams as well if the MID values are poorly constructed from privacy perspective leak additional information. I think this threat needs to be made more explicit. I also think it might be better to move this discussion to the Security Consideration section. I note that the security consideration section is focused on only the SDP BUNDLE mechanism, not the other defined protocol elements, i.e. the new SDP attributes as well as the MID. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Wed Aug 31 08:55:42 2016 Return-Path: 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 59B7112D1E7 for ; Wed, 31 Aug 2016 08:55:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 onBuFZOBAOm2 for ; Wed, 31 Aug 2016 08:55:35 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE94A12D5BE for ; Wed, 31 Aug 2016 08:48:11 -0700 (PDT) X-AuditID: c1b4fb3a-0618b980000009bd-0d-57c6fc395ca5 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.183.84]) by (Symantec Mail Security) with SMTP id 46.B9.02493.93CF6C75; Wed, 31 Aug 2016 17:48:09 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.211]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0301.000; Wed, 31 Aug 2016 17:48:08 +0200 From: Christer Holmberg To: mmusic WG Thread-Topic: SDP attribute setup=holdconn Thread-Index: AQHSAxGDZfpFJK4X60GfUoKnJx0Z4qBjN9mQ Date: Wed, 31 Aug 2016 15:48:08 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BC7AE69@ESESSMB209.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B4BC7AE69ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNLMWRmVeSWpSXmKPExsUyM2J7iK7ln2PhBi9PyVhMXf6YxYHRY8mS n0wBjFFcNimpOZllqUX6dglcGce7ZjMV9CRWzNrWx9TAuCOui5GTQ0LAROLy5/8sXYxcHEIC 6xklpq6+yA6SEBJYwijReNiri5GDg03AQqL7nzZIWERAXuJj5zlGEFtYQFPi481HrBBxLYmL H1vZIGwjiVnHLjOD2CwCqhJ3ji4HG8kr4CvRs/M2C8hIIYEAiUsvLUDCnAKBEpcn3wIrZxQQ k/h+ag0TiM0sIC5x68l8JogzBSSW7DnPDGGLSrx8/I8VwlaSWHT7M1R9vsSC1eeZIFYJSpyc +YRlAqPwLCSjZiEpm4WkbBbQRcxA36zfpQ9RoigxpfshO4StIdE6Zy47svgCRvZVjKLFqcXF uelGRnqpRZnJxcX5eXp5qSWbGIFRcnDLb6sdjAefOx5iFOBgVOLhXXDyaLgQa2JZcWXuIUYJ DmYlEd4pP4+FC/GmJFZWpRblxxeV5qQWH2KU5mBREuf1f6kYLiSQnliSmp2aWpBaBJNl4uCU amBczrS88dH25Vu+SRm8KTxuq2Dfap90gfOww4H8w2pPBfx5vC9NmPrCtPLJwaIAwxbRnz9f 6fjMTK5YM+talE6f1JlT//Zkqp7fel9eZ0ewB+uyugssrc1T3qd8fjJ77fypLJa6ljLLL6sF GL97IeiWHif7bU5pKl+nUNxUa49d+3Ta1p4Kld2lxFKckWioxVxUnAgAn1MkOo4CAAA= Archived-At: Subject: [MMUSIC] FW: SDP attribute setup=holdconn X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2016 15:55:39 -0000 --_000_7594FB04B1934943A5C02806D1A2204B4BC7AE69ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhbSBmb3J3YXJkaW5nIFJvbWFu4oCZcyBlLW1haWwgdG8gTU1VU0lDLCBiZWNhdXNlIGl0IHRo aW5rIGl0IGJlbG9uZ3MgaGVyZS4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KRnJvbTogUm9t YW4gU2hwb3VudCBbbWFpbHRvOnJvbWFuQHRlbHVyaXguY29tXQ0KU2VudDogMzEgQXVndXN0IDIw MTYgMDE6NTUNClRvOiBydGN3ZWJAaWV0Zi5vcmc7IG1tdXNpY0BpZXRmLm9yZw0KQ2M6IENocmlz dGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+DQpTdWJqZWN0OiBT RFAgYXR0cmlidXRlIHNldHVwPWhvbGRjb25uDQoNCkhpIEFsbCwNCg0KV2hlbiBkaXNjdXNzaW5n IGRyYWZ0LWlldGYtbW11c2ljLXNjdHAtc2RwIHdpdGggQ2hyaXN0ZXIgd2UgY2FtZSB1cCB3aXRo IGEgcXVlc3Rpb24gcmVnYXJkaW5nIGhhbmRsaW5nIHNldHVwPWhvbGRjb25uLiBJbiBjYXNlIG9m IFRDUC9EVExTL1NDVFAsIHRoZSB2YWx1ZSBvZiBzZXR1cCBhdHRyaWJ1dGUgaXMgc2hhcmVkIGJl dHdlZW4gVENQIGFuZCBEVExTLiBQZXIgUkZDIDQxNDUsIFRDUCBkZWZpbmVzIGEgdXNlIGNhc2Ug Zm9yIHNldHVwPWhvbGRjb25uLiBBdCB0aGUgc2FtZSB0aW1lIHBlciBkcmFmdC1pZXRmLW1tdXNp Yy1kdGxzLXNkcCwgc2V0dXA9aG9kbGNvbm4gbXVzdCBub3QgYmUgdXNlZC4gU28sIHdlIGhhdmUg dHdvIG9wdGlvbnMgaGVyZToNCg0KMS4gRm9yYmlkIHVzaW5nIHNldHVwPWhvbGRjb25uIHdpdGgg VENQL0RUTFMvU0NUUCBpbiBkcmFmdC1pZXRmLW1tdXNpYy1zY3RwLXNkcA0KMi4gRGVmaW5lIHdo YXQgc2V0dXA9aG9sZGNvbm4gbWVhbnMgZm9yIERUTFMgaW4gZHJhZnQtaWV0Zi1tbXVzaWMtZHRs cy1zZHANCg0KVG8gcHJvdmlkZSB0aGUgb3JpZ2luYWwgYmFja2dyb3VuZCwgaW4gY2FzZSBvZiBU Q1AsICBzZXR1cD1ob2xkY29ubiBlc3NlbnRpYWxseSBtZWFucyB0aGF0IG5ldyBUQ1AgY29ubmVj dGlvbiBjYW5ub3QgYmUgZXN0YWJsaXNoZWQgYXMgYSByZXN1bHQgb2YgdGhpcyBvZmZlci9hbnN3 ZXIgZXhjaGFuZ2UsIG5vIG1hdHRlciB3aGF0IG90aGVyIHZhbHVlIGhhcyBjaGFuZ2VkLiBJdCBp cyB1c2VkIHRvIGRpZmZlcmVudGlhdGUgdGhlIGNhc2Ugd2hlbiBjb25uZWN0aW9uPWV4aXN0aW5n IGlzIHVzZWQgd2l0aCBhIHBhc3NpdmUgVENQIGVuZCBwb2ludCB3aGljaCB3YW50cyB0byByZXVz ZSBleGlzdGluZyBjb25uZWN0aW9uIGFuZCBpcyBub3QgcmVhZHkgdG8gYWNjZXB0IGEgbmV3IFRD UCBjb25uZWN0aW9uLiBJbiBvdGhlciB3b3Jkcywgd2hlbiBwYXNzaXZlIGVuZCBwb2ludCBpcyBy ZWFkeSB0byBhY2NlcHQgbmV3IFRDUCBjb25uZWN0aW9uLCB0aGUgb2ZmZXIgaXMgc2VudCB3aXRo IGNvbm5lY3Rpb249ZXhpc3RpbmcgYW5kIHNldHVwPXBhc3NpdmUuIFdoZW4gbm8gYWNjZXB0IG1l dGhvZCB3YXMgaXNzdWVkIG9uIHRoZSBsaXN0ZW5pbmcgc29ja2V0IG9yIGlmIGxpc3RlbmluZyBz b2NrZXQgd2FzIGFscmVhZHkgY2xvc2VkLCB0aGUgb2ZmZXIgaXMgc2VudCB3aXRoIGNvbm5lY3Rp b249ZXhpc3RpbmcgYW5kIHNldHVwPWhvbGRjb25uLg0KDQpTaW5jZSBpbiBjYXNlIG9mIERUTFMs IG5vIGFjY2VwdCBtZXRob2QgbmVlZHMgdG8gYmUgY2FsbGVkIG9uIHRoZSBzb2NrZXQgYmVmb3Jl IHNlbmRpbmcgYW4gb2ZmZXIgYW5kIG5vIGV4dHJhIHJlc291cmNlcyBhcmUgbmVlZGVkIHRvIGFj Y2VwdCBuZXcgY29ubmVjdGlvbiwgSSB0aG91Z2h0IHNldHVwPWhvbGRjb25uIHdhcyBub3QgbmVj ZXNzYXJ5LiBUaGlzIGlzIHdoeSBpdCB3YXMgc3BlY2lmaWVkIGluIGRyYWZ0LWlldGYtbW11c2lj LWR0bHMtc2RwLCB0aGF0IHNldHVwPWhvbGRjb25uIG11c3Qgbm90IGJlIHVzZWQuIE9uIHRoZSBv dGhlciBoYW5kIHRoZXJlIGlzIG5vIGhhcm0gZnJvbSBzZXR1cD1ob2RsY29ubi4gRnVydGhlcm1v cmUgdGhlcmUgYXJlIGNlcnRhaW4gYWVzdGhldGljIGJlbmVmaXRzIHdoZW4gc2V0dXA9aG9sZGNv bm4gaXMgdXNlZCB3aXRoIElDRSBhbmQgRFRMUy4gV2hlbiBzZW5kaW5nIGFuIHVwZGF0ZSBvZmZl ciB3aXRob3V0IElDRSByZXN0YXJ0LCBzcGVjaWZ5aW5nIHNldHVwPWhvbGRjb25uIGNhbiBiZSB1 c2VkIHRvIGluZGljYXRlIHRoYXQgYW5zd2VyZXIgaXMgbm90IGFsbG93ZWQgdG8gc3RhcnQgYSBu ZXcgRFRMUyBhc3NvY2lhdGlvbiBkdXJpbmcgdGhpcyBvZmZlci9hbnN3ZXIgZXhjaGFuZ2UuDQoN ClNvLCBvbmNlIGFnYWluLCB3aGF0IHNob3VsZCB3ZSBkbyB3aXRoIHNldHVwPWhvbGRjb25uPyBV cGRhdGUgZHJhZnQtaWV0Zi1tbXVzaWMtZHRscy1zZHAgdG8gZGVmaW5lIGhhbmRsaW5nIG9mIHNl dHVwPWhvbGRjb25uIG9yIHByb2hpYml0ICBzZXR1cD1ob2xkY29ubiB3aXRoIFRDUC9EVExTL1ND VFAgaW4gZHJhZnQtaWV0Zi1tbXVzaWMtc2N0cC1zZHA/DQoNClJlZ2FyZHMsDQpfX19fX19fX19f X19fDQpSb21hbiBTaHBvdW50DQo= --_000_7594FB04B1934943A5C02806D1A2204B4BC7AE69ESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBz cGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxl MTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp ZjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7 c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBw dDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBz cGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIg ZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4N Cjxib2R5IGxhbmc9IkVOLUdCIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2 IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkkgYW0gZm9yd2Fy ZGluZyBSb21hbuKAmXMgZS1tYWlsIHRvIE1NVVNJQywgYmVjYXVzZSBpdCB0aGluayBpdCBiZWxv bmdzIGhlcmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5SZWdhcmRz LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Q2hyaXN0ZXI8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENv bXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2E+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBSb21hbiBTaHBvdW50IFttYWlsdG86cm9tYW5A dGVsdXJpeC5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gMzEgQXVndXN0IDIwMTYgMDE6NTU8YnI+ DQo8Yj5Ubzo8L2I+IHJ0Y3dlYkBpZXRmLm9yZzsgbW11c2ljQGlldGYub3JnPGJyPg0KPGI+Q2M6 PC9iPiBDaHJpc3RlciBIb2xtYmVyZyAmbHQ7Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29t Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBTRFAgYXR0cmlidXRlIHNldHVwPWhvbGRjb25uPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgQWxsLDxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2hlbiBkaXNjdXNzaW5nIGRyYWZ0LWll dGYtbW11c2ljLXNjdHAtc2RwIHdpdGggQ2hyaXN0ZXIgd2UgY2FtZSB1cCB3aXRoIGEgcXVlc3Rp b24gcmVnYXJkaW5nIGhhbmRsaW5nIHNldHVwPWhvbGRjb25uLiBJbiBjYXNlIG9mIFRDUC9EVExT L1NDVFAsJm5ic3A7dGhlIHZhbHVlIG9mIHNldHVwIGF0dHJpYnV0ZSBpcyBzaGFyZWQgYmV0d2Vl biBUQ1AgYW5kIERUTFMuIFBlciBSRkMgNDE0NSwgVENQIGRlZmluZXMgYSB1c2UNCiBjYXNlIGZv ciBzZXR1cD1ob2xkY29ubi4gQXQgdGhlIHNhbWUgdGltZSBwZXIgZHJhZnQtaWV0Zi1tbXVzaWMt ZHRscy1zZHAsIHNldHVwPWhvZGxjb25uIG11c3Qgbm90IGJlIHVzZWQuIFNvLCB3ZSBoYXZlIHR3 byBvcHRpb25zIGhlcmU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjEuIEZvcmJpZCB1c2luZyBzZXR1cD1ob2xkY29ubiB3aXRoJm5ic3A7VENQ L0RUTFMvU0NUUCBpbiBkcmFmdC1pZXRmLW1tdXNpYy1zY3RwLXNkcDxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Mi4gRGVmaW5lIHdoYXQmbmJzcDtz ZXR1cD1ob2xkY29ubiBtZWFucyBmb3IgRFRMUyBpbiZuYnNwO2RyYWZ0LWlldGYtbW11c2ljLWR0 bHMtc2RwPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UbyBw cm92aWRlIHRoZSBvcmlnaW5hbCBiYWNrZ3JvdW5kLCBpbiBjYXNlIG9mIFRDUCwmbmJzcDsmbmJz cDtzZXR1cD1ob2xkY29ubiBlc3NlbnRpYWxseSBtZWFucyB0aGF0IG5ldyBUQ1AgY29ubmVjdGlv biBjYW5ub3QgYmUgZXN0YWJsaXNoZWQgYXMgYSByZXN1bHQgb2YgdGhpcyBvZmZlci9hbnN3ZXIg ZXhjaGFuZ2UsIG5vIG1hdHRlciB3aGF0IG90aGVyIHZhbHVlIGhhcyBjaGFuZ2VkLiBJdCBpcyB1 c2VkIHRvIGRpZmZlcmVudGlhdGUNCiB0aGUgY2FzZSB3aGVuIGNvbm5lY3Rpb249ZXhpc3Rpbmcg aXMgdXNlZCB3aXRoIGEgcGFzc2l2ZSBUQ1AgZW5kIHBvaW50IHdoaWNoIHdhbnRzIHRvIHJldXNl IGV4aXN0aW5nIGNvbm5lY3Rpb24gYW5kIGlzIG5vdCByZWFkeSB0byBhY2NlcHQgYSBuZXcgVENQ IGNvbm5lY3Rpb24uIEluIG90aGVyIHdvcmRzLCB3aGVuIHBhc3NpdmUgZW5kIHBvaW50IGlzIHJl YWR5IHRvIGFjY2VwdCBuZXcgVENQIGNvbm5lY3Rpb24sIHRoZSBvZmZlciBpcyBzZW50DQogd2l0 aCBjb25uZWN0aW9uPWV4aXN0aW5nIGFuZCBzZXR1cD1wYXNzaXZlLiBXaGVuIG5vIGFjY2VwdCBt ZXRob2Qgd2FzIGlzc3VlZCBvbiB0aGUgbGlzdGVuaW5nIHNvY2tldCBvciBpZiBsaXN0ZW5pbmcg c29ja2V0IHdhcyBhbHJlYWR5IGNsb3NlZCwgdGhlIG9mZmVyIGlzIHNlbnQgd2l0aCBjb25uZWN0 aW9uPWV4aXN0aW5nIGFuZCBzZXR1cD1ob2xkY29ubi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U2luY2UgaW4gY2FzZSBvZiBEVExTLCBubyBh Y2NlcHQgbWV0aG9kIG5lZWRzIHRvIGJlIGNhbGxlZCBvbiB0aGUgc29ja2V0IGJlZm9yZSBzZW5k aW5nIGFuIG9mZmVyIGFuZCBubyBleHRyYSByZXNvdXJjZXMgYXJlIG5lZWRlZCB0byBhY2NlcHQg bmV3IGNvbm5lY3Rpb24sIEkgdGhvdWdodCBzZXR1cD1ob2xkY29ubiB3YXMgbm90IG5lY2Vzc2Fy eS4gVGhpcyBpcyB3aHkgaXQgd2FzIHNwZWNpZmllZCBpbiZuYnNwO2RyYWZ0LWlldGYtbW11c2lj LWR0bHMtc2RwLA0KIHRoYXQgc2V0dXA9aG9sZGNvbm4gbXVzdCBub3QgYmUgdXNlZC4mbmJzcDtP biB0aGUgb3RoZXIgaGFuZCB0aGVyZSBpcyBubyBoYXJtIGZyb20gc2V0dXA9aG9kbGNvbm4uIEZ1 cnRoZXJtb3JlIHRoZXJlIGFyZSBjZXJ0YWluIGFlc3RoZXRpYyBiZW5lZml0cyB3aGVuIHNldHVw PWhvbGRjb25uIGlzIHVzZWQgd2l0aCBJQ0UgYW5kIERUTFMuIFdoZW4gc2VuZGluZyBhbiB1cGRh dGUgb2ZmZXIgd2l0aG91dCBJQ0UgcmVzdGFydCwgc3BlY2lmeWluZyZuYnNwO3NldHVwPWhvbGRj b25uDQogY2FuIGJlIHVzZWQgdG8gaW5kaWNhdGUgdGhhdCBhbnN3ZXJlciBpcyBub3QgYWxsb3dl ZCB0byBzdGFydCBhIG5ldyBEVExTIGFzc29jaWF0aW9uIGR1cmluZyB0aGlzIG9mZmVyL2Fuc3dl ciBleGNoYW5nZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+U28sIG9uY2UgYWdhaW4sIHdoYXQgc2hvdWxkIHdlIGRvIHdpdGggc2V0dXA9aG9s ZGNvbm4/IFVwZGF0ZSBkcmFmdC1pZXRmLW1tdXNpYy1kdGxzLXNkcCB0byBkZWZpbmUgaGFuZGxp bmcgb2Ygc2V0dXA9aG9sZGNvbm4gb3IgcHJvaGliaXQgJm5ic3A7c2V0dXA9aG9sZGNvbm4gd2l0 aCZuYnNwO1RDUC9EVExTL1NDVFAgaW4mbmJzcDtkcmFmdC1pZXRmLW1tdXNpYy1zY3RwLXNkcD88 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmVn YXJkcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fXzxicj4NClJvbWFuIFNocG91bnQ8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_7594FB04B1934943A5C02806D1A2204B4BC7AE69ESESSMB209erics_-- From nobody Wed Aug 31 09:57:31 2016 Return-Path: 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 3F69212D516 for ; Wed, 31 Aug 2016 09:57:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 aVZ8Nkmn_726 for ; Wed, 31 Aug 2016 09:57:28 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF08812D1AD for ; Wed, 31 Aug 2016 09:57:27 -0700 (PDT) X-AuditID: c1b4fb25-ca31e98000001071-00-57c70c752ac7 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.183.90]) by (Symantec Mail Security) with SMTP id 3D.A0.04209.57C07C75; Wed, 31 Aug 2016 18:57:26 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.211]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0301.000; Wed, 31 Aug 2016 18:57:23 +0200 From: Christer Holmberg To: mmusic WG Thread-Topic: SDP attribute setup=holdconn Thread-Index: AQHSAxGDZfpFJK4X60GfUoKnJx0Z4qBjN9mQgAARnyA= Date: Wed, 31 Aug 2016 16:57:22 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BC7B386@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B4BC7AE69@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BC7AE69@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B4BC7B386ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLLMWRmVeSWpSXmKPExsUyM2J7lG4Zz/FwgzfveCymLn/M4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujCkX5jMV3Mmt6N+q1cD4IKuLkZNDQsBEYsf5VtYuRi4OIYH1 jBKz7xyDcpYwShy4eJa9i5GDg03AQqL7nzZIg4iAvMTHznOMILawgKbE2jtfWSHiWhIXP7ay QdhWEk82XWcHsVkEVCWe3njPBGLzCvhKbD/9hgli/hRGiSUbL4A1cAr4SXyZdZUZxGYUEJP4 fmoNWAOzgLjErSfzmSAuFZBYsuc8M4QtKvHy8T9WCFtJYtHtz1D1+RIH/vQzQywTlDg58wnL BEbhWUhGzUJSNgtJ2SygN5mB/lm/Sx+iRFFiSvdDdghbQ6J1zlx2ZPEFjOyrGEWLU4uTctON jPVSizKTi4vz8/TyUks2MQIj5eCW36o7GC+/cTzEKMDBqMTDu+Dk0XAh1sSy4srcQ4wSHMxK Irw72Y+HC/GmJFZWpRblxxeV5qQWH2KU5mBREuf1f6kYLiSQnliSmp2aWpBaBJNl4uCUamAs 3texTHuG/4JfR5iDKgrP6+affPFwG5un1SPpFO0bZjayhguUpFY3p2TeusKfPbtrdbfUTZXH Z9Q9vN3D2EsW/DftUDPbKZ8dsrLy3dllOuxf1+Rsb9nOqHnaPNarSv1hg9Zu512KITvsLt5e vrZtVvkbpmdbBa9tKj93RWLqP+cPWv3PFj1SYinOSDTUYi4qTgQAPhCEo5ACAAA= Archived-At: Subject: Re: [MMUSIC] SDP attribute setup=holdconn X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2016 16:57:30 -0000 --_000_7594FB04B1934943A5C02806D1A2204B4BC7B386ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCk15IGlucHV0IG9uIHRoaXMuDQoNCj5XaGVuIGRpc2N1c3NpbmcgZHJhZnQtaWV0Zi1t bXVzaWMtc2N0cC1zZHAgd2l0aCBDaHJpc3RlciB3ZSBjYW1lIHVwIHdpdGggYSBxdWVzdGlvbiBy ZWdhcmRpbmcgaGFuZGxpbmcgc2V0dXA9aG9sZGNvbm4uIEluIGNhc2Ugb2YgPlRDUC9EVExTL1ND VFAsIHRoZSB2YWx1ZSBvZiBzZXR1cCBhdHRyaWJ1dGUgaXMgc2hhcmVkIGJldHdlZW4gVENQIGFu ZCBEVExTLiBQZXIgUkZDIDQxNDUsIFRDUCBkZWZpbmVzIGEgdXNlIGNhc2UgZm9yIHNldHVwPWhv bGRjb25uLiBBdCB0aGUgc2FtZSA+dGltZSBwZXIgZHJhZnQtaWV0Zi1tbXVzaWMtZHRscy1zZHAs IHNldHVwPWhvZGxjb25uIG11c3Qgbm90IGJlIHVzZWQuIFNvLCB3ZSBoYXZlIHR3byBvcHRpb25z IGhlcmU6DQo+DQo+MS4gRm9yYmlkIHVzaW5nIHNldHVwPWhvbGRjb25uIHdpdGggVENQL0RUTFMv U0NUUCBpbiBkcmFmdC1pZXRmLW1tdXNpYy1zY3RwLXNkcA0KPjIuIERlZmluZSB3aGF0IHNldHVw PWhvbGRjb25uIG1lYW5zIGZvciBEVExTIGluIGRyYWZ0LWlldGYtbW11c2ljLWR0bHMtc2RwDQo+ DQo+VG8gcHJvdmlkZSB0aGUgb3JpZ2luYWwgYmFja2dyb3VuZCwgaW4gY2FzZSBvZiBUQ1AsICBz ZXR1cD1ob2xkY29ubiBlc3NlbnRpYWxseSBtZWFucyB0aGF0IG5ldyBUQ1AgY29ubmVjdGlvbiBj YW5ub3QgYmUgZXN0YWJsaXNoZWQgYXMgYSByZXN1bHQgb2YgdGhpcyA+b2ZmZXIvYW5zd2VyIGV4 Y2hhbmdlLCBubyBtYXR0ZXIgd2hhdCBvdGhlciB2YWx1ZSBoYXMgY2hhbmdlZC4gSXQgaXMgdXNl ZCB0byBkaWZmZXJlbnRpYXRlIHRoZSBjYXNlIHdoZW4gY29ubmVjdGlvbj1leGlzdGluZyBpcyB1 c2VkIHdpdGggYSBwYXNzaXZlIFRDUCBlbmQgPnBvaW50IHdoaWNoIHdhbnRzIHRvIHJldXNlIGV4 aXN0aW5nIGNvbm5lY3Rpb24gYW5kIGlzIG5vdCByZWFkeSB0byBhY2NlcHQgYSBuZXcgVENQIGNv bm5lY3Rpb24uIEluIG90aGVyIHdvcmRzLCB3aGVuIHBhc3NpdmUgZW5kIHBvaW50IGlzIHJlYWR5 IHRvIGFjY2VwdCA+bmV3IFRDUCBjb25uZWN0aW9uLCB0aGUgb2ZmZXIgaXMgc2VudCB3aXRoIGNv bm5lY3Rpb249ZXhpc3RpbmcgYW5kIHNldHVwPXBhc3NpdmUuIFdoZW4gbm8gYWNjZXB0IG1ldGhv ZCB3YXMgaXNzdWVkIG9uIHRoZSBsaXN0ZW5pbmcgc29ja2V0IG9yIGlmIGxpc3RlbmluZyA+c29j a2V0IHdhcyBhbHJlYWR5IGNsb3NlZCwgdGhlIG9mZmVyIGlzIHNlbnQgd2l0aCBjb25uZWN0aW9u PWV4aXN0aW5nIGFuZCBzZXR1cD1ob2xkY29ubi4NCj4NCj5TaW5jZSBpbiBjYXNlIG9mIERUTFMs IG5vIGFjY2VwdCBtZXRob2QgbmVlZHMgdG8gYmUgY2FsbGVkIG9uIHRoZSBzb2NrZXQgYmVmb3Jl IHNlbmRpbmcgYW4gb2ZmZXIgYW5kIG5vIGV4dHJhIHJlc291cmNlcyBhcmUgbmVlZGVkIHRvIGFj Y2VwdCBuZXcgPmNvbm5lY3Rpb24sIEkgdGhvdWdodCBzZXR1cD1ob2xkY29ubiB3YXMgbm90IG5l Y2Vzc2FyeS4gVGhpcyBpcyB3aHkgaXQgd2FzIHNwZWNpZmllZCBpbiBkcmFmdC1pZXRmLW1tdXNp Yy1kdGxzLXNkcCwgdGhhdCBzZXR1cD1ob2xkY29ubiBtdXN0IG5vdCBiZSA+dXNlZC4gT24gdGhl IG90aGVyIGhhbmQgdGhlcmUgaXMgbm8gaGFybSBmcm9tIHNldHVwPWhvZGxjb25uLiBGdXJ0aGVy bW9yZSB0aGVyZSBhcmUgY2VydGFpbiBhZXN0aGV0aWMgYmVuZWZpdHMgd2hlbiBzZXR1cD1ob2xk Y29ubiBpcyB1c2VkIHdpdGggSUNFIGFuZCA+RFRMUy4gV2hlbiBzZW5kaW5nIGFuIHVwZGF0ZSBv ZmZlciB3aXRob3V0IElDRSByZXN0YXJ0LCBzcGVjaWZ5aW5nIHNldHVwPWhvbGRjb25uIGNhbiBi ZSB1c2VkIHRvIGluZGljYXRlIHRoYXQgYW5zd2VyZXIgaXMgbm90IGFsbG93ZWQgdG8gc3RhcnQg YSBuZXcgPkRUTFMgYXNzb2NpYXRpb24gZHVyaW5nIHRoaXMgb2ZmZXIvYW5zd2VyIGV4Y2hhbmdl Lg0KDQpJIHRoaW5rIGl04oCZcyBtdWNoIGJldHRlciB0byBoYXZlIGEgZ2VuZXJhbCBzdGF0ZW1l bnQgc2F5aW5nIHRoYXQgdGhlIGFuc3dlcmVyIHNob3VsZCBub3Qgc3RhcnQgYSBuZXcgRFRMUyBh c3NvY2lhdGlvbiwgdW5sZXNzIGl0IGhhcyBhIGdvb2QgcmVhc29uIGZvciBkb2luZyBzby4gSUYg dGhlIGFuc3dlcmVyIGhhcyBhIGdvb2QgcmVhc29uIGZvciBzdGFydGluZyBhIG5ldyBEVExTIGFz c29jaWF0aW9uLCBkbyB5b3UgcmVhbGx5IHdhbnQgdG8gcHJldmVudCBpdCBmcm9tIGRvaW5nIHNv Pw0KDQo+U28sIG9uY2UgYWdhaW4sIHdoYXQgc2hvdWxkIHdlIGRvIHdpdGggc2V0dXA9aG9sZGNv bm4/IFVwZGF0ZSBkcmFmdC1pZXRmLW1tdXNpYy1kdGxzLXNkcCB0byBkZWZpbmUgaGFuZGxpbmcg b2Ygc2V0dXA9aG9sZGNvbm4gb3IgPnByb2hpYml0ICBzZXR1cD1ob2xkY29ubiB3aXRoIFRDUC9E VExTL1NDVFAgaW4gZHJhZnQtaWV0Zi1tbXVzaWMtc2N0cC1zZHA/DQoNCk15IGh1bSBnb2VzIGZv ciBwcm9oaWJpdGluZyBzZXR1cD1ob2xkY29ubiB3aXRoIFRDUC9EVExTL1NDVFAgKGFuZCBrZWVw aW5nIGRyYWZ0LWR0bHMtc2RwIHVuY2hhbmdlZCkuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQo= --_000_7594FB04B1934943A5C02806D1A2204B4BC7B386ESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBz cGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxl MTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh bnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp ZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4 cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3Np emU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp ZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRh dGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8 Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBj bGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5IaSw8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPk15IGlucHV0IG9uIHRoaXMuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImNvbG9yOiMxRjQ5N0QiPiZndDs8L3NwYW4+V2hlbiBkaXNjdXNzaW5nIGRyYWZ0LWlldGYtbW11 c2ljLXNjdHAtc2RwIHdpdGggQ2hyaXN0ZXIgd2UgY2FtZSB1cCB3aXRoIGEgcXVlc3Rpb24gcmVn YXJkaW5nIGhhbmRsaW5nIHNldHVwPWhvbGRjb25uLiBJbiBjYXNlIG9mDQo8c3BhbiBzdHlsZT0i Y29sb3I6IzFGNDk3RCI+Jmd0Ozwvc3Bhbj5UQ1AvRFRMUy9TQ1RQLCZuYnNwO3RoZSB2YWx1ZSBv ZiBzZXR1cCBhdHRyaWJ1dGUgaXMgc2hhcmVkIGJldHdlZW4gVENQIGFuZCBEVExTLiBQZXIgUkZD IDQxNDUsIFRDUCBkZWZpbmVzIGEgdXNlIGNhc2UgZm9yIHNldHVwPWhvbGRjb25uLiBBdCB0aGUg c2FtZQ0KPHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZndDs8L3NwYW4+dGltZSBwZXIgZHJh ZnQtaWV0Zi1tbXVzaWMtZHRscy1zZHAsIHNldHVwPWhvZGxjb25uIG11c3Qgbm90IGJlIHVzZWQu IFNvLCB3ZSBoYXZlIHR3byBvcHRpb25zIGhlcmU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jmd0 Ozwvc3Bhbj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mZ3Q7PC9zcGFuPjEuIEZvcmJp ZCB1c2luZyBzZXR1cD1ob2xkY29ubiB3aXRoJm5ic3A7VENQL0RUTFMvU0NUUCBpbiBkcmFmdC1p ZXRmLW1tdXNpYy1zY3RwLXNkcDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZndDs8L3NwYW4+Mi4g RGVmaW5lIHdoYXQmbmJzcDtzZXR1cD1ob2xkY29ubiBtZWFucyBmb3IgRFRMUyBpbiZuYnNwO2Ry YWZ0LWlldGYtbW11c2ljLWR0bHMtc2RwPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZndDs8L3NwYW4+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jmd0Ozwvc3Bhbj5UbyBwcm92aWRlIHRoZSBvcmlnaW5h bCBiYWNrZ3JvdW5kLCBpbiBjYXNlIG9mIFRDUCwmbmJzcDsmbmJzcDtzZXR1cD1ob2xkY29ubiBl c3NlbnRpYWxseSBtZWFucyB0aGF0IG5ldyBUQ1AgY29ubmVjdGlvbiBjYW5ub3QgYmUgZXN0YWJs aXNoZWQgYXMgYSByZXN1bHQgb2YgdGhpcw0KPHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZn dDs8L3NwYW4+b2ZmZXIvYW5zd2VyIGV4Y2hhbmdlLCBubyBtYXR0ZXIgd2hhdCBvdGhlciB2YWx1 ZSBoYXMgY2hhbmdlZC4gSXQgaXMgdXNlZCB0byBkaWZmZXJlbnRpYXRlIHRoZSBjYXNlIHdoZW4g Y29ubmVjdGlvbj1leGlzdGluZyBpcyB1c2VkIHdpdGggYSBwYXNzaXZlIFRDUCBlbmQNCjxzcGFu IHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mZ3Q7PC9zcGFuPnBvaW50IHdoaWNoIHdhbnRzIHRvIHJl dXNlIGV4aXN0aW5nIGNvbm5lY3Rpb24gYW5kIGlzIG5vdCByZWFkeSB0byBhY2NlcHQgYSBuZXcg VENQIGNvbm5lY3Rpb24uIEluIG90aGVyIHdvcmRzLCB3aGVuIHBhc3NpdmUgZW5kIHBvaW50IGlz IHJlYWR5IHRvIGFjY2VwdA0KPHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZndDs8L3NwYW4+ bmV3IFRDUCBjb25uZWN0aW9uLCB0aGUgb2ZmZXIgaXMgc2VudCB3aXRoIGNvbm5lY3Rpb249ZXhp c3RpbmcgYW5kIHNldHVwPXBhc3NpdmUuIFdoZW4gbm8gYWNjZXB0IG1ldGhvZCB3YXMgaXNzdWVk IG9uIHRoZSBsaXN0ZW5pbmcgc29ja2V0IG9yIGlmIGxpc3RlbmluZw0KPHNwYW4gc3R5bGU9ImNv bG9yOiMxRjQ5N0QiPiZndDs8L3NwYW4+c29ja2V0IHdhcyBhbHJlYWR5IGNsb3NlZCwgdGhlIG9m ZmVyIGlzIHNlbnQgd2l0aCBjb25uZWN0aW9uPWV4aXN0aW5nIGFuZCBzZXR1cD1ob2xkY29ubi48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mZ3Q7PC9zcGFuPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMx RjQ5N0QiPiZndDs8L3NwYW4+U2luY2UgaW4gY2FzZSBvZiBEVExTLCBubyBhY2NlcHQgbWV0aG9k IG5lZWRzIHRvIGJlIGNhbGxlZCBvbiB0aGUgc29ja2V0IGJlZm9yZSBzZW5kaW5nIGFuIG9mZmVy IGFuZCBubyBleHRyYSByZXNvdXJjZXMgYXJlIG5lZWRlZCB0byBhY2NlcHQgbmV3DQo8c3BhbiBz dHlsZT0iY29sb3I6IzFGNDk3RCI+Jmd0Ozwvc3Bhbj5jb25uZWN0aW9uLCBJIHRob3VnaHQgc2V0 dXA9aG9sZGNvbm4gd2FzIG5vdCBuZWNlc3NhcnkuIFRoaXMgaXMgd2h5IGl0IHdhcyBzcGVjaWZp ZWQgaW4mbmJzcDtkcmFmdC1pZXRmLW1tdXNpYy1kdGxzLXNkcCwgdGhhdCBzZXR1cD1ob2xkY29u biBtdXN0IG5vdCBiZQ0KPHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZndDs8L3NwYW4+dXNl ZC4mbmJzcDtPbiB0aGUgb3RoZXIgaGFuZCB0aGVyZSBpcyBubyBoYXJtIGZyb20gc2V0dXA9aG9k bGNvbm4uIEZ1cnRoZXJtb3JlIHRoZXJlIGFyZSBjZXJ0YWluIGFlc3RoZXRpYyBiZW5lZml0cyB3 aGVuIHNldHVwPWhvbGRjb25uIGlzIHVzZWQgd2l0aCBJQ0UgYW5kDQo8c3BhbiBzdHlsZT0iY29s b3I6IzFGNDk3RCI+Jmd0Ozwvc3Bhbj5EVExTLiBXaGVuIHNlbmRpbmcgYW4gdXBkYXRlIG9mZmVy IHdpdGhvdXQgSUNFIHJlc3RhcnQsIHNwZWNpZnlpbmcmbmJzcDtzZXR1cD1ob2xkY29ubiBjYW4g YmUgdXNlZCB0byBpbmRpY2F0ZSB0aGF0IGFuc3dlcmVyIGlzIG5vdCBhbGxvd2VkIHRvIHN0YXJ0 IGEgbmV3DQo8c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jmd0Ozwvc3Bhbj5EVExTIGFzc29j aWF0aW9uIGR1cmluZyB0aGlzIG9mZmVyL2Fuc3dlciBleGNoYW5nZS48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SSB0aGluayBpdOKAmXMgbXVjaCBiZXR0 ZXIgdG8gaGF2ZSBhIGdlbmVyYWwgc3RhdGVtZW50IHNheWluZyB0aGF0IHRoZSBhbnN3ZXJlciBz aG91bGQgbm90IHN0YXJ0IGEgbmV3IERUTFMgYXNzb2NpYXRpb24sIHVubGVzcyBpdCBoYXMgYSBn b29kIHJlYXNvbiBmb3IgZG9pbmcgc28uDQogSUYgdGhlIGFuc3dlcmVyIGhhcyBhIGdvb2QgcmVh c29uIGZvciBzdGFydGluZyBhIG5ldyBEVExTIGFzc29jaWF0aW9uLCBkbyB5b3UgcmVhbGx5IHdh bnQgdG8gcHJldmVudCBpdCBmcm9tIGRvaW5nIHNvPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jmd0Ozwvc3Bhbj5Tbywgb25jZSBhZ2Fpbiwg d2hhdCBzaG91bGQgd2UgZG8gd2l0aCBzZXR1cD1ob2xkY29ubj8gVXBkYXRlIGRyYWZ0LWlldGYt bW11c2ljLWR0bHMtc2RwIHRvIGRlZmluZSBoYW5kbGluZyBvZiBzZXR1cD1ob2xkY29ubiBvcg0K PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZndDs8L3NwYW4+cHJvaGliaXQgJm5ic3A7c2V0 dXA9aG9sZGNvbm4gd2l0aCZuYnNwO1RDUC9EVExTL1NDVFAgaW4mbmJzcDtkcmFmdC1pZXRmLW1t dXNpYy1zY3RwLXNkcD88c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5NeSBodW0gZ29lcyBmb3IgcHJvaGliaXRpbmcg c2V0dXA9aG9sZGNvbm4gd2l0aCBUQ1AvRFRMUy9TQ1RQIChhbmQga2VlcGluZyBkcmFmdC1kdGxz LXNkcCB1bmNoYW5nZWQpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkNo cmlzdGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_7594FB04B1934943A5C02806D1A2204B4BC7B386ESESSMB209erics_-- From nobody Wed Aug 31 10:15:59 2016 Return-Path: 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 60EA012D127 for ; Wed, 31 Aug 2016 10:15:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.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 kPUp4ZJwAhOo for ; Wed, 31 Aug 2016 10:15:56 -0700 (PDT) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A98D12D10B for ; Wed, 31 Aug 2016 10:15:56 -0700 (PDT) Received: by mail-it0-x230.google.com with SMTP id e124so20611762ith.0 for ; Wed, 31 Aug 2016 10:15:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zBxfgfRmlhGLPsn+6UMD0P8dzhdV2D1h9Ac+wXxkYRo=; b=P3AvCArQLz1TO1q1PsrrjLSABf2r8o93dn1lgGy3pNyc//RDkr86hqy+l4RRKkVywM t5UQsROyUapdGHErNaQ1eM5r5EytF1mG7vjZT58+BZQ1028MIIWv4IRr3Q2KIDhTi4FF 18Mzz19exEKXRUwTs+//OzIBP/C2H3D0QxKuQ2CkgxckmkckQ/p5wcUe+z1BlvCZEpVc IgFUyPpnukHsRj4ObxhEDgI+P7QhEAmGqUQG/t4WgoZyOjGumjSQHT+uDkDnkHzuVcFm oYwBpCn7gH4T4rLmJL645NmReiqo6vZvBfm203GmBl6HMnjeTTfGucxf6OVOs37hsBYb K+aQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=zBxfgfRmlhGLPsn+6UMD0P8dzhdV2D1h9Ac+wXxkYRo=; b=AbXjrsA95DhUV5ludqifLIHPilLjVFcB7FNVVGon7oERK/xpvLUAFlvO1d5DbZX16a jE8y6immG78wm0aV9RnKYpCezIEIqCQ2JmXwB3qa07/vn/1JkFBl2YVsbF1q2+Rfs78s mj7x6YhohVqmM/yNweKG0LUZit/ExSSgjHchABtvg9WN3qdQxCCyI8lJv4kS72AxDXwH vPdsA5Cif5uhpEpGztEcMB4PxC5MIUZJjdAxYwzaMEfJBhYMz++F8ft6fA7NdxD1Ogrt WQPxK1n/kpQPoj49SsWwuD7xoAXq/yVdWqAWJewxJ9550i7VyGOj7i9vM1m/qg1mJY0I uHqA== X-Gm-Message-State: AE9vXwP/PWuVZne5FKfkTKH/DJ2ySGMWtAjI5JoltuHe9wlrWXPhpQEU0eN/X0N2eIz4Eg== X-Received: by 10.36.116.193 with SMTP id o184mr31443467itc.14.1472663755716; Wed, 31 Aug 2016 10:15:55 -0700 (PDT) Received: from mail-it0-f54.google.com (mail-it0-f54.google.com. [209.85.214.54]) by smtp.gmail.com with ESMTPSA id o5sm12776653ith.20.2016.08.31.10.15.55 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 31 Aug 2016 10:15:55 -0700 (PDT) Received: by mail-it0-f54.google.com with SMTP id e124so20610906ith.0 for ; Wed, 31 Aug 2016 10:15:55 -0700 (PDT) X-Received: by 10.36.137.9 with SMTP id s9mr14014072itd.58.1472663754950; Wed, 31 Aug 2016 10:15:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.14.11 with HTTP; Wed, 31 Aug 2016 10:15:54 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BC7B386@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B4BC7AE69@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BC7B386@ESESSMB209.ericsson.se> From: Roman Shpount Date: Wed, 31 Aug 2016 13:15:54 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=94eb2c05bfc6fcf2c7053b613f7d Archived-At: Cc: mmusic WG Subject: Re: [MMUSIC] SDP attribute setup=holdconn X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2016 17:15:58 -0000 --94eb2c05bfc6fcf2c7053b613f7d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Aug 31, 2016 at 12:57 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > I think it=E2=80=99s much better to have a general statement saying that = the > answerer should not start a new DTLS association, unless it has a good > reason for doing so. IF the answerer has a good reason for starting a new > DTLS association, do you really want to prevent it from doing so? > > > The issue here is the difference between should not and must not. If offering TCP end point did not start the new accept call on the listening socket, answering end point MUST NOT start a new connection -- there is no socket to which it can connect. If offering ICE end point did not initiate ICE restart, answering end point MUST NOT start a new DTLS association -- new DTLS association will be running over the same 5 tuple and it could not be de-multiplexed from the previous DTLS association. The questions here are: 1. Does anybody currently or would they ever in the future send TCP offer with connection=3Dexisting and setup=3Dholdconn? Is there a real scenario w= hen new connections are no longer expected but the TCP transport is still used? 2. Is there a reason to mark ICE updates offers with setup=3Dholdconn for DTLS? Answering end point can already see that it is not an ICE restart and know that it MUST NOT start a new DTLS association. If we answer no to all of those questions, we can safely prohibit setup=3Dholdconn. I am certainly in favor of fewer things to define and implement, unless someone is using them. Regards, _____________ Roman Shpount --94eb2c05bfc6fcf2c7053b613f7d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Aug 31, 2016 at 12:57 PM, Christer Holmberg = <chr= ister.holmberg@ericsson.com> wrote:

I think it=E2=80=99s much better to have a g= eneral statement saying that the answerer should not start a new DTLS assoc= iation, unless it has a good reason for doing so. IF the answerer has a good reason for starting a new DTLS association, do = you really want to prevent it from doing so?


=

The issue here is the difference between should not and= must not. If offering TCP end point did not start the new accept call on t= he listening socket, answering end point MUST NOT start a new connection --= there is no socket to which it can connect. If offering ICE end point did = not initiate ICE restart, answering end point MUST NOT start a new DTLS ass= ociation -- new DTLS association will be running over the same 5 tuple and = it could not be de-multiplexed from the previous DTLS association. The ques= tions here are:

1. Does anybody currently or would= they ever in the future send TCP offer with connection=3Dexisting and setu= p=3Dholdconn? Is there a real scenario when new connections are no longer e= xpected but the TCP transport is still used?

2. Is= there a reason to mark ICE updates offers with setup=3Dholdconn for DTLS? = Answering end point can already see that it is not an ICE restart and know = that it MUST NOT start a new DTLS association.

If = we answer no to all of those questions, we can safely prohibit setup=3Dhold= conn. I am certainly in favor of fewer things to define and implement, unle= ss someone is using them.=C2=A0

Regards,
_____________
Roman Shpount
<= div>=C2=A0
--94eb2c05bfc6fcf2c7053b613f7d--