IETF Logo Mail Archive

Re: [MMUSIC] New draft version: draft-ietf-mmusic-data-channel-sdpneg-01

Paul Kyzivat <pkyzivat@alum.mit.edu> Tue, 10 March 2015 16:05 UTC

Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC2951A1B19 for <mmusic@ietfa.amsl.com>; Tue, 10 Mar 2015 09:05:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.565
X-Spam-Level:
X-Spam-Status: No, score=0.565 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_15=0.6, J_CHICKENPOX_74=0.6, J_CHICKENPOX_75=0.6, SPF_SOFTFAIL=0.665] autolearn=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 dE2X6pRFugc2 for <mmusic@ietfa.amsl.com>; Tue, 10 Mar 2015 09:05:30 -0700 (PDT)
Received: from resqmta-ch2-12v.sys.comcast.net (resqmta-ch2-12v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:44]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 807141A1B0C for <mmusic@ietf.org>; Tue, 10 Mar 2015 09:05:30 -0700 (PDT)
Received: from resomta-ch2-11v.sys.comcast.net ([69.252.207.107]) by resqmta-ch2-12v.sys.comcast.net with comcast id 1s5V1q0052Ka2Q501s5Vq0; Tue, 10 Mar 2015 16:05:29 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-11v.sys.comcast.net with comcast id 1s5V1q0093Ge9ey01s5VVq; Tue, 10 Mar 2015 16:05:29 +0000
Message-ID: <54FF1649.6070700@alum.mit.edu>
Date: Tue, 10 Mar 2015 12:05:29 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: mmusic@ietf.org
References: <54FD7E59.6020309@alcatel-lucent.com> <54FDBD60.8060900@alum.mit.edu> <54FF0C10.7040206@alcatel-lucent.com>
In-Reply-To: <54FF0C10.7040206@alcatel-lucent.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1426003529; bh=HC+SndY/751SIyc72yPNbzYFdKlmM8azMv5KJN7ZtII=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=v7sYZILosA9o8eyewXL3m1iLtvk9xNcc1z7JaUIQtPDqxSIdy7iphc0lRRY3C1r4L VwtQJ2ibxL8DSxsBD/ZWl2UuiOY2pS/noFQmp8aUmijN1rsFUB41SzwxWUpITnSM7m sV2/As7lU2rKzzyFVmVWHgYI+MXheqL3Fxg4CHwAgd7T/KEAfislxXwKN5nAslhXTL 2dlgbT2WZVJsViQ6a4QQJjYbECtPjIJvoO1zMtSXuqe/vGNyrhup9j3VXdQcjCpniz OcyE4YaT92PBmmSdKLICIjun1s5d+TUYco9mj0ikGHVNKvbF74ObtYlmJ9T1aZeQbm MmgJXjlwIpaWA==
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/Tztyns3HDeugw_nj8Ubz4kMrzX4>
Subject: Re: [MMUSIC] New draft version: draft-ietf-mmusic-data-channel-sdpneg-01
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Mar 2015 16:05:31 -0000

WFM

On 3/10/15 11:21 AM, Juergen Stoetzer-Bradler wrote:
> Paul,
>
> Thank you for further comments.
> Please see my remarks inserted below.
>
> Thanks,
> Juergen
>
> On 09.03.2015 16:33, Paul Kyzivat wrote:
>> Juergen,
>>
>> In general this is good. I have a few remaining comments:
>>
>> Section 5.2.2 says:
>>
>>    ... If an SDP offer contains both of
>>    these parameters then such an SDP offer will be rejected.
>>
>> The use of "will" is confusing - it isn't normative. IMO it should
>> either use "MUST" or else it should say such usage is undefined.
>
> [Juergen] The intention is indeed to request the answerer to reject sch
> an SDP offer.
> Thus we could say:
> "... If an SDP offer contains both of these parameters then such an SDP
> offer MUST be rejected."
>
>>
>> Then:
>>
>>    The SDP answer shall echo the same subprotocol, max-retr, max-time,
>>    ordered parameters, if those were present in the offer, and may
>>
>> Again, "shall" is non-normative. IMO this should be SHALL or MUST.
>
> [Juergen] Agreed. Would propose to say:
> "The SDP answer SHALL echo the same subprotocol, max-retr, max-time,
> ordered parameters, ..."
>
>>
>> Then:
>>
>>    Data channel types defined in [I-D.ietf-rtcweb-data-protocol] are
>>    mapped to SDP in the following manner:
>>
>>    DATA_CHANNEL_RELIABLE
>>          a=dcmap:2 subprotocol="BFCP";label="channel 2"
>>    ...
>>
>> "This is a bit unclear because these are *examples* using BFCP. (It
>> also uses 'ordered=0' rather than 'ordered=false'. I think it would be
>> clearer as:
>>
>>    Data channel types defined in [I-D.ietf-rtcweb-data-protocol] are
>>    mapped to SDP a=dcmap parameters in the following manner:
>>
>>    DATA_CHANNEL_RELIABLE
>>          ordered=true
>>
>>    DATA_CHANNEL_RELIABLE_UNORDERED
>>          ordered=false
>>
>>    DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT
>>          ordered=true;max-retr=NNN
>>
>>    DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT_UNORDERED
>>          ordered=false;max-retr=NNN
>>
>>    DATA_CHANNEL_PARTIAL_RELIABLE_TIMED
>>          ordered=true;max-time=NNN
>>
>>    DATA_CHANNEL_PARTIAL_RELIABLE_TIMED_UNORDERED
>>          ordered=false;max-time=NNN
>>
>> ('ordered=true' is default and may be omitted.)"
>
> [Juergen] We fully agree an will update the text as you propose in next
> draft -02.
>
>>
>>     Thanks,
>>     Paul
>>
> [snip]
>
>
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>

v2.23.0 | Report a Bug | By Email