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(_dot_)westerlund(_at_)ericsson(_dot_)com
----------------------------------------------------------------------