Re: [Simple] SDP comments to draft-ietf-simple-msrp-cema-02.txt - Miguel's comments

[Christer Holmberg <[e-mail]>]

Hi,

I have removed the MMUSIC list from this reply, and added the SIMPLE list, as there should be no issues with the SDP attribute related comments.


> 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.

I suggest the following new section:

	"5.  The SDP 'msrp-cema' attribute

	5.1.  General

   		The SDP 'msrp-cema' attribute is used by MSRP entities to indicate
   		support of the CEMA extension, according to the procedures in
   		Sections 4.2 and 4.3.

	5.2.  Syntax

   		This section describes the syntax extensions to the ABNF syntax
   		defined in RFC 4566 required for the SDP 'msrp-cema' attribute.  The
   		ABNF defined in this specification is conformant to RFC 5234
   		[RFC5234].

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


----------------


> - 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

I will change as suggested.


----------------

 
> - 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".

I suggest chaning to "MSRP SDP offerer procedures" and "MSRP 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.

Christian Schmidt had a similar comment. I will change as suggested.


----------------


> - 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.

The bullets gives an overview when there will be a fallback, but the extension as such is still applicable in those cases.


----------------


> - 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.

I suggest adding a reference to RFC 6135 (Comedia for MSRP) to the first occurence.


----------------

 
> - 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.

The 2nd bullet is covered by RFC 4975.

The 3rd bullet, however, is not according to RFC 4976, which is the reason it is explicitly said how to populate the c/m line.


----------------


> - 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 ..."

In order to allign with the current style, I suggest to say:

	"When the offerer receives an SDP answer, if the..."


----------------


> - 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.

The text talks about matching of "address information", so I don't think that is the same as matching the whole c/m line with the URI.

But, I can add a note, saying that if the URI contains a domain name, it needs to be resolved into an IP address before the matching is done.


----------------


> - 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".

The last paragraph of the chapter talks about the case when none of the 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.

I will add text saying that the reason for this is that the SDP answerer assumes that a middlebox, that do NOT support CEMA, has modified the c/m line of the SDP offer.


----------------


> - 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".


Others have also commented on the text. I suggest to modify the text in the following way:

	   	"This document assumes that Middleboxes are able to modify the SDP
   		address information associated with the MSRP media.  Middleboxes
   		cannot be deployed in environments that require end-to-end SDP
   		protection using SIP identity [RFC4916]."


----------------


> - 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"

In order to better be alligned with the current text, I suggest to add the following modified text:

		"This document instructs IANA to add a attribute to the 'att-field 
		(media level only)' registry of the SDP parameters registry, according 
		to the information provided in this section."


----------------


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

I suggest modifying to "creator of the SDP".


	"8.1.  IANA Registration of the SDP 'msrp-cema' attribute

   		This document instructs IANA to add a attribute to the 'att-field
	   	(media level only)' registry of the SDP parameters registry,
   		according to the information provided in this section.

   		This section registers a new SDP attribute, 'msrp-cema'.  The
   		required information for this registration, as specified in RFC 4566,
   		is:

   	Contact name: Christer Holmberg

   	Contact e-mail: [e-mail]

   	Attribute name: a=msrp-cema

   	Type of attribute: media level

   	Purpose: This attribute is used to indicate support of
            the MSRP Connection Establishment for Media
            Anchoring (CEMA) extension defined in
            RFC XXXX. When present in an MSRP media
            description of an SDP body, it indicates
            that the creator of the SDP supports the CEMA
            mechanism.

   	Values: The attribute does not carry a value

   	Charset dependency: none"


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

Ok.


----------------

 
> - 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 have previously been requested by IESG to include formal references only on the first occurance, so I would suggest not to change that.

But, of course, if there are first occurances, without formal references, they shall of course be fixed.


----------------


> - I believe the text should say "a Message Session ..." 
> rather than "an Message Session".
> 
> But "an MSRP message", rather than "a MSRP message"

Correct.


----------------


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

Ok.


----------------


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

Ok.


----------------


Regards,

Christer