Connection Establishment for Media Anchoring (CEMA) for the Message Session Relay Protocol (MSRP)
draft-ietf-simple-msrp-cema-07

Section 3:
   "Support of the extension is optional."

Do you mean "OPTIONAL"?

   "MSRP endpoints that
   support CEMA are required to use RFC 4975 behavior in cases where
   they detect that the CEMA extension cannot be enabled."
   
Do you mean "REQUIRED"?

Section 4.1:

   In the following cases, where there is a Middlebox in the network,
   the CEMA extension cannot be used...

Do you mean "MUST NOT be used"?

Section 4.2:

   When the offerer receives an SDP answer, if the MSRP media
   description of the SDP answer does not contain an SDP 'msrp-cema'
   attribute, the offerer MUST check the criteria below.  If either or
   all of the criteria is met, the offerer MUST fallback to RFC 4975
   behavior, by sending a new SDP offer according to the procedures in
   RFC 4975 and RFC 4976.

This is mostly editorial, but since it involves 2119 language, I think it's worth fixing: The first MUST is redundant. If the offerer MUST do things based on the criteria, there is no need to say that you MUST check the criteria. (Also, "either" is the wrong word when there are more than two criteria. You meant "any".) Instead maybe:

   The offerer MUST fallback to RFC 4975 behavior, by sending a new
   SDP offer according to the procedures in RFC 4975 and RFC 4976, if
   it receives an SDP answer whose description does not contain an SDP
   'msrp-cema' attribute, any of the following criteria are met:
   
   [1...
    2...
    3...]
   
   The new offer MUST NOT contain an SDP 'msrp-cema' attribute.

It seems to me that the security considerations are somewhat underspecified, and I find the concept of a TLS B2BUA unsatisfying, but I will let folks from the security area comment on those aspects of the specification.

s1: strike lawful intercept (I see Stephen made this a discuss otherwise I would have made it one too)

s2: Fingerprint Based TLS AUthentication:
    r/self-signed TLS certificate/self-signed certificate
    r/fingerprint/fingerprint (i.e., a hash of the self-signed certificate)

s2: Name Based TLS Authethication
    r/certificate authority/certification authority
    r/SubjectAltName parameter/SubjectAltName extension

s3: r/Support of the extension is optional./
      Support of the extension is OPTIONAL.

s7.2: certificates are by definition public so I'm a little confused by the following:

  1.  TLS certificates together with support of interacting with a
      Certificate Management Service [RFC6072], to which it publishes the
      public version of its own self-signed certificate and from which it
      fetches on demand the public certificates of other endpoints.

Maybe: 

  1.  TLS certificates together with support of interacting with a
      Certificate Management Service [RFC6072], to which it publishes
      its self-signed certificate and from which it
      fetches on demand the self-signed certificates of other endpoints.

s7.2: (Stephen caught this too) MIKEY-TICKET is a normative reference.

s7.2: I share the same concerns Stephen has wrt the fingerprint authentication.

s7.3: Probably worth a pointer to the SIP issues based on the following:

  Even with seemingly end-to-end media integrity, at the time of the
  publication of this document there are other vulnerabilities in MSRP,
  due to vulnerabilities in the SIP signaling.

Thanks for addressing my discuss points, I've cleared.