Subject: [clue] New version of signaling document

From: Robert Hansen <[email-masked]>
Date: Wed, 05 Aug 2015 14:09:18 +0100

Signaling document updated to -06 - sorry it took a few more days than 
expected.

Changes are as follows:

    o  State machine interactions updated to match versions in -04 of
       protocol doc.
    o  Section on encoding updated to specify both encID and encodingID
       from data model doc.
    o  Removed the limitations on describing H264 encoding limits using
       SDP syntax as an open issue.
    o  Previous draft had SRTP and DTLS mandatory to implement and to use
       on CLUE- controlled m lines.  Current version has DTLS mandatory
       to implement, and 'security' mandatory to use but does not define
       what that security is.
    o  Terminology reference to framework doc reinforced.  All
       terminology that duplicates framework removed.  All text updated
       with capitalisation that matches framework document's terminology.
    o  SDP example syntax updated to match that of ietf-clue-datachannel
       and hence ietf-mmusic-data-channel-sdpneg.

Of those changes, the security requirements related to the RTP is likely 
to be the section that requires active discussion. This is the current 
text, based on my intepretation of the discussions from the IETF meeting:

    As such all CLUE-capable
    devices MUST support key negotiation and receiver intent assurance
    via DTLS [RFC5763] on CLUE-controlled RTP "m" lines.  All CLUE-
    controlled RTP "m" lines must be secured and implemented using
    mechanisms such as SRTP [RFC3711]; no specific security mechanisms
    are made mandatory to use due to the issues addressed in [RFC7202].
    Due to the requirements of backwards compatibility, these is not a
    mandatory requirement for non-CLUE-controlled "m" lines.

Rob

---

From: Christian Groves <[email-masked]>
Date: Tue, 11 Aug 2015 15:38:15 +1000

Hello Rob,

Thanks for the update. With respect to the procedures for disabling CLUE 
mid-call (clause 4.5.4.3) I think there needs to be some discussion 
about CLUE data channel closure via an SCTP reset (i.e. clause 3.2.7). 
It may be simpler to reference clause 
5.2.4/draft-ietf-mmusic-data-channel-sdpneg-04 which has the complete 
procedure for closing data channel sub-protocols (i.e. CLUE)

Regards, Christian

On 5/08/2015 11:09 PM, Robert Hansen wrote:
> Of those changes, the security requirements related to the RTP is 
> likely to be the section that requires active discussion. This is the 
> current text, based on my intepretation of the discussions from the 
> IETF meeting:
>
>    As such all CLUE-capable
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue
>