Reviewer: Russ Mundy
Review result: Almost Ready

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.

The Interoperability Profile for Relay User Equipment (draft-ietf-rum-rue-09) document is well structured and written as well as providing very understandable information about the Video Relay Service (VRS) and the Relay User Equipment (RUE).  Although I have very limited exposure to this technology area, the functional aspects of this profile seem well thought out and described in the draft. 

As an Interoperability Profile, I don't find it surprising that there is absence of specific (or even general) security requirements in the current draft.  However, this may result in interoperability challenges because RUE and VRS make different choices with respect to the (50+) normative references particularly with respect to security implementations. For example, RFC 7575 defines an "opportunistic security" scenario that might (or might not) be appropriate for some of the RUE activities perhaps anonymous calls as described in 5.2.1. Also, it might (or might not) be acceptable for implementations to negotiate the use of earlier versions of TLS or cryptographic algorithms for some (or none) of the capabilities defined in sections 5 through 10 of the draft.  These sections (5 - 10) describe a sufficiently different set of functions that it seems as though some of them might have different security requirements but no specifics security requirements (besides the use of TLS and HTTPS), it would be useful to state the security requirements for each of the sub sections.

Although I think that it would be useful to include other security details, identifying at least the basic security requirements that must be provided for each of the defined sub-sections in sections 5 -10 of the draft seems essential.  I.e., does each one of the functions require Authentication, Confidentiality and Integrity as defined in section 1 of RFC 8446 (or another RFC) or do some of the defined capabilities only require a subset of these security services?  Or do some of the defined functions need something different?

Identifying the specific security services required for each of the defined sub-sections would provide more useful information for implementors and deployers who will depend on this specification as well as more consistent security properties in the deployments.

Regards,
Russ