Subject: [MMUSIC] SDP comments to draft-ietf-simple-msrp-cema-02.txt

From: "Miguel A. Garcia" <[email-masked]>
Date: Sun, 2 Oct 2011 18:55:51 +0200

Here are some comments related to the new "msrp-cema" attribute defined 
in draft-ietf-simple-msrp-cema-02.txt

- I am missing a section that has the syntax of the new extension. While 
it's true that the syntax is fairly simple, any extension should clearly 
specify the syntax (in this case, ABNF). This formal syntax could be:

        attribute          /= msrp-cema-attr
        ; attribute defined in RFC 4566
        msrp-cema-attr     = "msrp-cema"

I also suggest to add a section titled "The SDP 'msrp-cema' attribute" 
where you first give an overview of what the attribute does at a very 
high level (in this case, it indicates support for the CEMA mechanism), 
and then you include the formal syntax.

- General. When you mention an SDP attribute, the "a=" is nor part of the 
attribute itself. So, it is not correct to say:

   the a=path attribute

The correct one is:

   the 'path' attribute

- The title of sections 4.2 and 4.3 could be improved. There is not such 
things as "MSRP offer" or "MSRP answer". We have the notion of "SDP 
offer" and "SDP answer", as well as "SDP offerer" and "SDP answerer", in 
which case, the sections should be titled "SDP offerer procedures" and 
"SDP answerer procedures".

Furthermore, it is quite confusing to follow these sections because they 
refer to the "MSRP endpoint" and the "remote MSRP endpoint". Obviously, 
what is the "MSRP endpoint" in Section 4.2, becomes the "remote MSRP 
endpoint" in Section 4.3, and vice versa. I suggest to re-write these 
sections in terms of "the SDP offerer" and "the SDP answerer". This will 
make the text much clearer, and the terms will not reverse when we change 
sections.

- Section 4.1. I think those three bullet points are the real 
"Applicability Statement" rather than something general to the mechanism. 
To me, they should be moved to Section 3.

- Sections 4.1 to 4.3, the text says that an "MSRP endpoint becomes 
'active'" or 'passive'. I was confused with what the text was meaning. I 
guess it means from the point of view of the TCP connection used for 
MSRP. I think this should be clarified.

- Section 4.2, 2nd bullet point. I am missing that this bullet point says 
how to populate the c/m lines in SDP. Perhaps it is covered by the first 
paragraph of this Section 4.2, which basically refers to RFC 4975 and 
4976. But then, the third bullet point describes the m/c line, so, at 
this point in time, I had my doubts whether bullet point forgets to say 
something of the c/m line or it is populated as per RFC 4975/4976.

- In order to add a bit of clarity and separate the generation of the SDP 
offer from receiving the SDP answer, I would suggest to add the following 
text at the beginning of the paragraph that introduces the SDP answer in 
Section 4.2:

  "When receiving an SDP answer," and then continue with the current text 
"if the MSRP media description of the SDP answer ..."

- Section 4.2, 1st bullet point of the SDP answer (and in other parts of 
4.2 and 4.3), the text says: "... does not match the information ...". I 
have a problem with the word "match". Most likely, "match" implies 
"equality". So we are talking of the equality of the c/m lines with a 
URI. These two can never be equal. In particular, a URI can eve be a 
domain name or host name, in which case, will never be equal to an IP 
address and a port number. Most likely you want to say "resolve", but I 
am not sure.

- I was trying to analyze if all the different cases are described in 
Section 4.2. Here is one that I believe is not covered: "if the SDP 
answer does not contain an 'msrp-cema' attribute and none of the 3 
conditions are met".

- Section 4.3, first paragraph. The text says "MUST reject". I think it 
would be nice to have a motivation to have such a strong action.

- Section 5.4. The text says:  "Middleboxes
    cannot be deployed in environments that require end-to-end SDP
    protection using SIP identity [RFC4916]."

I am trying to see the connection between "end-to-end SDP protection" and 
"SIP identity". I would have removed one of them from the text, depending 
on what you want to say. Perhaps you want to say that the CEMA extension 
does not work if "end-to-end integrity protection of SDP is used".

- Section 7.1 does not mention the registry where IANA has to operate. 
Start the section saying:

  "This document instructs IANA to add a attribute to the 'att-field 
(media level only)' registry of the SDP parameters registry, according to 
the following data"

- Section 7.1, "Purpose". I will not speak of the "sending UA" in an SDP 
registry, but of the "SDP creator".

Nits:

- First paragraph in Section 6.3:  " ... manipulating message content is 
CEMA provides ..."
Most likely s/is/in

- I would add formal references whenever an RFC is mentioned, especially 
if they are part of a normative sentence. For example, "... according to 
the procedures of RFC 4975 [RFC4975]".

- I believe the text should say "a Message Session ..." rather than "an 
Message Session".

But "an MSRP message", rather than "a MSRP message"

- Section 4.1, first paragraph. Replace "... and what SDP information" 
with "... and which SDP information"

- Section 4.1, first paragraph, at the end. Replace "TLS connection for 
the MSRP messages" with "TLS connection for sending and receiving MSRP 
messages".

/Miguel

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain