Subject: [Simple] Draft new versions: ACM and sessmatch

From: Christer Holmberg <[email-masked]>
Date: Thu, 8 Apr 2010 09:54:38 +0200

Hi,

I've submitted new versions of the ACM (-07) draft and SESSMATCH (-04) drafts.

ACM: There are no changes from the previous version. I did a new version in order to make the idnit tool happy (the xml2rfc tool now also seems to get the boilerplate stuff right, so no manual fixes are needed)

SESSMATCH: I did the changes based on the outcome of Adam's WGLC comments.

Regards,

Christer

---

From: Ben Campbell <[email-masked]>
Date: Thu, 8 Apr 2010 18:01:35 -0500

(as individual)

Hi Christer,

I did a new detailed read of both drafts, and came up with a few new comments. Some of these are on old text, so I apologize for not coming up with them earlier. In my defense, I was trying to take a fresh look, and consider the sort of comments we might get in an IETF last call. They are all minor, and mostly editorial:

-----------------------------
Comments on ACM-07:

-- section 3, 

Last sentence needs some elaboration. I think the important point is that this should be supported for user agents that might be deployed behind a NAT where they cannot accept inbound TCP connections, and therefore could not accept MSRP sessions offered by a peer device outside the NAT, right?

-- Sections 4.*

We need to be a little careful about normative language of the form of "MSRP UAs MUST..."  when that language is really scoped to "MSRP UAs that support this extension MUST...".  I certainly don't expect you to say "MSRP UAs that support this extension" every single time, but I'm afraid that sections could be quoted out of context.

I see two reasonable ways to fix this. One would be to make sure each section has some text that scopes the normative language to MSRP-ACM UAs. Another, which might be less intrusive, would be to invent a new term for UAs that support ACM (maybe "MSRP-ACM UA"?), define the term early in the document (maybe in section 3), then use it consistently. Although it wouldn't be a global replace, as there are some sections (e.g. 4.4) that reasonably apply to all MSRP UAs.

-- section 4.2, last bullet point:

s/"NAT address:port"/"NAT address and port"

-- section 4.2, first paragraph after bullet list:

s/determinte/determine

spurious quote at end.

I suggest rewording the last sentence to the effect of "If SIP requests crosses a SIP proxy before crossing a NAT,…"

-- section 4.2, "note" following first paragraph after the bullet list:

Note is redundant with last sentence in previous paragraph.

-- section 4.2, 2nd paragraph:

Can you elaborate on the last sentence?

-- section 4.2, 3rd paragraph:

I'm not aware of anything in 4975 that says a UA always sends it's certificate. If not doing mutual authn, then there's no reason to expect the TLS client to send a client cert.

---------------------------------
Comments on sessmatch-04:

-- section 5, third paragraph, first 2 sentences:

I think the meaning got a little confused here with all the back-and-forth. Does the following say what you mean to say?:

"With this update, MSRP entities no longer use the MSRP URI domain part to perform session matching. But if intermediaries modify…"

On Apr 8, 2010, at 2:54 AM, Christer Holmberg wrote:

> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/simple

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 10 Apr 2010 09:27:34 +0200

Hi, 

>Last sentence needs some elaboration. I think the important point is that this should be supported for user agents that might be deployed behind a NAT where they cannot accept inbound TCP 
>connections, and therefore could not accept MSRP sessions offered by a peer device outside the NAT, right?

It does not only apply to user agents that might be deployed behind a NAT. It also applies to user agents that might not be deployed behind NATs themselves, but that communicate with other user agents that might be deployed behind NATs.

>-- Sections 4.*
>
>We need to be a little careful about normative language of the form of "MSRP UAs MUST..."  when that language is really scoped to "MSRP UAs that support this extension MUST...".  I certainly 
>don't expect you to say "MSRP UAs that support this extension" every single time, but I'm afraid that sections could be quoted out of context.
>
>I see two reasonable ways to fix this. One would be to make sure each section has some text that scopes the normative language to MSRP-ACM UAs. Another, which might be less intrusive, would be 
>to invent a new term for UAs that support ACM (maybe "MSRP-ACM UA"?), define the term early in the document (maybe in section 3), then use it consistently. Although it wouldn't be a global 
>replace, as there are some sections (e.g. 4.4) that reasonably apply to all MSRP UAs.

My understanding is that, since the draft does not update/obsolete RFC 4975, the procedures only apply to user agents that implement the draft.

I think it would be very messy if we, everytime we say something normative, explicitly need to clarify that it only applies to MSRP-ACM UAs...

Section 3 says that the support of the specification is optional. Isn't that enough?

If needed, I could modify the text in section 4.1 to:

"This section defines how an MSRP UA that supports this specification uses the COMEDIA SDP attributes defined in [RFC4145]."

>s/"NAT address:port"/"NAT address and port"

Ok.

>-- section 4.2, first paragraph after bullet list:

Ok.

>I suggest rewording the last sentence to the effect of "If SIP requests crosses a SIP proxy before crossing a NAT,…"

Ok.

>Note is redundant with last sentence in previous paragraph.

Ok.

>Can you elaborate on the last sentence?

It means that an entity that knows that it is not located behind a NAT can unsure that the remote UA establishes the connection, in case it would be located behind a NAT.

If you think the text is unclear, would the following be better?

"The a=setup attribute is particularly useful when one MSRP UA (e.g. a network media server) knows that it is not located behind a NAT. The a=setup attribute allows that MSRP UA to ensure that the remote MSRP UA creates the MSRP tranport connection, in case the remote MSRP UA remote is located behind a NAT."

And, going back to your comment on section 3, this is why the extension is also applicable to entities that are not located behind NATs themselves :)

>I'm not aware of anything in 4975 that says a UA always sends it's certificate. If not doing mutual authn, then there's no reason to expect the TLS client to send a client cert.

I assume you refer to the 3rd paragraph of section 4.3?

After a re-look at RFC 4975, and when it comes to the TLS client it seems you are right. So, I guess we could simply remove the following statement:

"In accordance with [RFC4975], if an MSRP UA has a TLS certificate, it always sends the certificate to the other endpoint during the TLS establishment."

=================================

The text was provided by Adam. But, I have no problem with your suggestion, so if Adam is ok with it I can do that change.

So, the section text would be:

"With this update, MSRP entities no longer use the MSRP URI domain part to perform session matching. But if intermediaries modify the "a=path" attribute in the SDP, but do not modify the corresponding information in the associated MSRP messages, then the endpoints can determine that such modifications have been performed by comparing the domain information in the SDP with the domain information in the MSRP messages."

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 12 Apr 2010 11:41:38 +0200

Hi, 

>>I suggest rewording the last sentence to the effect of "If SIP requests crosses a SIP proxy before crossing a NAT,..."
> 
>Ok.

I took a second look at this.

I don't think it matters whether there is a proxy between the UA and the NAT - the Via check will still work.

Regards,

Christer

---

From: Ben Campbell <[email-masked]>
Date: Tue, 13 Apr 2010 20:08:22 -0500

> It does not only apply to user agents that might be deployed behind a NAT. It also applies to user agents that might not be deployed behind NATs themselves, but that communicate with other user age…

Okay, I buy that. But I have trouble getting the essence of that from  "User Agents that are likely to be deployed in networks where User Agents need to establish the TCP connections in order to traverse NATs..." is clear. By user agents that "need to _establish_ the TCP connection" , are you talking about those that must be the active party? Or is the important point that the TCP connections are peer to peer (i.e. no relay)?

> Section 3 says that the support of the specification is optional. Isn't that enough?

I agree that it's ugly to restate the scope every time. I'm trying to think about how people (sometimes willfully) misread drafts. My concern is that text is often taken out of context. I think it helps to have the occasional reminder, instead of assuming everyone will infer the meaning from the scope of the draft. 

> "This section defines how an MSRP UA that supports this specification uses the COMEDIA SDP attributes defined in [RFC4145]."

I think that helps. It might be better to move that text to be under the Section 4 heading instead of a 4.1, and say "This section and its subsections..."  since those willful misreaders could otherwise argue that the "this section" refers to 4.1.

[ ... ]

> And, going back to your comment on section 3, this is why the extension is also applicable to entities that are not located behind NATs themselves :)

Oops, that sections fine. I meant section 4.3. (And I would not have figured out what I was originally commenting on had you not so graciously pointed out my 4.2 vs 4.3 confusion in the next comment ;-)  )
> I assume you refer to the 3rd paragraph of section 4.3?

Yes, sorry.

> "In accordance with [RFC4975], if an MSRP UA has a TLS certificate, it always sends the certificate to the other endpoint during the TLS establishment."

I think that's the best solution.

> "With this update, MSRP entities no longer use the MSRP URI domain part to perform session matching. But if intermediaries modify the "a=path" attribute in the SDP, but do not modify the correspond…

Works for me.

Thanks!

Ben.

---

From: Ben Campbell <[email-masked]>
Date: Tue, 13 Apr 2010 21:13:11 -0500

> I don't think it matters whether there is a proxy between the UA and the NAT - the Via check will still work.

How? I assume you are talking about inspecting the "received" parameter in the Via, right? But by the time a response gets back to the UAC, only the initial Via will be left.  The UAC cannot infer anything from downstream Via headers, since they won't be in the response. Am I missing something?

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 14 Apr 2010 07:59:11 +0200

Hi,

>>>Last sentence needs some elaboration. I think the 
>>>important point is that this should be supported for user agents that might 
>>>be deployed behind a NAT where they cannot accept inbound TCP 
>>>connections, and therefore could not accept MSRP sessions 
>>>offered by a peer device outside the NAT, right?
>> 
>>It does not only apply to user agents that might be 
>>deployed behind a NAT. It also applies to user agents that 
>>might not be deployed behind NATs themselves, but that 
>>communicate with other user agents that might be deployed behind NATs.
> 
>Okay, I buy that. But I have trouble getting the essence of 
>that from  "User Agents that are likely to be deployed in 
>networks where User Agents need to establish the TCP 
>connections in order to traverse NATs..." is clear. By user 
>agents that "need to _establish_ the TCP connection" , are 
>you talking about those that must be the active party? Or is 
>the important point that the TCP connections are peer to peer 
>(i.e. no relay)?

I am talking about cases where the SDP answerer is behind the NAT, and needs to become active. In RFC 4975 the answerer is always passive.

I don't think it apply to terminals behind relays, because they will anyway always establish a connection with the relay - no matter if they are active or passive.

So, would the following be more clear:

"Support of this specification is optional for MSRP user agents in general.
User agents that are located behind NATs, do not use MSRP relays for 
NAT traversal, and need to establish the TCP connections in order to traverse NATs, 
and other user agents communicating with those user agents, SHOULD support 
this specification in order to improve the odds of being able to communicate acress NATs."

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

>>>-- Sections 4.*
>>> 
>>>We need to be a little careful about normative language of 
>>>the form  of "MSRP UAs MUST..."  when that language is really scoped 
>>>to "MSRP UAs that support this extension MUST...".  I 
>>>certainly don't expect you to say "MSRP UAs that support this 
>>>extension" every single time, but I'm afraid that sections 
>>>could be quoted out of context.
>>> 
>>>I see two reasonable ways to fix this. One would be to 
>>>make sure each section has some text that scopes the normative language 
>>>to MSRP-ACM UAs. Another, which might be less intrusive, would be to 
>>>invent a new term for UAs that support ACM (maybe "MSRP-ACM 
>>>UA"?), define the term early in the document (maybe in 
>>>section 3), then use it consistently. Although it wouldn't be 
>>>a global replace, as there are some sections (e.g. 4.4) that 
>>>reasonably apply to all MSRP UAs.
>> 
>>My understanding is that, since the draft does not 
>>update/obsolete RFC 4975, the procedures only apply to user 
>>agents that implement the draft.
>> 
>>I think it would be very messy if we, everytime we say 
>>something normative, explicitly need to clarify that it only 
>>applies to MSRP-ACM UAs...
>> 
>>Section 3 says that the support of the specification is 
>>Optional. Isn't that enough?
> 
>I agree that it's ugly to restate the scope every time. I'm 
>trying to think about how people (sometimes willfully) 
>misread drafts. My concern is that text is often taken out of 
>context. I think it helps to have the occasional reminder, 
>instead of assuming everyone will infer the meaning from the 
>scope of the draft. 
> 
>> 
>>"This section defines how an MSRP UA that supports this 
>>specification uses the COMEDIA SDP attributes defined in [RFC4145]."
> 
>I think that helps. It might be better to move that text to 
>be under the Section 4 heading instead of a 4.1, and say 
>"This section and its subsections..."  since those willful 
>misreaders could otherwise argue that the "this section" 
>refers to 4.1.

Keith has spent a number of years teachin me that you can't do it that way (it's called hanging paragraph, or something), 
and that the correct way is to have a "General" subsection where you describe things which 
apply to all subsections :)

That is also how we've done in many other specifications.

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

>>It means that an entity that knows that it is not located 
>>behind a NAT can unsure that the remote UA establishes the 
>>connection, in case it would be located behind a NAT.
>> 
>>"The a=setup attribute is particularly useful when one MSRP 
>>UA (e.g. a network media server) knows that it is not located 
>>behind a NAT. The a=setup attribute allows that MSRP UA to 
>>ensure that the remote MSRP UA creates the MSRP tranport 
>>connection, in case the remote MSRP UA remote is located 
>>behind a NAT."
>> 
>>And, going back to your comment on section 3, this is why the 
>>extension is also applicable to entities that are not 
>>located behind NATs themselves :)
> 
>Oops, that sections fine. I meant section 4.3. (And I would 
>not have figured out what I was originally commenting on had 
>you not so graciously pointed out my 4.2 vs 4.3 confusion in 
>the next comment ;-)  )

So, your issue is related to section 4.3, 2nd paragraph?

The sentence says:

"From TLS authentication point of view it is thus irrelevant whether an
endpoint takes the active or passive role."

The text simply intends to show that the TLS authentication is not affected by the active/passive role.

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

>>>I'm not aware of anything in 4975 that says a UA always 
>>>sends it's certificate. If not doing mutual authn, then 
>>>there's no reason to expect the TLS client to send a client cert.
>> 
>>After a re-look at RFC 4975, and when it comes to the TLS 
>>client it seems you are right. So, I guess we could simply 
>>remove the following statement:
>> 
>>"In accordance with [RFC4975], if an MSRP UA has a TLS 
>>certificate, it always sends the certificate to the other 
>>endpoint during the TLS establishment."
> 

Gone it is :)

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

>How? I assume you are talking about inspecting the "received" parameter in the Via, right? 
>But by the time a response gets back to the UAC, only the initial Via will be left.  
>The UAC cannot infer anything from downstream Via headers, since they won't be in the response. 
>Am I missing something?

No, you are correct. I was thinking about how an edge proxy could determine whether it's a NAT between itself and the UA.

So, the text could be:

"If SIP requests crosses a SIP proxy before crossing a NAT, the UA will not be able to detect the
NAT by comparing the IP addresses."

>>>I think the meaning got a little confused here with all 
>>>the back-and-forth. Does the following say what you mean to say?:
>>> 
>>>"With this update, MSRP entities no longer use the MSRP 
>>>URI domain part to perform session matching. But if 
>>>intermediaries modify..."
>> 
>>The text was provided by Adam. But, I have no problem with 
>>your suggestion, so if Adam is ok with it I can do that change.
>> 
>> "With this update, MSRP entities no longer use the MSRP URI 
>domain part to perform session matching. But if 
>intermediaries modify the "a=path" attribute in the SDP, but 
>do not modify the corresponding information in the associated 
>MSRP messages, then the endpoints can determine that such 
>modifications have been performed by comparing the domain 
>information in the SDP with the domain information in the 
>MSRP messages."
>> 
> 
>Works for me.

Changed it is.

Regards,

Christer