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

[Eric Burger <[e-mail]>]

Works for me.

On Oct 2, 2011, at 4:23 PM, Christer Holmberg wrote:

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