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

From: Christer Holmberg <[email-masked]>
Date: Sun, 2 Oct 2011 22:23:16 +0200

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: [email-masked]

   	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

---

From: Eric Burger <[email-masked]>
Date: Sun, 2 Oct 2011 18:55:46 -0400

Works for me.

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Tue, 4 Oct 2011 11:22:28 +0200

Hi Christer:

I am removing these comments for which there is agreement.

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

Just bear in mind that matching URIs is not a simple task. You have to 
consider things like the presence or absence of a default port number, 
several IP addresses that resolve to the same name, and be able to answer 
questions such as if two IP addresses are different, although the same 
name resolves to those IP addresses, are the URIs equivalent?.

I think you should take a look at RFC 3986 and 3987. Both have sections 
on equivalence. But at a first glance, an IP address and a port number 
cannot be consider to a URI that contains a host name. I think you need 
to further investigate this issue and have very clear understand on what 
is required for CEMA.
>     		protection using SIP identity [RFC4916]."

I don't understand how this solves my comment. I had a comment to the 
last line of the paragraph, and it is unmodified in your proposal.

Since you are copying the text, remember that I already commented 
generally to the draft that the name of the attribute does not include 
the "a=", therefore, you should write:

      	Attribute name: msrp-cema

>     	Charset dependency: none"

BR,

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

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 4 Oct 2011 13:58:10 +0200

Hi, 

>>> 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.
> 
> Just bear in mind that matching URIs is not a simple task. 
> You have to consider things like the presence or absence of a 
> default port number, several IP addresses that resolve to the 
> same name, and be able to answer questions such as if two IP 
> addresses are different, although the same name resolves to 
> those IP addresses, are the URIs equivalent?.
> 
> I think you should take a look at RFC 3986 and 3987. Both 
> have sections on equivalence. But at a first glance, an IP 
> address and a port number cannot be consider to a URI that 
> contains a host name. I think you need to further investigate 
> this issue and have very clear understand on what is required 
> for CEMA.

I suggest the following text:

	"X. Address Information Matching

		When comparing address information in the SDP c/m-line and an MSRP URI, for address and port 
		equivalence, the address and port values are retrieved in the following ways:

		- The IP address is retrieved from the SDP c- line, and the port from the associated SDP 
		m- line for MSRP.

		- In case the authority part of the MSRP URI contains an IP address and a port, they are 
		used for the comparison.

		NOTE: According to section 6 of RFC 4975, if the authority part of the MSRP URI contains
		an IP address, it must also contain a port.

		- In case the authority part of the MSRP URI contains a Fully Qualified Domain Name (FQDN) 
		and a port, the IP address is retrived using DNS, according to the procedures in section 6.2 
		of RFC 4975. The port is retrieved from the authority part of the MSRP URI.

		- In case the authority part of the MSRP URI contains a Fully Qualified Domain Name (FQDN), 
		but does not contain a port, the IP address and port are retrived using DNS.

		NOTE: In case the DNS returns multiple records, each needs to be compared against the SDP c/m- 
		line address information.

		If the authority part of the MSRP URI contains special characters, they are handled according 
		to the procedures in RFC 4975."

MSRP does not define a default port number value - the IANA registered port value only indicates which port should be used. So, one can assume that there will always be an explicit port (that port may be received from the DNS server, though).

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

>>> 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".
>>
>>
>I don't understand how this solves my comment. I had a 
>comment to the last line of the paragraph, and it is 
>unmodified in your proposal.

Ok, now I see.

You CAN use the CEMA extension as such even when end-to-end integrity protection of SDP is used.

I could add the following note:

	"NOTE: Eventhough the CEMA extension as such works with end-to-end SDP protection, the main advantage of the extension is in networks where Middleboxes are deployed."

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

Correct.

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

In addition, based on an off-line comment you gave me, I suggest to add the following text to the Conventions section:

	"This document reuses the terms answer, answerer, offer and offerer as defined in RFC 3264 [RFC3264]."

Related to that, in the text I will replace "MSRP offerer/answerer" with "offerer/answerer".

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

Regards,

Christer

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Wed, 5 Oct 2011 10:03:02 +0200

Hi Christer,

This is looking better, but there are some missing cases. See below.

> 		- The IP address is retrieved from the SDP c- line, and the port from the associated SDP

It appears that the text is assuming an IP address in the c= line, but 
you could also have an FQDN in there.

Also, if you have an IPv6 address, you should normalize it as well.

> 		of RFC 4975. The port is retrieved from the authority part of the MSRP URI.

s/retrived/retrieved

> 		but does not contain a port, the IP address and port are retrived using DNS.

I think this case does not exist. According to RFC 4975 a port number is 
always explicitly expected in an MSRP URI. Perhaps you can modify the 
note above to say that an explicit port number is always used in MSRP URIs.

> 	"NOTE: Eventhough the CEMA extension as such works with end-to-end SDP protection, the main advantage of the extension is in networks where Middleboxes are deployed."

I am not sure if I am missing something... but isn't it so that CEMA will 
not work with middle boxes if SDP integrity protection or encryption is 
activated? So, the draft should just simply say it so. I think we don't 
have to bring SIP identity to the equation. I proposed the following 
paragraph:

"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 integrity
protection or SDP encryption."

BR,

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

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 5 Oct 2011 13:06:57 +0200

Hi, 

>> 		When comparing address information in the SDP 
>>          c/m-line and an MSRP URI, for address and port
>It appears that the text is assuming an IP address in the c= 
>line, but you could also have an FQDN in there.

Correct. So, I will add a similar bullet as for the case when an MSRP URI contains a FQDN.

		"- In case the SDP c- line contains a Fully Qualified Domain Name (FQDN), the IP address is retrieved using DNS."

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

>Also, if you have an IPv6 address, you should normalize it as well.

I suggest the following note.
 
		"NOTE: Before IPv6 addresses are compared for equality, they need to be converted into the same representation, e.g. 
		using the mechanism defined in RFC 5952 [RFC5952]."

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

>> 		- In case the authority part of the MSRP URI 
>>          contains an IP address and a port, they are
>> 		used for the comparison.
>>
>> 		NOTE: According to section 6 of RFC 4975, if 
>>          the authority part of the MSRP URI contains
>> 		- In case the authority part of the MSRP URI 
>>          contains a Fully Qualified Domain Name (FQDN)
>> 		and a port, the IP address is retrived using 
>>          DNS, according to the procedures in section 6.2

Fixed.

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

>> 		- In case the authority part of the MSRP URI 
>>          contains a Fully Qualified Domain Name (FQDN),
> I think this case does not exist. According to RFC 4975 a 
> port number is always explicitly expected in an MSRP URI.

Correct. I'll remove the bullet.

> Perhaps you can modify the note above to say that an explicit 
> port number is always used in MSRP URIs.

Yes.

	"NOTE: According to RFC 4975, the authority part of the 
	MSRP URI must always contain a port."

So, based on your comments, and with some re-structuring, the new section would look like:

"4.4.  Address Information Matching

   When comparing address information in the SDP c/m-line and an MSRP
   URI, for address and port equivalence, the address and port values
   are retrieved in the following ways:

   - SDP c/m-line address information: The IP address is retrieved from
   the SDP c- line, and the port from the associated SDP m- line for
   MSRP.

   - In case the SDP c- line contains a Fully Qualified Domain Name
   (FQDN), the IP address is retrieved using DNS.

   - MSRP URI address information: The IP address and port are retrieved
   from the authority part of the MSRP URI.

   - In case the authority part of the MSRP URI contains a Fully
   Qualified Domain Name (FQDN), the IP address is retrieved using DNS,
   according to the procedures in section 6.2 of RFC 4975.

   NOTE: According to RFC 4975, the authority part of the MSRP URI must
   always contain a port.

   NOTE: Before IPv6 addresses are compared for equivalence, they need
   to be converted into the same representation, e.g. using the
   mechanism defined in RFC 5952 [RFC5952].

   NOTE: In case the DNS returns multiple records, each needs to be
   compared against the SDP c/m- line address information.

   NOTE: If the authority part of the MSRP URI contains special
   characters, they are handled according to the procedures in section
   6.1 of RFC 4975."

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

> I am not sure if I am missing something... but isn't it so 
> that CEMA will not work with middle boxes if SDP integrity 
> protection or encryption is activated? So, the draft should 
> just simply say it so. I think we don't have to bring SIP 
> identity to the equation. I proposed the following
> paragraph:
> 
> "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 integrity protection or SDP encryption."

I am ok with that text (it basically removes the SIP identity part).

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

Regards,

Christer