Re: [AVTCORE] Roman Danyliw's No Objection on draft-ietf-payload-tsvcis-03: (with COMMENT)

"Roni Even (A)" <roni.even@huawei.com> Wed, 02 October 2019 05:43 UTC

Return-Path: <roni.even@huawei.com>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34840120091; Tue, 1 Oct 2019 22:43:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 h85F7tMoM_vT; Tue, 1 Oct 2019 22:43:27 -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 C2F89120041; Tue, 1 Oct 2019 22:43:27 -0700 (PDT)
Received: from lhreml707-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 1F05A4737961267FADE1; Wed, 2 Oct 2019 06:43:26 +0100 (IST)
Received: from DGGEMM424-HUB.china.huawei.com (10.1.198.41) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 2 Oct 2019 06:43:25 +0100
Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.89]) by dggemm424-hub.china.huawei.com ([10.1.198.41]) with mapi id 14.03.0439.000; Wed, 2 Oct 2019 13:43:23 +0800
From: "Roni Even (A)" <roni.even@huawei.com>
To: Roman Danyliw <rdd@cert.org>, The IESG <iesg@ietf.org>
CC: "draft-ietf-payload-tsvcis@ietf.org" <draft-ietf-payload-tsvcis@ietf.org>, Ali Begen <ali.begen@networked.media>, "avtcore-chairs@ietf.org" <avtcore-chairs@ietf.org>, "avt@ietf.org" <avt@ietf.org>
Thread-Topic: Roman Danyliw's No Objection on draft-ietf-payload-tsvcis-03: (with COMMENT)
Thread-Index: AQHVeGELrh1O1EJ2UEqrXdC8pBE1WadG1rxg
Date: Wed, 02 Oct 2019 05:43:22 +0000
Message-ID: <6E58094ECC8D8344914996DAD28F1CCD23D78E68@DGGEMM506-MBX.china.huawei.com>
References: <156993860610.23632.14112555733358406719.idtracker@ietfa.amsl.com>
In-Reply-To: <156993860610.23632.14112555733358406719.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.52]
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/avt/uSxbd3VBmxoP6myvd1yLPWcb1Lw>
Subject: Re: [AVTCORE] Roman Danyliw's No Objection on draft-ietf-payload-tsvcis-03: (with COMMENT)
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/avt/>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Oct 2019 05:43:30 -0000

Hi,
Section 8, Per “Applications SHOULD use one or more appropriate strong security mechanisms”, what exactly is the “SHOULD” requiring?
 As discussed in RFC7201 RTP is used in different application scenarios, as such RTP cannot mandate to the application (for example, SIP, WEBRTC, RTSP,...) which security mechanism to use if at all. We can only say that the application SHOULS use . Note that in some cases the security is not done by the application by its infrastructure (tunnels, ...)
Roni Even


-----Original Message-----
From: Roman Danyliw via Datatracker [mailto:noreply@ietf.org] 
Sent: Tuesday, October 01, 2019 5:03 PM
To: The IESG
Cc: draft-ietf-payload-tsvcis@ietf.org; Ali Begen; avtcore-chairs@ietf.org; ali.begen@networked.media; avt@ietf.org
Subject: Roman Danyliw's No Objection on draft-ietf-payload-tsvcis-03: (with COMMENT)

Roman Danyliw has entered the following ballot position for
draft-ietf-payload-tsvcis-03: 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-payload-tsvcis/



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

Section 2.  Per “In most IP-based network deployments, standard link encryption methods (SRTP , VPNs, FIPS 140 link encryptors or Type 1 Ethernet encryptors) would be used to secure the RTP speech contents.”, the inclusion of STRP in this list of “link encryption” methods was surprising.  The other methods typically provide a service agnostic tunnel but STRP is application specific (and doesn’t protect a link).

Section 8, Per “Applications SHOULD use one or more appropriate strong security mechanisms”, what exactly is the “SHOULD” requiring?