Subject: [Simple] AD Review: draft-ietf-simple-msrp-acm-08.txt

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 11 May 2010 17:43:12 +0300

Hi,

I have received a publication request for the following draft:

https://datatracker.ietf.org/doc/draft-ietf-simple-msrp-acm/

I have a few comments on the draft. The draft states that the main
motivation for using COMEDIA is NAT traversal. The draft needs to
explain why things like ICE TCP are not applicable or are inferior to
the mechanism described in the draft. Section 5 touches upon this.

Also, since the draft claims that this is an improvement over the
standard way of establishing MSRP connections, the draft should briefly
describe how it is superior. Is it only that one can specify which
endpoint will start the TCP connection or are there other advantages of
using COMEDIA?

I found this sentence somewhat confusing:

"User Agents that are likely to be deployed in networks
   where User Agents need to establish the TCP connections in order to
   traverse NATs SHOULD support this specification in order to improve
   the odds of being able to communicate across NATs."

Does this simply mean that this mechanism is applicable in scenarios
with NATs because it improves the odds of successfully establishing
connections in such an environment?

The following normative statement seems redundant since support for
COMEDIA has already been mandated:

  "An MSRP UA MUST support the a=setup "active", "actpass" and "passive"
   attribute values."

If this sentence is meant as a clarification, it should not use RFC2119
language.

The same with this sentence:

  "In accordance with [RFC4145], if the a=setup attribute value is
   "active", the port number value SHOULD be 9."

The idea is not to informatively specify things that are already
specified in COMEDIA.

Th authors may want to consider splitting Section 4.2 into several
sections. One with general guidelines on how to use COMEDIA in this
environment, another on which values on the COMEDIA parameters need to
be used for backwards compatibility reasons (i.e., to interact with
regular MRSP endpoints). The other would describe the policy to be used
when setting those values to maximize the chances to traverse NATs. I
would keep this last section at a SHOULD or RECOMMENDED level (at
maximum) because endpoints in some environments might want to do things
differently.

Thanks,

Gonzalo

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 20 May 2010 19:14:37 +0200

Hi,
 
>the mechanism described in the draft. Section 5 touches upon this.
 
 Assuming you have sessmatch, I guess one could use ICE TCP.
 
(If you do NOT have sessmatch, and use ICE, the a=path address will point to the STUN/TURN server, and you will end up with the uri address comparision mismatch issue that sessmatch addresses.)
 
Using comedia is much more "light weight" than using ICE, so I guess that is the main motivation for using comedia.
 
Regarding ICE TCP, there has been some issues (mostly related to dual synch, afaik), but I don't know what the current status of those are. And, the latest version of the ICE TCP draft expired on april 16th.
 
------------------
 
>endpoint will start the TCP connection or are there other advantages of
 
 For MSRP, that is the main advantage, yes.
 
One could also say that an advantage is that the TCP connection establishement mechanism is consistant to the ones used for other types TCP transported media, but the main advantage is still NAT traversal.
 
 (COMEDIA also defines the connection attribute, but MSRP does not use it.)
 
 ------------------
 
>connections in such an environment?
 
Yes.
 
 But, the main point of the sentence is to make clear that it is not only useful for the entities behind the NATs to support the mechanism, but also for other entities in networks where NATs are deployed - even if those entities are not behind NATs.
 
 This paragraph has been modified a number of times, but maybe the following text would be more clear:
 
 "User Agents that are likely to be deployed in networks with NATs SHOULD support this specification. It will improve 
 the odds of being able to make TCP connections successfully traverse NATs, since User Agents behind NATs can be 
 requested to initiate the establishment of the TCP connections."

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

>If this sentence is meant as a clarification, it should not use RFC2119 language.
> 
The MSRP UA does not need to support all attribute values, so it needs to be clear which it needs to support.
 
 But, I guess "MUST" could be changed to "must".
 
 At one point we made a WG decission to not talk about the "holdconn" attribute value, but if it makes the text more clear I could add something like:
 
 "MSRP UAs compliant to this specification MUST NOT send the "holdconn" attribute, and MUST ignore it if received."

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

>The idea is not to informatively specify things that are already specified in COMEDIA.
 
 Ok. I can change "SHOULD" to "should".

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

>The authors may want to consider splitting Section 4.2 into several
 
I guess we could remove the second paragraph ("The a=setup attribute is particurlarly..."), because the introduction of the draft already says the same for comedia in general.
 
So, the remaining section could e.g. be divided into two sub sections, as below:
 
"4.2.  a=setup
 
  4.2.1 General
 
  An MSRP UA uses the SDP a=setup attribute [RFC4145], in order
  to negotiate which endpoint will create the MSRP transport connection
  towards the other UA.
  
  An MSRP UA MUST always include an explicit a=setup attribute in its
  SDP offers and answers, since it might be useful for the other
  endpoint, or for entities in the network, to know whether the UA
  supports COMEDIA or not.

  An MSRP UA must support the a=setup "active", "actpass" and "passive"
  attribute values.
 
  4.2.2 Attribute usage
 
  When the a=setup attribute value is "actpass" or "passive", the IP
  address and port values in the MSRP URI of the SDP a=path attribute
  MUST contain the actual address and port values on which the UA can
  receive a TCP Open request for the MSRP transport connection.
 
  In accordance with [RFC4145], if the a=setup attribute value is
  "active", the port number value should be 9.
 
  If an MSRP UA can provide a global IP address that the other endpoint
  can use as destination for a TCP Open request, the UA MUST use the
  a=setup "actpass" attribute value in SDP offers.  This is in order to
  allow the remote UA to send an SDP answer with an a=setup "active"
  attribute value if the UA is located behind NAT, and in order to be
  compatible with UAs that do not support COMEDIA and thus always
  will act as passive endpoints.  If an MSRP UA cannot provide the
  actual transport address, the UA MUST use the a=setup "active"
  attribute value.
 
  The MSRP UA MUST NOT use the a=setup "passive" attribute value in an SDP
  offer.
 
  The MSRP UA can determine that it provides a global IP address in the
  following scenarios:
 
  - the UA can determine that it is not located behind a NAT;
 
  - the UA relays its MSRP transport connections via a relay (e.g.
    MSRP relay or TURN server); or
 
  - the UA has used Session Traversal Utilities for NAT (STUN)
    [RFC5389] signaling to retrieve NAT address and port through the
    local port to be used for the eventual transport connection, while
    also having determined that the NAT is not address restricted.
 
 Some UAs can determine whether the SIP [RFC3261] signaling has
traversed a NAT by inspecting the SIP Via header field in the 200
(OK) response to the initial SIP REGISTER request, and comparing the
IP addresses in the Via sent-by and the received header field
parameters.  If the IP addresses are not the same then the UA can
determine that there is a NAT in the path.  Even though the media
transport might not traverse the NAT, it is safe to assume that it
will, and set the a=setup attribute accordingly.  This comparing
mechanism does not work in all scenarios, though.  For example, if
SIP a requests crosses a SIP proxy before crossing a NAT, the UA will
not be able to detect the NAT by comparing the IP addresses.
 
If an SDP offer includes an a=setup "actpass" attribute value, the
SDP answer MAY include an a=setup "active" attribute value, but
SHOULD include a=setup "passive" attribute value if the SDP answerer
knows that it is not located behind a NAT.
 
Once the active UA has established the MSRP transport connection, the
UA must immediately send an MSRP SEND request, as defined in
[RFC4975].
 
NOTE: According to [RFC4975] the initiating UA is always active, but
when COMEDIA is used the a=setup attribute is used to negotiate which
UA becomes active."

Regards,

Christer

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 31 May 2010 19:36:12 +0300

Hi Christer,

thanks for your answers. Please, revise the draft along the lines of
your answers below so that I can start its IETF LC.

Thanks,

Gonzalo