Re: [tram] Mirja Kühlewind's Discuss on draft-ietf-tram-turnbis-27: (with DISCUSS and COMMENT)
"Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com> Sat, 27 July 2019 15:14 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 7048612001B for <tram@ietfa.amsl.com>; Sat, 27 Jul 2019 08:14:16 -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 31KjCGd_dNBM for <tram@ietfa.amsl.com>; Sat, 27 Jul 2019 08:14:13 -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 69E2612001A for <tram@ietf.org>; Sat, 27 Jul 2019 08:14:13 -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=1564240424; 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=xdSPZMWOJH6ZMqIhPaa2504mJ+UR6K9CG1ZRg6 ORDFw=; b=rN+8XSFdtSULTC0lbU1K8mVWOHIiogS0+BRJM9or mor4hIgxNQwCVQH7cJ0UTprpkfohcZBAeEUWw+IhB75AoIOgWm BeTGrDp9wAncA4mT2pk28F27q31zaGCbOS1Cakp2wFVRY/AYH2 eUH0h+IYd2n3KXPhF5mg46aMt7a4gKI=
Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-81-tki46S4GOgKwDeAG_jJcwg-1; Sat, 27 Jul 2019 11:13:05 -0400
Received: from DNVEXAPP1N05.corpzone.internalzone.com (DNVEXAPP1N05.corpzone.internalzone.com [10.44.48.89]) by MIVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 0c28_5388_acca985b_bbda_4fb3_9e33_586c876278f0; Sat, 27 Jul 2019 11:13:43 -0400
Received: from DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sat, 27 Jul 2019 09:13:00 -0600
Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Sat, 27 Jul 2019 09:13:00 -0600
Received: from NAM02-CY1-obe.outbound.protection.outlook.com (10.44.176.243) by edge.mcafee.com (10.44.176.66) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sat, 27 Jul 2019 09:12:58 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GRfrwasAeiASq8k81TdWFE6YM7mq8pOzyBcUexEyQeVI6AFnCHanfHuR935EIU9rCEfCZ9jf5/Pe7tEOPKNidALWN3d6h6kV6MNArNCG+qnxRydhxpvS9kW0nnHLY5i5yv+dXve67WHEfNRfwI/Jr2dTYGLq7yNik5NR/uZkUWuSfaJLcCjkRjU3UZ7DJX+1dati6LBEnOOEBka2iYAWH8/ZNNy7usqlMbq761/zcmWJ2eAKb5SKyOfr9a5Jp34mdPBHhpnRXt98su3Eg9Bp8nelb6OT6chVQN/oHySOHsH4pGIiezRYFXwrKqIv4MTcOAdZ5JWqCPhLNepqhjk04g==
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=xdSPZMWOJH6ZMqIhPaa2504mJ+UR6K9CG1ZRg6ORDFw=; b=QFI2zrcU5PurostWOOgkcVAQpl/6hcVhl6Jr2dvdcwpshz+1GN/cJDL8X75GjfKWreOSXxcXKeYOSs6Gaemeb+GQR5qsCdbw4EzYfd/IkLDF9mmaPiQUDGEUP7Cwb3BLXq/s8Q9OeVI7pFSLAV9gx7y+AfQanMiDxMUMKgDwWbE4UHQpr3kRv/tuVwgOs67L7+FHI7RFb7l1kyT2EVbUnAubHoXKBneNFJ9/HebWOQpYLXfFUGSGOUgw4gPHmOYg2s4oCUc5dvHigzv8B/QyRw94PmsIk+7+9j5UfOn/PP5J43vRkoGTXGumeo2Q3kxM7mx1WWk/U2SDepsLLPcy7Q==
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 DM5PR16MB2245.namprd16.prod.outlook.com (52.132.142.34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2094.17; Sat, 27 Jul 2019 15:12:58 +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; Sat, 27 Jul 2019 15:12:58 +0000
From: "Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com>
To: Mirja Kuehlewind <ietf@kuehlewind.net>
CC: The IESG <iesg@ietf.org>, "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+S0ggBcsNYCAAIPT0A==
Date: Sat, 27 Jul 2019 15:12:58 +0000
Message-ID: <DM5PR16MB17056584304E83DBE4793DAAEAC30@DM5PR16MB1705.namprd16.prod.outlook.com>
References: <156277411459.15353.13243689830942672102.idtracker@ietfa.amsl.com> <DM5PR16MB17057CF81A9137D3887BA65BEACF0@DM5PR16MB1705.namprd16.prod.outlook.com> <54A55B10-F74D-4D55-9CC9-B2FB31F1E26A@kuehlewind.net>
In-Reply-To: <54A55B10-F74D-4D55-9CC9-B2FB31F1E26A@kuehlewind.net>
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.17
dlp-reaction: no-action
x-originating-ip: [185.221.69.46]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: f1882376-ec66-4c9c-679b-08d712a4e8bf
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:DM5PR16MB2245;
x-ms-traffictypediagnostic: DM5PR16MB2245:
x-ms-exchange-purlcount: 6
x-microsoft-antispam-prvs: <DM5PR16MB2245AA40E3C5F6F4A83FC53BEAC30@DM5PR16MB2245.namprd16.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 01110342A5
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(396003)(376002)(366004)(346002)(136003)(76094002)(32952001)(51914003)(199004)(13464003)(189003)(102836004)(4326008)(229853002)(71190400001)(6916009)(99286004)(14454004)(186003)(74316002)(64756008)(66574012)(11346002)(66556008)(66476007)(316002)(14444005)(66946007)(26005)(446003)(81166006)(6246003)(86362001)(76116006)(7736002)(5660300002)(256004)(5024004)(71200400001)(52536014)(81156014)(53936002)(54906003)(9686003)(3846002)(2906002)(486006)(6306002)(80792005)(66066001)(8936002)(6436002)(966005)(33656002)(224303003)(6506007)(25786009)(478600001)(76176011)(53546011)(305945005)(66446008)(30864003)(55016002)(476003)(7696005)(68736007)(6116002)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB2245; H:DM5PR16MB1705.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: rtXFJNPVils3Vr4WWsEQgisTE6mdtbjnpWtIxz73CLCGBcAbWOCcVILzJMswb8EoeSGLEGhV3w6F4klq/ULkODOVJ361AuT7TKIDPwOm7sxMaDz38h0Z6fVZViM/YTOXtonfV5EFDFs7HLkucGbgCFavHSD0mcMojrqvfB8swl8+eCbI053hqgbGvjpd7U1GY26BLStKjAFoDtinU9H8j0AqSUvZDqWdIXMiQnBnnnM/16IjEXl/IHMQEbNk4lj7jkRs6bjXQBCHCYjiLvh9YEnKoFiPoEL29S5UbVdwZyvyZ68ZfGk9FhGv3I1Xsaui8232FQJ8hlLdg3ryynT21ABt6MVhjLfvZ/OAzt25Es1rLTP+0K+xwWCaaVhXubgGO971Y0MB6O+9wOPZm7F9+PjEn7BSpYuyP8ziIrrK6YY=
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: f1882376-ec66-4c9c-679b-08d712a4e8bf
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jul 2019 15:12:58.3247 (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: DM5PR16MB2245
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 <6599> : inlines <7127> : streams <1828580> : uri <2873664>
X-MC-Unique: tki46S4GOgKwDeAG_jJcwg-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/jY9ZSLm1l9u_CBS0aC48ChwPCu8>
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: Sat, 27 Jul 2019 15:14:17 -0000
Hi Mirja, Please see inline > -----Original Message----- > From: Mirja Kuehlewind <ietf@kuehlewind.net> > Sent: Saturday, July 27, 2019 12:37 PM > To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com> > Cc: The IESG <iesg@ietf.org>; 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) > > 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. > > Hi Tiru, > > Thanks for your quick reply and update and sorry for my delay! I’ve just > cleared my discuss but see two quick comments in line below. > > > On 15. Jul 2019, at 02:31, Konda, Tirumaleswar Reddy > <TirumaleswarReddy_Konda@McAfee.com> wrote: > > > > 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. > > Yes, but I though you maybe should cite it as well :-) Sure, updated text as follows: The Packetized Path MTU Discovery algorithm defined in [RFC4821] is one such algorithm and a set of algorithms are defined in [I-D.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. > > Here also, I can imagine that sending as much of the ICMP packet as possible > could be useful as well. Was that considered? Yes, the decision was not send the ICMP packet (Please see https://mailarchive.ietf.org/arch/msg/tram/dk5PzVhBzzCUSAftYVoSpYQl0o4) Cheers, -Tiru > > Mirja > > > > > >> > >> 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
- [tram] Mirja Kühlewind's Discuss on draft-ietf-tr… Mirja Kühlewind via Datatracker
- Re: [tram] Mirja Kühlewind's Discuss on draft-iet… Konda, Tirumaleswar Reddy
- Re: [tram] Mirja Kühlewind's Discuss on draft-iet… Konda, Tirumaleswar Reddy
- Re: [tram] Mirja Kühlewind's Discuss on draft-iet… Konda, Tirumaleswar Reddy
- Re: [tram] Mirja Kühlewind's Discuss on draft-iet… Mirja Kuehlewind
- Re: [tram] Mirja Kühlewind's Discuss on draft-iet… Konda, Tirumaleswar Reddy