Re: [MMUSIC] [Gen-art] Gen-ART Last Call review of draft-ietf-mmusic-dtls-sdp-22

Paul Kyzivat <pkyzivat@alum.mit.edu> Tue, 28 March 2017 03:55 UTC

Return-Path: <pkyzivat@alum.mit.edu>
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 E871612025C for <mmusic@ietfa.amsl.com>; Mon, 27 Mar 2017 20:55:24 -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 cVEMbj2XDfef for <mmusic@ietfa.amsl.com>; Mon, 27 Mar 2017 20:55:23 -0700 (PDT)
Received: from resqmta-ch2-08v.sys.comcast.net (resqmta-ch2-08v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:40]) (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 B7A851275C5 for <mmusic@ietf.org>; Mon, 27 Mar 2017 20:55:23 -0700 (PDT)
Received: from resomta-ch2-15v.sys.comcast.net ([69.252.207.111]) by resqmta-ch2-08v.sys.comcast.net with SMTP id siE2cBXcNAfZssiE7cg3ek; Tue, 28 Mar 2017 03:55:23 +0000
Received: from [192.168.1.110] ([24.62.227.142]) by resomta-ch2-15v.sys.comcast.net with SMTP id siE5cJISFXTPjsiE6cQbNP; Tue, 28 Mar 2017 03:55:22 +0000
To: Christer Holmberg <christer.holmberg@ericsson.com>, "draft-ietf-mmusic-dtls-sdp.all@ietf.org" <draft-ietf-mmusic-dtls-sdp.all@ietf.org>
References: <60b45113-8012-9a6c-2019-dea5b57ca7bb@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B4CB31018@ESESSMB109.ericsson.se>
Cc: General Area Review Team <gen-art@ietf.org>, IETF MMUSIC WG <mmusic@ietf.org>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <c546ae96-4d6e-6da6-a004-e12d6f1969fb@alum.mit.edu>
Date: Mon, 27 Mar 2017 23:55:21 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4CB31018@ESESSMB109.ericsson.se>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-CMAE-Envelope: MS4wfN3D4IC3cv+/bBIQmfIVvHcsXf/3O1o/SIhzE14N60fVlUG+KG0csSiaKcX0e6YOf724Kp6Y8ZpJFcTGCowPQR91FL7PMVlh1m8GsZii5quVbY+5SVvV IB54wB7PJbs9E3lwpX13ZHMT1GtHYQqeynSiH5QOv3m5aX3vL04tUMnR1QF5uXWTRYt63s9TtkTFuaUjRgUtYC2YPvMx18vptQlDb9ykVB842PU/Ur1AySG9 DernHihVKml/C9GQtgmEPTElVWvh7hfCKxiz5z+0BUmtdlk+SZtipADp6CIF7PG2
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/dbKYhn2TYbMVUaV4JFeN9f8N8Dg>
Subject: Re: [MMUSIC] [Gen-art] Gen-ART Last Call review of draft-ietf-mmusic-dtls-sdp-22
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.22
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: <https://mailarchive.ietf.org/arch/browse/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, 28 Mar 2017 03:55:25 -0000

Hi Christer,

[trimming]

On 3/27/17 7:42 PM, Christer Holmberg wrote:
> Hi Paul,
>
> Thanks for your review! Please see inline.
>
> (1) Nit:
>
>> Regarding the following in section 5.1:
>>
>>    When an offerer or answerer indicates that it wants to establish a
>>    new DTLS association, it needs to make sure that media packets in the
>>    existing DTLS association and new DTLS association can be de-
>>    multiplexed.
>>
>> This text presumes there is an existing association. To explicitly cover the case where there is not, I suggest the following:
>>
>>    When an offerer or answerer indicates that it wants to establish a
>>    new DTLS association to replace an existing association, it needs to
>>    ensure that media packets in the existing DTLS association and new
>>    DTLS association can be de-multiplexed.
>
> I could do that. Or, I could use say "make sure that media packets in *any* existing DTLS association"

That would also be fine. I have no preference.

> (3) Minor:
>
>> I concur with the comments in the ops-dir review by Carlos Pignataro regarding the formatting of
>> section 9. He didn't suggest a fix. Perhaps some special marker (e.g. "|" or "<" and ">") can be placed
>> in every line to indicate it is test from or for another document - either at the beginning or end of every line.
>
> I have never seen that been used before - not in documents I have authored, or in documents written by others.

Yes, I know. I was just trying to be constructive by suggesting 
*something*. My first thought was to indent. But that would require 
reflowing all the text to avoid exceeding line length. That seemed like 
a bad idea.

I'm not attached to this solution. I've complained about the same 
problem in other drafts, but nobody came up with a solution so they 
didn't get resolved. Here I'm not the only one who sees a problem, so 
maybe it is worth trying to find a solution.

	Thanks,
	Paul