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

[Magnus Westerlund <[e-mail]>]

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  [phone]
Färögatan 6                 | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------