Re: [MMUSIC] WG Last Call for draft-ietf-mmusic-data-channel-sdpneg-11

Paul Kyzivat <> Mon, 16 January 2017 19:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EFBB41299F6 for <>; Mon, 16 Jan 2017 11:56:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.899
X-Spam-Status: No, score=-5.899 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, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1apSNPcnlSXj for <>; Mon, 16 Jan 2017 11:56:04 -0800 (PST)
Received: from ( [IPv6:2001:558:fe16:19:96:114:154:164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C37D41299F7 for <>; Mon, 16 Jan 2017 11:56:04 -0800 (PST)
Received: from ([]) by with SMTP id TDN3c6D3CMqbUTDNrcxHJ2; Mon, 16 Jan 2017 19:56:03 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=q20161114; t=1484596563; bh=OGbC2nGYKDKOcuXtMdplCK9y6RfkWRy3qHUdT9DtLF4=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=MZvlkqRPL8fm+Cq79QJvZKvD1rmwCnjl2pyc1ZSNAxqKT9IOPJlLj60nYR8qJuc86 GQyDqpJDwoLgL1KNrl4VXV/8zEn3uLR5m6nMYpeXfP4iFiaZ6YsaXikG8imtNjzuga hl0aKQpSoTYHsx2m8j3rzXnD8CqKcG6pVPTKwsqzPowVOUSsCvH+K+gUtWaEXlv/oZ 2/X34C/cUothhQxIhZh8FapMkUK4Mff06vagQXo/3s2JGF7J5GqgqvSK3trMNrXi7M wwxHSt0unkk9t8r4lSjX1qKlOmAmgsZ1Oqb42H9B4Jc/LwYlge2u1UqWLe6mbWspSV NTXpFD1caVYSQ==
Received: from [] ([]) by with SMTP id TDNqcHNjNTnqpTDNrcETgC; Mon, 16 Jan 2017 19:56:03 +0000
References: <>
From: Paul Kyzivat <>
Message-ID: <>
Date: Mon, 16 Jan 2017 14:56:02 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.6.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [MMUSIC] WG Last Call for draft-ietf-mmusic-data-channel-sdpneg-11
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, 16 Jan 2017 19:56:06 -0000

I've followed this document closely throughout its development.
In preparation for this message I reviewed the document again. I found 
some things that need to be addressed:

1) MAJOR: Section and various other places:

I can find nothing here or elsewhere in the document that says whether 
the the stream id in an offer is the id on which the offerer will 
receive, or the ID on which it will send. Of course this is irrelevant 
if both ends agree to use the same id, but that isn't required.

For this to interact properly with attributes for individual streams (in 
dcsa) I think it will be necessary for this to be consistent with the 
say SDP negotiates media sections - namely that the SDP in an offer 
identifies where the offerer wants to *receive* the media.

It will probably require changes in a variety of places to get this 
sorted out.

2) MINOR: Section 5.1.1 says:

    The intention in exchanging these attributes is to create, on two
    peers, without use of DCEP [I-D.ietf-rtcweb-data-protocol], matched
    pairs of oppositely directed data channels having the same set of
    attributes.  It is assumed that the data channel properties
    (reliable/partially reliable, ordered/unordered) are suitable per the
    subprotocol transport requirements.

In this, "matched pairs of oppositely directed data channels" is 
improper terminology. Each channel *is* a matched pair, of oppositely 
directed SCTP streams.

3) MINOR: Section 5.1.2 says:

    In the SDP, each data channel declaration MAY also be followed by
    other media level SDP attributes, ...

I'm concerned with "followed", because that imposes an ordering 
requirement on attributes. Generally there is no ordering requirement on 
SDP attributes other than that they up front if they are session level 
or follow a particular m= line if they are media-level.

Certainly it will be more readable to group these things in a logical 
way, but I don't think it should be required. So I suggest changing 
"followed" to "accompanied".

4) NIT: IdNits reports 1 error and 8 warnings. These need to be addressed.


On 1/16/17 6:45 AM, Bo Burman wrote:
> This email starts a one week WG last call on version -11 of this draft
> that ends on January 23, 2017.
> There was a previous WG last call on version -09 that resulted in some
> minor document updates.
> The intended status of this document is standards track (Proposed Standard).
> Please review and provide any comments you may have on the document.
> Comments should be sent to the document authors and the MMUSIC WG list.
> If you review the document but do not have any comments, please send a
> note to that effect as well.
> Please also forward this WGLC to any other interested parties who may be
> able to review the draft, asking them to also direct their comments to
> the authors and the list as above.
> The document can be retrieved here:
> Thank you!
>         Bo Burman (MMUSIC co-chair)
> _______________________________________________
> mmusic mailing list