Re: [tram] Mirja Kühlewind's Discuss on draft-ietf-tram-turnbis-27: (with DISCUSS and COMMENT)

"Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com> Wed, 24 July 2019 05:48 UTC

Return-Path: <tirumaleswarreddy_konda@mcafee.com>
X-Original-To: tram@ietfa.amsl.com
Delivered-To: tram@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0012120281 for <tram@ietfa.amsl.com>; Tue, 23 Jul 2019 22:48:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4
X-Spam-Level:
X-Spam-Status: No, score=-4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=mcafee.com
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 nHUgtm82FjLk for <tram@ietfa.amsl.com>; Tue, 23 Jul 2019 22:48:22 -0700 (PDT)
Received: from us-smtp-delivery-210.mimecast.com (us-smtp-delivery-210.mimecast.com [63.128.21.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D6BF12007C for <tram@ietf.org>; Tue, 23 Jul 2019 22:48:22 -0700 (PDT)
X-NAI-Header: Modified by McAfee Email Gateway (5500)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1563946546; h=ARC-Seal: ARC-Message-Signature:ARC-Authentication-Results: From:To:CC:Subject:Thread-Topic:Thread-Index: Date:Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: dlp-product:dlp-version:dlp-reaction:authentication-results: x-originating-ip:x-ms-publictraffictype:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-ms-exchange-purlcount:x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers:x-forefront-prvs: x-forefront-antispam-report:received-spf:x-ms-exchange-senderadcheck: x-microsoft-antispam-message-info:Content-Type: Content-Transfer-Encoding:MIME-Version:X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-CrossTenant-mailboxtype: X-MS-Exchange-CrossTenant-userprincipalname: X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Level: X-NAI-Spam-Threshold:X-NAI-Spam-Score:X-NAI-Spam-Version; bh=/IDWN1VdRXIoTbxV6ZJUIGQb6L/jMp/XmUIsge /4rK8=; b=hcYHoGdLk1fJLhz3QrWbuEcTPbS6IfsTZPCXTcGP XE+L2NAVDHP5McMSAm3Odyl0F5qvOmtaNKNUFgFh5x4AZiaswe balrF8TfWTl0lxd0LWZ+itCVxNCctbw6iQHyuzhGsZHboVQ3oH /D1uPMCq6jRVqusZFtzzuNux/Jbohlo=
Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-156-78pU0ACzMm-1E_28oTQCSw-1; Wed, 24 Jul 2019 01:47:05 -0400
Received: from DNVEXAPP1N04.corpzone.internalzone.com (unknown [10.44.48.88]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 1536_08a5_68cad2a7_9e19_4ce9_846c_078592276669; Tue, 23 Jul 2019 23:35:45 -0600
Received: from DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 23 Jul 2019 23:46:19 -0600
Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Tue, 23 Jul 2019 23:46:19 -0600
Received: from NAM03-BY2-obe.outbound.protection.outlook.com (10.44.176.243) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 23 Jul 2019 23:46:07 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=iOSU85KQpAamZFgEVawbpAk3/wBa8yTW5coj2glIBPRjETfobXPEFikN+qe/Xuo1sbjVPWKH6xTd5yoahcyKOAbYoIq40wkh8aK6eYBrHo3QO3ahpPylpX7LVwd+osm4/rVjngQGpxXV/hH4zj/lrtvajIw93+RnFqvOSo5mTs7N81NX3n3ntZ6S+io52IX6XU5K59aNEADdyV1PQ/MYn6JnuIh2IaTPh0StnqCXf6lVl1+YQAQq9mtDkS9fI4nCxT1LPbJeSGTxEObCTbg9gAfzZZ4GZ9zfSKuJeWxfunEn5HJq8GNn4X78aJxiLdDscnuY5QZxJ9I+hsbHxNwu+w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/IDWN1VdRXIoTbxV6ZJUIGQb6L/jMp/XmUIsge/4rK8=; b=TYlETHYr6198cEbx80nh3Wv5SuDj6XyhjvrawD3hpOSy9JMPMzqIMYZOayxOMWj63JBLJ0XfuUd+GMpzN+iO1QIM74ue8N/BDFYp2MeHmLBXyMLFvjkQkbHxsWwJg0ptvZM15B0w1fvXU5YkvP2a8X2G6183A+aWnBElRxpGYH6B7gbhhnVYVejk9fDH0BYYeFo94NRty1FKR07ribRiPZ9U7+VJ88D8umCGRnF9u1AAzp7BBGNQaWB6S3eeu8cHKWRNyxfcDVf15Fq9Ipcpdga1UQi0Vtfkfd/82QTPY4snddJAUeyWtt9DLmEH/2hE+D2hgNj+o/jnmay+DyDQ8w==
ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=mcafee.com;dmarc=pass action=none header.from=mcafee.com;dkim=pass header.d=mcafee.com;arc=none
Received: from DM5PR16MB1705.namprd16.prod.outlook.com (10.172.44.147) by DM5PR16MB1452.namprd16.prod.outlook.com (10.173.211.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2094.15; Wed, 24 Jul 2019 05:46:05 +0000
Received: from DM5PR16MB1705.namprd16.prod.outlook.com ([fe80::6c22:21e:7528:3dc5]) by DM5PR16MB1705.namprd16.prod.outlook.com ([fe80::6c22:21e:7528:3dc5%6]) with mapi id 15.20.2115.005; Wed, 24 Jul 2019 05:46:05 +0000
From: "Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com>
To: Mirja Kühlewind <ietf@kuehlewind.net>, The IESG <iesg@ietf.org>
CC: "tram-chairs@ietf.org" <tram-chairs@ietf.org>, "draft-ietf-tram-turnbis@ietf.org" <draft-ietf-tram-turnbis@ietf.org>, "tram@ietf.org" <tram@ietf.org>, "brandon.williams@akamai.com" <brandon.williams@akamai.com>
Thread-Topic: [tram] Mirja Kühlewind's Discuss on draft-ietf-tram-turnbis-27: (with DISCUSS and COMMENT)
Thread-Index: AQHVNzftWkN2G8olS0aOBDqJ1prLPKbG+S0ggAecAUCACbymgA==
Date: Wed, 24 Jul 2019 05:46:05 +0000
Message-ID: <DM5PR16MB170510A0A350D1B5B2447E03EAC60@DM5PR16MB1705.namprd16.prod.outlook.com>
References: <156277411459.15353.13243689830942672102.idtracker@ietfa.amsl.com> <DM5PR16MB17057CF81A9137D3887BA65BEACF0@DM5PR16MB1705.namprd16.prod.outlook.com> <DM5PR16MB170554281EFA84C4CC8A950FEAC90@DM5PR16MB1705.namprd16.prod.outlook.com>
In-Reply-To: <DM5PR16MB170554281EFA84C4CC8A950FEAC90@DM5PR16MB1705.namprd16.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
dlp-product: dlpe-windows
dlp-version: 11.3.0.16
dlp-reaction: no-action
x-originating-ip: [185.221.69.46]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 78559412-fc09-47b7-275d-08d70ffa386a
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:DM5PR16MB1452;
x-ms-traffictypediagnostic: DM5PR16MB1452:
x-ms-exchange-purlcount: 7
x-microsoft-antispam-prvs: <DM5PR16MB14522308492E3FEC1DAA76ADEAC60@DM5PR16MB1452.namprd16.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0108A997B2
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(376002)(396003)(366004)(39860400002)(136003)(189003)(199004)(13464003)(32952001)(51914003)(76094002)(224303003)(4326008)(66556008)(25786009)(66446008)(64756008)(81156014)(66066001)(54906003)(5660300002)(81166006)(6116002)(66946007)(52536014)(76116006)(66476007)(3846002)(53936002)(478600001)(80792005)(966005)(6246003)(9686003)(229853002)(55016002)(6306002)(6436002)(86362001)(102836004)(14454004)(6506007)(66574012)(53546011)(26005)(2906002)(33656002)(71200400001)(74316002)(71190400001)(7696005)(305945005)(316002)(476003)(76176011)(11346002)(486006)(68736007)(446003)(8936002)(7736002)(5024004)(186003)(99286004)(256004)(30864003)(110136005)(14444005)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1452; H:DM5PR16MB1705.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: q4RMj386kiHW+Hy5wi62Tb6XwahZ0q+dbSj3DhPNG8BdEcKrzkkJVmnMkghw849xOSV3+FkdQRcv++pHUhIqpMxX1+D6KuWjNUcmkd4X+b47gM7hJAUxLKcVFj5N2mgP3GrJviKHGG2qpFwhbvEeA8L1lahcO6LXHBxc+5cEVpwYJbRk6WHno/yp6tJly08z8j4kaHerRluMYaimE/wVALZd3cz4u//AhEYbMZM8oJJEDLRSG0qEXqYhDzgrs6FYnNZ26xSqFIVSnI3CXgP2Ys9JjFiRWnAXWdZ5Zmqc+10ej5CPV3p+VKk1E/puswjgSN3sKL0o7M/+6vBRhVrwNSvkC6pW+StxDKKft5LF0FPsKvYXxBZWOnJk4aHeSsdhwdqCCaNBHOnPZpeY/HuQKuvUhHeZJhtJNwCrP6jJ4ZU=
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 78559412-fc09-47b7-275d-08d70ffa386a
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jul 2019 05:46:05.7545 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: TirumaleswarReddy_Konda@McAfee.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1452
X-OriginatorOrg: mcafee.com
X-NAI-Spam-Flag: NO
X-NAI-Spam-Level:
X-NAI-Spam-Threshold: 15
X-NAI-Spam-Score: 0.2
X-NAI-Spam-Version: 2.3.0.9418 : core <6596> : inlines <7125> : streams <1828256> : uri <2871684>
X-MC-Unique: 78pU0ACzMm-1E_28oTQCSw-1
X-Mimecast-Spam-Score: 0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Archived-At: <https://mailarchive.ietf.org/arch/msg/tram/FwqCXEmq6dgTko-9-Ipu6ie1KO0>
Subject: Re: [tram] Mirja Kühlewind's Discuss on draft-ietf-tram-turnbis-27: (with DISCUSS and COMMENT)
X-BeenThere: tram@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." <tram.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tram>, <mailto:tram-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tram/>
List-Post: <mailto:tram@ietf.org>
List-Help: <mailto:tram-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tram>, <mailto:tram-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Jul 2019 05:48:25 -0000

Hi Mirja,

We have updated the draft to address your Discuss and comments (https://tools.ietf.org/rfcdiff?url2=draft-ietf-tram-turnbis-28.txt).  Please have a look.

Cheers,
-Tiru

> -----Original Message-----
> From: Konda, Tirumaleswar Reddy
> Sent: Wednesday, July 17, 2019 6:06 PM
> To: Mirja Kühlewind <ietf@kuehlewind.net>; The IESG <iesg@ietf.org>
> Cc: tram-chairs@ietf.org; draft-ietf-tram-turnbis@ietf.org; tram@ietf.org;
> brandon.williams@akamai.com
> Subject: RE: [tram] Mirja Kühlewind's Discuss on draft-ietf-tram-turnbis-27:
> (with DISCUSS and COMMENT)
> 
> Hi Mirja,
> 
> I have updated the draft to address your Discuss and comments (see
> https://github.com/tireddy2/TURNbis/blob/master/Diff%20%20draft-ietf-
> tram-turnbis-27.txt%20-%20draft-ietf-tram-turnbis-28.pdf).
> Please have a look.
> 
> Cheers,
> -Tiru
> 
> > -----Original Message-----
> > From: Konda, Tirumaleswar Reddy
> > Sent: Monday, July 15, 2019 12:01 PM
> > To: Mirja Kühlewind <ietf@kuehlewind.net>; The IESG <iesg@ietf.org>
> > Cc: tram-chairs@ietf.org; draft-ietf-tram-turnbis@ietf.org;
> > tram@ietf.org; brandon.williams@akamai.com
> > Subject: RE: [tram] Mirja Kühlewind's Discuss on draft-ietf-tram-turnbis-27:
> > (with DISCUSS and COMMENT)
> >
> > Hi Mirja,
> >
> > Thanks for the review. Please see inline
> >
> > > -----Original Message-----
> > > From: tram <tram-bounces@ietf.org> On Behalf Of Mirja Kühlewind via
> > > Datatracker
> > > Sent: Wednesday, July 10, 2019 9:25 PM
> > > To: The IESG <iesg@ietf.org>
> > > Cc: tram-chairs@ietf.org; draft-ietf-tram-turnbis@ietf.org;
> > > tram@ietf.org; brandon.williams@akamai.com
> > > Subject: [tram] Mirja Kühlewind's Discuss on
> > > draft-ietf-tram-turnbis-27: (with DISCUSS and COMMENT)
> > >
> > > This email originated from outside of the organization. Do not click
> > > links or open attachments unless you recognize the sender and know
> > > the content is safe.
> > >
> > > Mirja Kühlewind has entered the following ballot position for
> > > draft-ietf-tram-turnbis-27: Discuss
> > >
> > > 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-tram-turnbis/
> > >
> > >
> > >
> > > --------------------------------------------------------------------
> > > --
> > > DISCUSS:
> > > --------------------------------------------------------------------
> > > --
> > >
> > > One quick discussion which probably is only an oversight and
> > > therefore should be easy got fix:
> > >
> > > I'm bit confused about the requirement on using authentication. This
> > > draft says in section 5 (as RFC5766 does):
> > >
> > > "The server MUST demand that all requests
> > >    from the client be authenticated using this mechanism, or that a
> > >    equally strong or stronger mechanism for client authentication is
> > >    used."
> > >
> > > However, RFC 8155 which is even now cited in this draft, updates
> > > RFC5766 and relaxes this requirement. Later in the section 7.2. this
> > > draft
> > says:
> > >
> > > "The server SHOULD require that the request be authenticated."
> > >
> > > I assume the requirement in section 5 is an oversight?
> >
> > Yes, removed the requirement in Section 5.
> >
> > >
> > > I also recommend to only specify this requirement normatively in one
> place.
> >
> > Done, updated step 1 in Section 5 to address the comment from Ben as
> > follows:
> >
> >    1.   The TURN server provided by the local or access network MAY
> >         allow unauthenticated request in order to accept Allocation
> >         requests from new and/or guest users in the network who do not
> >         necessarily possess long term credentials for STUN
> >         authentication and its security implications are discussed in
> >         [RFC8155].  Otherwise, the server MUST require that the request
> >         be authenticated.  If the request is authenticated, the
> >         authentication MUST be done either using the long-term
> >         credential mechanism of [I-D.ietf-tram-stunbis] or the STUN
> >         Extension for Third-Party Authorization [RFC7635] unless the
> >         client and server agree to use another mechanism through some
> >         procedure outside the scope of this document.
> >
> > >
> > >
> > > --------------------------------------------------------------------
> > > --
> > > COMMENT:
> > > --------------------------------------------------------------------
> > > --
> > >
> > > Some other technical comments/questions:
> > >
> > > 1) Sec 3.7:
> > > "or use UDP fragmentation [I-D.ietf-tsvwg-udp-options]."
> > > I believe the possibility to use UDP fragmentation was brought up by
> > > the TSV-ART review (Thanks Joe!). However, I would like to mention
> > > that this can only be used if supported by both endpoints and that
> > > should probably also be remarked here. The next sentence in the
> > > draft indicated this by saying "until UDP fragmentation support is
> > > available", however, this actually seem to be editorially a bit
> > > misplaced there and could explain more. See also this text in
> > > draft-ietf-tsvwg-udp-options:
> > >
> > > "FRAG needs to be used with extreme care because it will present
> > >    incorrect datagram boundaries to a legacy receiver, unless encoded
> > >    as LITE data (see Section 5.8)."
> > >
> > > Also note that draft-ietf-tsvwg-udp-options is still under
> > > development and we don't have much deployment experience with it
> yet.
> >
> > Yes, Joe suggest the above change. I have added the following line:
> > Note that the UDP fragmentation option needs to be supported by both
> > endpoints, and at the time of writing of this document, UDP
> > fragmentation support is under discussion and is not deployed.
> >
> > >
> > > And further, in the same section. There is also
> > > draft-ietf-tsvwg-datagram- plpmtud on "Packetization Layer Path MTU
> > > Discovery for Datagram Transports". Please also be aware that there
> > > is an extensive TSV-ART for draft-ietf-tram-stun-pmtud. Both might
> > > impact the final content of this section.
> >
> > The draft does not refer to draft-ietf-tsvwg-datagram- plpmtud.
> >
> > >
> > > 2) sec 11.5:
> > > "When the server receives an ICMP packet, the server verifies that the
> > >    type is either 3 or 11 for an ICMPv4 [RFC0792] packet or either 1, 2,
> > >    or 3 for an ICMPv6 [RFC4443] packet."
> > > Restricting to a set of known types, doesn't seem to support future
> > > extensibility very well...
> >
> > Good point, added the following lines:
> > New ICMP types or codes can be defined in future specifications. If
> > the server receives an ICMP error packet, and the new type or code
> > field can help the client to make use of the ICMP error notification
> > and generate feedback to the application layer, the server sends the
> > Data indication with an ICMP attribute conveying the new ICMP type or
> code.
> >
> > >
> > > 3) sec 12.5:
> > > "Over TCP and TLS-over-TCP, the ChannelData message MUST be padded
> > to
> > >    a multiple of four bytes in order to ensure the alignment of
> > >    subsequent messages."
> > > Not exactly sure why this is useful...? Is this to align with STUN
> > > and therefore make processing somehow easier? Is that really needed.
> > > And exception should be easy to implement and should save some bytes
> > > which is the as I understood it the whole purpose of channels, no?
> >
> > This behavior is not new, it is defined and deployed in TURN
> > https://tools.ietf.org/html/rfc5766#section-11.5
> >
> > >
> > > 4) 12.6:
> > > "Note that if
> > >    the Length field in the ChannelData message is 0, then there will be
> > >    no data in the UDP datagram, but the UDP datagram is still formed and
> > >    sent."
> > > Can you maybe add some more text and explain why this is useful?
> >
> > Sure, added reference to Section 4.1 in
> > https://tools.ietf.org/html/rfc6263
> >
> > >
> > > 5) sec 15:
> > > RFC6824 will soon be obsoleted by draft-ietf-mptcp-rfc6824bis and
> > > please s/TCP multi-path/Multipath TCP/.
> >
> > Thanks, updated.
> >
> > >
> > > 6) Just a thought looking at section 14 and 16: It could have been
> > > nice to provide an ECN feedback field from the server to the client
> > > in case a ECN marked packet is received from the peer... however, I
> > > guess that future work at this point in the process...
> > >
> > > 7) sec 18.13: Maybe I missed this because I reviewed this doc over 3
> > > days, but is only the ICMP Attribute send to the client or is the
> > > actual ICMP packets or as much as possible of that packet includes as well?
> >
> > Yes, only the ICMP attribute is sent to the client.
> >
> > >
> > > 8) sec 23:
> > > "Response: TURN will no longer be needed once there are no longer any
> > >    NATs.  Unfortunately, as of the date of publication of this document,
> > >    it no longer seems very likely that NATs will go away any time soon.
> > >    However, the need for TURN will also decrease as the number of NATs
> > >    with the mapping property of Endpoint-Independent Mapping
> [RFC4787]
> > >    increases."
> > > Yes... so you don't think that IPv6 will be any help here?
> >
> > Yes, IPv6 will not help in some scenarios, updated Introduction to list them.
> >
> >    In many enterprise networks, direct UDP transmissions are not
> >    permitted between clients on the internal networks and external IP
> >    addresses.  To permit media sessions in such a situation to use UDP
> >    and to avoid forcing the media sessions through TCP, Enterprise
> >    Firewall can be configured to allow UDP traffic relayed through an
> >    Enterprise relay server.  This scenario is required to be supported
> >    by the WebRTC requirements (Section 2.3.5.1 in [RFC7478]).  In
> >    addition, in a SIP or WebRTC call, if the user wants IP location
> >    privacy from the peer then the client can select a relay server
> >    offering IP location privacy and only convey the relayed candidates
> >    to the peer for ICE connectivity checks (see Section 4.2.4 in
> >    [I-D.ietf-rtcweb-security]).
> >
> > >
> > > Editorial comments:
> > >
> > > 1) Sec 6:
> > > "The relayed transport address MUST be unique across all
> > >    allocations, so it can be used to uniquely identify the allocation.
> > >
> > >    Both the relayed transport address and the 5-tuple MUST be unique
> > >    across all allocations, so either one can be used to uniquely
> > >    identify the allocation, [...]"
> > > These two sentences seem quite redundant. The first one was added in
> > > this draft. The second one was already there in RFC5766.
> >
> > Thanks, removed the second sentence.
> >
> > >
> > > 2) sec 7.1:
> > > "Since this specification only
> > >    allows UDP between the server and the peers, it is RECOMMENDED
> > > that [...]"
> > > Wordings ("only allows") seems weird to me given use of other
> > > proposals is at least to some extend discussed.
> >
> > The specification does not allow any other protocol other than UDP
> > between the server and peers (As you know, UDP is the preferred
> > transport for media streams).
> >
> > >
> > > Nits:
> > > sec 7.1.: s/the client pick a currently unused transport address/the
> > > client picks a currently unused transport address/
> >
> > Fixed.
> >
> > Cheers,
> > -Tiru
> > >
> > >
> > > _______________________________________________
> > > tram mailing list
> > > tram@ietf.org
> > > https://www.ietf.org/mailman/listinfo/tram