Re: [MMUSIC] Mirja Kühlewind's No Objection on draft-ietf-mmusic-data-channel-sdpneg-25: (with COMMENT)

"Roni Even (A)" <roni.even@huawei.com> Thu, 11 April 2019 09:50 UTC

Return-Path: <roni.even@huawei.com>
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 A00E41202B3; Thu, 11 Apr 2019 02:50:59 -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, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=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 8QbuRMmPZoRz; Thu, 11 Apr 2019 02:50:57 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 6FC091202B1; Thu, 11 Apr 2019 02:50:57 -0700 (PDT)
Received: from lhreml702-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 9135FF767181897E29DA; Thu, 11 Apr 2019 10:50:55 +0100 (IST)
Received: from lhreml709-chm.china.huawei.com (10.201.108.58) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 11 Apr 2019 10:50:48 +0100
Received: from lhreml709-chm.china.huawei.com (10.201.108.58) by lhreml709-chm.china.huawei.com (10.201.108.58) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Thu, 11 Apr 2019 10:50:47 +0100
Received: from DGGEMM401-HUB.china.huawei.com (10.3.20.209) by lhreml709-chm.china.huawei.com (10.201.108.58) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1713.5 via Frontend Transport; Thu, 11 Apr 2019 10:50:47 +0100
Received: from DGGEMM526-MBX.china.huawei.com ([169.254.8.138]) by DGGEMM401-HUB.china.huawei.com ([10.3.20.209]) with mapi id 14.03.0415.000; Thu, 11 Apr 2019 17:50:19 +0800
From: "Roni Even (A)" <roni.even@huawei.com>
To: =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= <ietf@kuehlewind.net>, The IESG <iesg@ietf.org>
CC: "draft-ietf-mmusic-data-channel-sdpneg@ietf.org" <draft-ietf-mmusic-data-channel-sdpneg@ietf.org>, Bo Burman <bo.burman@ericsson.com>, "mmusic-chairs@ietf.org" <mmusic-chairs@ietf.org>, "mmusic@ietf.org" <mmusic@ietf.org>
Thread-Topic: =?utf-8?B?TWlyamEgS8O8aGxld2luZCdzIE5vIE9iamVjdGlvbiBvbiBkcmFmdC1pZXRm?= =?utf-8?Q?-mmusic-data-channel-sdpneg-25:_(with_COMMENT)?=
Thread-Index: AQHU68sw/YSnkciZbUuyklXvy0atWKY2vu7A
Date: Thu, 11 Apr 2019 09:50:19 +0000
Message-ID: <6E58094ECC8D8344914996DAD28F1CCD18CDB5D4@dggemm526-mbx.china.huawei.com>
References: <155448109368.10029.4766956503581760917.idtracker@ietfa.amsl.com>
In-Reply-To: <155448109368.10029.4766956503581760917.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.200.202.102]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/nLJXyqAKXBDpS-w4sC2tNMa6jx8>
Subject: Re: [MMUSIC] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draf?= =?utf-8?q?t-ietf-mmusic-data-channel-sdpneg-25=3A_=28with_COMMENT=29?=
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 11 Apr 2019 09:51:00 -0000

Hi Mirja,
Thanks

See inline
Roni

-----Original Message-----
From: Mirja Kühlewind via Datatracker [mailto:noreply@ietf.org] 
Sent: Friday, April 05, 2019 7:18 PM
To: The IESG
Cc: draft-ietf-mmusic-data-channel-sdpneg@ietf.org; Bo Burman; mmusic-chairs@ietf.org; bo.burman@ericsson.com; mmusic@ietf.org
Subject: Mirja Kühlewind's No Objection on draft-ietf-mmusic-data-channel-sdpneg-25: (with COMMENT)

Mirja Kühlewind has entered the following ballot position for
draft-ietf-mmusic-data-channel-sdpneg-25: 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-data-channel-sdpneg/



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

Thanks for quickly addressing the comments from the TSV-ART review regarding interactions with SCTP (and thanks Micheal T. for the review!)!

One minor, more editorial comment on max-time parameter:
draft-ietf-rtcweb-data-protocol says "This life-time starts when providing the user message to the protocol stack.". While a reference to draft-ietf-rtcweb-data-protocol is given respectively, I would recommend to also clarify in this draft which time frame is meant given this time frame includes and end-to-end delays.
[RE] are you suggesting to repeat the text from the RTCweb document " A user message will no longer be transmitted or retransmitted after a  specified life-time given in milliseconds in the 'max-time' parameter. The life-time starts
         when providing the user message to the protocol stack."
   

As a side note: not sure it is necessary to expand IETF (Internet Engineering Task Force) (see sec 5.2) in an IETF RFC but the RFC editor might tell you...
[RE] will remove