Re: [rtcweb] Working Group Last Call: draft-ietf-rtcweb-jsep-19.txt

[Magnus Westerlund <[e-mail]>]

Hi,

I have reviewed the changes in the JSEP-19 document. For Appendix B see 
separate email.

1. The deleting of the "implementation requirements" (previously in 
5.1.1) makes me wonder if the "usage requirements" and specifically the 
bullets in the current 5.1.1 is actually needed. What I can see this is 
a 2119 normative rehashing of requirements that already exist elsewhere 
in the RTCWeb document suite.

    All session descriptions handled by JSEP implementations, both local
    and remote, MUST indicate support for the following specifications.
    If any of these are absent, this omission MUST be treated as an
    error.

The above actually make some sense to ensure that these features are 
negotiated.


    o  ICE, as specified in [RFC5245], MUST be used.  Note that the
       remote endpoint may use a Lite implementation; implementations
       MUST properly handle remote endpoints which do ICE-Lite.

Transport specification does not mandate use of ICE, only support. But, 
the MUST be used in this paragraph, appears to be unnecessary. This due 
the above paragraph. Which results in either a received offer indicates 
ICE or one rejects it, and one must include it in those one offers. 
Which will result in usage.

But, I don't think it actually is JSEP's role to mandate use of other 
than how the "signalling" element in the API surface is to be treated.


    o  DTLS [RFC6347] or DTLS-SRTP [RFC5763], MUST be used, as
       appropriate for the media type, as specified in
       [I-D.ietf-rtcweb-security-arch]

This is also double specification in the "MUST be used" as that is clear 
from the sec-arch document in section 5.5. that it must be used.


    The SDES SRTP keying mechanism from [RFC4568] MUST NOT be used, as
    discussed in [I-D.ietf-rtcweb-security-arch].

Also covered in Section 5.5. of Sec-ARCH.



2. Section 5.1.2:

    o  The profile in any "m=" line in any answer MUST exactly match the
       profile provided in the offer.

    o  Any profile matching the following patterns MUST be accepted:
       "RTP/[S]AVP[F]" and "(UDP/TCP)/TLS/RTP/SAVP[F]"

These two are in conflict in cases when the answer to an 
"UDP/TLS/RTP/SAVPF" offer comes back as UDP/TLS/RTP/SAVP. Then the first 
can't be fulfilled, but the second is. Isn't the rule "It either is an 
exact match or matches the following patterns"?


Cheers

Magnus Westerlund

----------------------------------------------------------------------
Media Technologies, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Färögatan 6                 | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------