Subject: [rtcweb] Extended Last Call: <draft-ietf-rtcweb-transports-14.txt> (Transports for WebRTC) to Proposed Standard

From: The IESG <[email-masked]>
Date: Tue, 12 Jul 2016 10:12:12 -0700

The IESG has received a request from the Real-Time Communication in
WEB-browsers WG (rtcweb) to consider the following document:
- 'Transports for WebRTC'
  <draft-ietf-rtcweb-transports-14.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2016-08-01. Exceptionally, comments may be
sent to [email-masked] instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

   This document describes the data transport protocols used by WebRTC,
   including the protocols used for interaction with intermediate boxes
   such as firewalls, relays and NAT boxes.

The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-rtcweb-transports/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-rtcweb-transports/ballot/

No IPR declarations have been submitted directly on this I-D.

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 14 Jul 2016 10:53:14 +0200

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: [email-masked]
----------------------------------------------------------------------

---

From: Harald Alvestrand <[email-masked]>
Date: Sat, 16 Jul 2016 07:05:36 +0200

Thank you, I have filed these as issue #22 to #26 at
github.com/rtcweb-wg/rtcweb-transport/issues.

I think issue #25, which I entitled "DSCP bleaching", may be the
difficult one to resolve.