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

From: Christer Holmberg <[email-masked]>
Date: Tue, 1 Jun 2010 13:54:28 +0200

Hi,

I have now submitted a new version (-09) of the ACM draft.

Regards,

Christer 

> -----Original Message-----
> From: Gonzalo Camarillo 
> Sent: 31. toukokuuta 2010 19:36
> To: Christer Holmberg
> Cc: [email-masked]
> Subject: Re: [Simple] AD Review: draft-ietf-simple-msrp-acm-08.txt
> 
> 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
> 
> On 20/05/2010 8:14 PM, Christer Holmberg wrote:
> > 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.
> >  
> >  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.
> >  
> > ------------------
> >  
> >> 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?
> >  
> >  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.)
> >  
> >  ------------------
> >  
> >> 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?
> >  
> > 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."
> > 
> >  
> >  ------------------
> >  
> >  
> >> 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 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 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.
> >  
> >  Ok. I can change "SHOULD" to "should".
> >  
> >  
> >  ------------------
> >  
> >  
> >> The 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.
> >  
> > 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, 07 Jun 2010 12:50:23 +0300

Hi,

I have just requested an IETF LC on this document. It will start shortly.

Cheers,

Gonzalo