Re: [rtcweb] Extended Last Call: <draft-ietf-rtcweb-transports-14.txt> (Transports for WebRTC) to Proposed Standard
Magnus Westerlund <magnus.westerlund@ericsson.com> Thu, 14 July 2016 08:53 UTC
Return-Path: <magnus.westerlund@ericsson.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F234612DB6C; Thu, 14 Jul 2016 01:53:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level:
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 EgZh-3yCi84w; Thu, 14 Jul 2016 01:53:19 -0700 (PDT)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51DD812DB6A; Thu, 14 Jul 2016 01:53:18 -0700 (PDT)
X-AuditID: c1b4fb2d-f79936d0000030e4-da-578752fc5598
Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 0D.C3.12516.CF257875; Thu, 14 Jul 2016 10:53:16 +0200 (CEST)
Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.38) with Microsoft SMTP Server id 14.3.294.0; Thu, 14 Jul 2016 10:53:15 +0200
To: ietf@ietf.org
References: <20160712171212.5076.26582.idtracker@ietfa.amsl.com>
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
Message-ID: <055e8255-7ed7-b10c-43e7-b54d9542fc37@ericsson.com>
Date: Thu, 14 Jul 2016 10:53:14 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <20160712171212.5076.26582.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrELMWRmVeSWpSXmKPExsUyM2K7iu6foPZwgxOHtSwu9itaPNs4n8Wi 5+0NFou1/9rZHVg8liz5yRTAGMVlk5Kak1mWWqRvl8CV0fH5PHPBApmKpRP2MTYwrhbrYuTk kBAwkbi0ZAcbhC0mceHeeiCbi0NI4AijxJbj61ghnOWMEudf/QVzhAUaGCUeTXnFBNIiIiAs ceTRP3YQW0jAQeLSwjmsIDazQJTEopYDYDVsAhYSN380Ao3l4OAVsJd4sbIYJMwioCrRsOAK WFhUIEZifV8CSJhXQFDi5MwnLCA2p4CjxO/3c1lBSpiBOh9sLYMYLi/RvHU2M8RSbYmGpg7W CYyCs5B0z0LomIWkYwEj8ypG0eLU4uLcdCNjvdSizOTi4vw8vbzUkk2MwJA9uOW37g7G1a8d DzEKcDAq8fAuaGwLF2JNLCuuzD3EKMHBrCTC+zWwPVyINyWxsiq1KD++qDQntfgQozQHi5I4 r/9LxXAhgfTEktTs1NSC1CKYLBMHp1QDY8D6ajkWg0fXD1/+rBgq8N5X9PF32VtX/m5IZFy/ 75q06j+ndxMfZrrxsht11ay5PUn+YnyX2eF73ec/Jt1axSHbZZ1dwNL1fV247omdl3b6XNXU VDyYY/rhnODc0hd/j6fuC4kwabvLXipboiK52Ekw+985Y9Vmhot8bFe2Zzx5seADa8aKbiWW 4oxEQy3mouJEANzfWr9VAgAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/nxsCaO5VRn5G-13viUCYCjGFslI>
Cc: rtcweb@ietf.org, draft-ietf-rtcweb-transports@ietf.org, rtcweb-chairs@ietf.org
Subject: Re: [rtcweb] Extended Last Call: <draft-ietf-rtcweb-transports-14.txt> (Transports for WebRTC) to Proposed Standard
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Jul 2016 08:53:21 -0000
Hi, I have reviewed this document in IETF last call, sorry I missed the last WG last call, thus in this stage instead. I do support the publication of this document. However, I think the below comments do need to be considered before publication approval. 1. Section 3.3: When a client gathers all IPv6 addresses on a host, and both temporary addresses and permanent addresses of the same scope are present, the client SHOULD discard the permanent addresses before exposing addresses to the application or using them in ICE. This is consistent with the default policy described in [RFC6724]. If some of the temporary IPv6 addresses, but not all, are marked deprecated, the client SHOULD discard the deprecated addresses. I haven't noticed this before, but if you have both permanent and temporary addresses, can all the temporary be marked deprecated? If that can occur, does this specification need to say something in this case which should be used, a deprecated temporary or a permanent one? 2. Section 3.4: If TCP connections are used, RTP framing according to [RFC4571] MUST be used, both for the RTP packets and for the DTLS packets used to carry data channels. I think the last part of this sentence, unintentionally excludes the DTLS handshake packets. The ICE TCP spec also specifies that the STUN connectivity checks are using RFC4571 framing. Thus, I think some reformulation of this sentence is in order. 3. Section 3.5: WebRTC implementations MUST support multiplexing of DTLS and RTP over the same port pair, as described in the DTLS-SRTP specification [RFC5764], section 5.1.2. All application layer protocol payloads over this DTLS connection are SCTP packets. This text should reference also the update to RFC5764: https://datatracker.ietf.org/doc/draft-ietf-avtcore-rfc5764-mux-fixes/ That document is publication requested so even as normative reference it will hopefully have minimal impact on the publication progress of this document. 4. Section 4.2: The implementation MAY turn off use of DSCP markings if it detects symptoms of unexpected behaviour like priority inversion or blocking of packets with certain DSCP markings. The detection of these conditions is implementation dependent. As raised on the TSVWG and RTCWEB mailing list recently in regards to draft-ietf-tsvwg-rtcweb-qos there have been a recent study (https://irtf.org/anrw/2016/anrw16-final17.pdf) showing that non zero DSCP values resulted in consistent failures in 10-13% of the tested paths. So I think it worth considering if this text needs to be sharpen, and possibly actually point to a solution that needs to be specified? 5. Section 8.1: [I-D.martinsen-mmusic-ice-dualstack-fairness] Martinsen, P., Reddy, T., and P. Patil, "ICE IPv4/IPv6 Dual Stack Fairness", draft-martinsen-mmusic-ice- dualstack-fairness-02 (work in progress), February 2015. Can be updated as this is now an WG item in ICE. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ----------------------------------------------------------------------
- Re: [rtcweb] Extended Last Call: <draft-ietf-rtcw… Harald Alvestrand
- Re: [rtcweb] Extended Last Call: <draft-ietf-rtcw… Magnus Westerlund
- [rtcweb] Extended Last Call: <draft-ietf-rtcweb-t… The IESG