Subject: [Simple] WGLC of msrp-acm and msrp-sessionmatch

From: Ben Campbell <[email-masked]>
Date: Wed, 9 Dec 2009 13:25:30 -0600

This is a Working Group Last Call on the msrp-acm and msrp-sessionmatch drafts. We are last-calling them as a unit:

http://tools.ietf.org/html/draft-ietf-simple-msrp-acm-02
http://tools.ietf.org/html/draft-ietf-simple-msrp-sessmatch-00t

The WGLC will conclude on 23 December 2009. Please send your comments, including NITS and "this is ready to go" type comments, to the authors and the working group.

Thanks!

Ben.

---

From: Salvatore Loreto <[email-masked]>
Date: Mon, 14 Dec 2009 13:21:04 +0200

Hi there,

In my opinion those documents are ready to progress.
I have reviewed the both the drafts and I have a few minor 
comments/typos below that should be considered by the authors,
but should not be considered blocking.

draft: "An Alternative Connection Model for the Message Session Relay 
Protocol  (MSRP)"
         http://tools.ietf.org/html/draft-ietf-simple-msrp-acm-02

1.  Introduction

   [RFC4975] defines that the MSRP UA which sends the SDP offer is
   "active", and is this responsible to create the MSRP transport
   connection towards the remote UA.

it should be

   .., and it is responsible to create the MSRP transport
   connection towards the remote UA.

moreover consider to add before the comma   

   ", if a new connection is required."

3.  Applicability statement

   An MSRP UA SHOULD use the alternative connection model, defined in
   this document, when the UA does not use an MSRP relay in order to
   proxy its MSRP media.

the statement is not clear about the fact if the alternative connection 
model is optional or compulsory.
To me it looks like it is compulsory, in either cases it would be good 
make it more clear.

4.2.  a=setup

   ...

 An MSRP UA can determine a valid WAN transport address:port if the UA
   can determine that it is not located behind a NAT, or if the UA
   relays its MSRP transport connections via a TURN server, or if the UA
   through STUN signalling from the local port to be used for the 
   eventual transport connection has used STUN to retrieve NAT address:
   port while also having determined that the NAT is not address
   restricted.

it would be better make it more clear (below a suggestion)

   An MSRP UA can determine a valid WAN transport address:port 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 TURN server;
   - the UA has used STUN signalling to retrieve NAT address:port 
     through the local port to be used for the the eventual transport connection,
     while also having determined that the NAT is not address restricted.

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

draft: "Session Matching Update for the Message Session Relay Protocol 
(MSRP)"
http://tools.ietf.org/id/draft-ietf-simple-msrp-sessmatch-00.txt

1.  Introduction

   ...

   In order to use general NAT traversal methods, an ALGs, 

should be

   In order to use general NAT traversal methods and ALGs, 

4.2.  RFC4975: 7.3 Receiving Requests

   The receiving endpoint MUST first check the URI in the To-Path to
   make sure the request belongs to an existing session.  When the
   request is received, the To-Path will have exactly one URI, of which
   the session-id component MUST map to an existing session that is
   associated with the connection on which the request arrived.

I guess that the idea is that "The session-id part is compared as case 
sensitive." as specified in Section 6.1
point 4 of RFC 4975. If so it would be better say it explicitly.

cheers
/Sal

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

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 15 Dec 2009 08:08:06 +0100

Hi Sal, 

>   connection towards the remote UA.

I'll fix that.

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

>    ", if a new connection is required."

I can do that also.

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

>the statement is not clear about the fact if the alternative 
>connection model is optional or compulsory.
>To me it looks like it is compulsory, in either cases it 
>would be good make it more clear.

In fact, I think the first paragraph of the applicability statement can be removed.

The current version of the draft only defines the usage of comedia, and there is no reason why a MSRP UA behind a relay couldn't use it.

------------
 
>      while also having determined that the NAT is not address 

I can change that.

------------
 
>    In order to use general NAT traversal methods and ALGs, 

I'll fix that.

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

> point 4 of RFC 4975. If so it would be better say it explicitly.

I'll fix that.

Thank you very much for your comments!

Regards,

Christer

---

From: Shida Schubert <[email-masked]>
Date: Tue, 15 Dec 2009 23:36:29 +0900

I reviewed the two drafts and believe that both drafts 
are in good shape and ready to progress after some of the 
comments below are addressed. 

## Clarification Required###

msrp-acm ================================

  - Introduction
     1. A lot of acronym is used and they should be expanded when 
         used for the first time. e.g. IM (Instant Messenger), OMA (Open Mobile Alliance) etc. 

     2. " and all IM MSRP clients support COMEDIA" 
        >> I think you mean all OMA IM MSRP clients ? Or was COMEDIA a normative 
             MUST implement for MSRP clients?? 

     3. "The document also defines how an MSRP UA can
         establish an MSRP transport connection with a remote UA that does not
         support COMEDIA."
        >> Can't you already establish an MSRP transport connection without COMEDIA? 
              I think you need to elaborate a little more here. 

  - Applicability Statement
    1. I think the statement is about interop with [RFC4975] only conformant MSRP and 
        that should be clear. 

  - 4.2
    1. Use of term WAN transport address >> Do we have a common term that we use 
       for this in IETF? If so I think you should what's used elsewhere.. 

    2. What do you mean by "If an MSRP UA cannot provide
     the actual transport address, the UA MUST use the a=setup "active"
     attribute value."

    Do you mean if MSRP UA cannot provide its WAN transport address? If so this should be clarified.

## Nits ######

msrp-acm ================================
  
  - Abstract
    "The model allows MSRP UAs which are located behind NATs to indicate
   that they want to initiate the establishment of the TCP connection
   towards the remote MSRP UA, "

    May be replace it with

     "The model allows MSRP UAs behind NATs to negotiate which UA
    will initiate the establishment of the TCP connection"

  - Introduction 
    "[RFC4975] also allows, but does
   not define, MSRP UAs to use other mechanisms in order to create the
   MSRP transport connection."
 
    May be replace it with

    "[RFC4975] allows other mechanisms to be used to create 
     MSRP transport connection, but does not define any other mechanisms."

   ****

    "[RFC4145] defines a mechanism, COMEDIA, which endpoints can use to
   negotiate which endpoint will create the media transport connection."

    May be replace it with 

    "[RFC4145] defines a mechanism, COMEDIA, which endpoints can use to
   negotiate the endpoint which initiates the creation of media transport connection."

  ****

  " media server, and which is always" >> and is unnecessary.

 ****
  
 - Applicability statement >> should be Applicability Statement 
  ".. and does  not proxy its MSRP communication via an MSRP-Relay node" 
    
   shouldn't it be something like 

  ".. and does not proxy its MSRP messages via an MSRP-Relay"

 - Section 4.2

 "The media server can ensure that the user MSRP
   UAs will create the MSRP transport connections towards the server, so
   that possible NATs at user premises will not interfere with the
   connection creation."

  Should be replaced with 

 "a=setup attributes allows the media server to ensure that the user's MSRP
   UAs initiates the MSRP transport connections towards the server, so
   that NATs at user's premises will not interfere with the
   connection creation."

 "If an MSRP UA can determine a valid WAN transport endpoint address:
   port" 
 
 Should be replaced with 

 "If an MSRP UA can determine its WAN transport endpoint address:
   port"

 ****

 "COMEDIA and thus always
   will always act as passive endpoints" 
  >> too many always.

 - 4.3 
 "the client and server TLS roles MUST" 

 Should be 

 "the role of TLS client and TLS server MUST"

msrp-sessionmatch ================================

 - Section 1: 3rd paragraph : 1st sentence.
   "consistence" should be "consistency" 
 
 Do you mean Intermediates or Intermediaries?

 Regards
  Shida

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 15 Dec 2009 21:32:52 +0100

Hi Shida, 

Thanks for reviewing the documents! Comments inline.

I'll fix that.

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

>             MUST implement for MSRP clients?? 

I mean OMA clients. I'll add "OMA" to make it clear.

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

>              I think you need to elaborate a little more here. 

I guess the text should say something like "The document also defines how an MSRP UA which uses COMEDIA can establish..."

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

>    1. I think the statement is about interop with [RFC4975] only conformant MSRP and 

Based on Sal's comments, I plan to remove the first paragraph of the applicability statement, because it is not true anymore.

I think the rest of the text is clear on what kind of UAs are referred to, or do you think something needs to be clarified?

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

>    Do you mean if MSRP UA cannot provide its WAN transport address? If so this should be clarified.

Yes. These comments are related, so I'll try to make it more clear.

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

>    will initiate the establishment of the TCP connection"

Looks ok.

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

>     MSRP transport connection, but does not define any other mechanisms."

Looks ok.

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

>   negotiate the endpoint which initiates the creation of media transport connection."

Looks ok.

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

>  " media server, and which is always" >> and is unnecessary.

I'll remove it.

---------------
  
>  ".. and does not proxy its MSRP messages via an MSRP-Relay"

As said earlier, I plan to remove the whole paragraph.

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

>   that NATs at user's premises will not interfere with the

Looks ok.

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

>"If an MSRP UA can determine its WAN transport endpoint address:

I'll fix that as part of the clairification mentioned earlier.

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

I'll fix that.

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

I'll fix that.
 
>   "consistence" should be "consistency" 

Yes.

>Do you mean Intermediates or Intermediaries?

Intermediaries :)

Thanks!

Christer

---

From: Ben Campbell <[email-masked]>
Date: Fri, 18 Dec 2009 16:50:34 -0600

Oops, please forgive the typo on the sessmatch URI below. There should be no "t" on the end.

---

From: Ben Campbell <[email-masked]>
Date: Fri, 18 Dec 2009 17:13:11 -0600

(Since Christer submitted updates to both drafts, I have reviewed msrp-acm-03 and sessmatch-01)

Both of these drafts are nearly ready to progress, but I think there are a few open issues that are minor, but still substantive.

-------------------- WGLC review of draft-ietf-simple-msrp-acm-03:

** Substantive:

-- Section 3:

I'd like to see something to the effect of "Support of this specification is optional for MSRP user agents in general. User Agents that are likely to be deployed without MSRP Relays SHOULD support this specification in order to improve the odds of being able to communicate across NATs."

-- Section 4.2, 4th paragraph from end:

I'm not entirely sure it's safe to assume that the presence or absence of a NAT on the signaling path always indicates the same for the media path. For example, there could be a SIP proxy _inside_ the NAT.

-- Section 4.3:

 Did we ever close on the COMEDIA-TLS fingerprint requirement, and how that could be a problem in the presence of relays?

-- Section 4.4, third paragraph (NOTE about ICE)

Is the note really needed? This draft is not about using ICE per se.

-- Section 5:

Does it make sense to use STUN for this in a TCP stream?

Do we need some statement about not sending a keepalive mid-chunk? (I'm not sure why one would need to, but doing so is likely to corrupt a message.) Also, does the default Tr value in ICE apply to TCP?

-- Section 6:

Have we thought through whether changing the active party has any impact on TLS security? Does this interact with key fingerprints in the signaling channel? (I'm not saying that I know it does--I just want to make sure we've thought about it.)

** Editorial and Nits:

-- General:

Please expand non-common-knowledge acronyms on first mention. 

-- section 1, first two paragraphs:

These would be easier to read if the references were structured as truly parenthetical rather than as bona-fide parts of the sentence. For example, "The Message Session Relay Protocol (MSRP) [ref] defines that…" rather than "[ref] defines that…"

-- section 1, paragraph 2:

ben: s/"responsible to create"/"responsible for creating"

-- section 1, paragraph 4 (OMA example)

By "located in the network", do you mean carrier network? Publicly accessible network?

-- section 1, last paragraph:

Am I correct in assuming this would not be limited to TCP? For example, if we define an SCTP binding in the future, COMEDIA could still apply? If so, perhaps it would be better to consistently refer to transport connections rather than TCP connections.

-- section 3, paragraph 1:

s/interop/interoperate (or interwork). 

Also, I tend to think of UAs conforming to this spec as (mostly) also conforming to RFC4975. So I'm not sure "[RFC 4975] conformant" is the best way to refer to UAs that do not implement COMEDIA. Perhaps something along the lines of "… from a UA that follows the RFC 4975 connection model…"

-- section 4.2, paragraph 1:

We still need to make it more clear that the normative language in this spec is scoped to UAs supporting COMEDIA, i.e. this MUST is not universal. That might be doable by being a little more precise in the applicability statement (see my comment on section 3). Otherwise, we need some concise term that means "MSRP UAs implementing COMEDIA"

-- section 4.2, paragraph 2:

ben:s/"which is not…"/"that is not..."

-- section 4.2, fifth paragraph from end (starting with - the UA has used STUN)
s/signalling/signaling
Can we have an informational reference for STUN?

-- idnits returns some warnings that should be fixed prior to pubreq.

-------------------- WGLC review of draft-ietf-simple-msrp-sessionmatch-01:

*** Substantive:

-- Section 5:

I think we need another paragraph along the lines of:

"An MSRP UA treats its session URI as a shared secret to determine that an incoming transport connection is indeed from the signaled peer device. An MSRP session URI therefore needs to be hard to guess. However, RFC 4975 already requires the session-id part of the URI to be sufficiently hard to guess. Furthermore, the addressing information in the domain part of the URI is relatively easy to guess. This makes the difficulty in guessing the session-id roughly equivalent to the difficulty of guessing the entire URI."

-- Section 5, last paragraph:

Do we need to talk about the security issues created by the intermediaries themselves? We don't otherwise specify how intermediaries work in this draft.

** Editorial and Nits:

-- General:

Please expand acronyms on first mention.

-- Section 1, paragraph 3:

I'm not sure I follow the "- NAPT - " part of the last sentence.

-- Section 4.1 and 4.2

Either need to state that 4.2 replaces the first paragraph in section 7.3, or state that it replaces the entire section and include the (one sentence) second paragraph from that section.

-- Section 8.1:

I'm not sure the references are right here. 

-- Section 8.2

Can we have an nformative reference to TS23.228?

-- idnits returns some warnings--please check them before pubreq.

---

From: Ben Campbell <[email-masked]>
Date: Fri, 18 Dec 2009 17:15:05 -0600

(And of course, that entire review was as an individual contributor.)

---

From: Adam Roach <[email-masked]>
Date: Mon, 21 Dec 2009 17:23:56 -0600

> This is a Working Group Last Call on the msrp-acm and msrp-sessionmatch drafts. We are last-calling them as a unit:

Just for clarification: the fact that we're last calling these at the 
same time doesn't mean that we intend them to progress as a cluster 
(http://www.rfc-editor.org/cluster_def.html), does it? There is no 
normative dependency between them, and I'd hate to see them both be 
delayed due to issues related to only one of them (e.g., in IETF last 
call, or IESG review).

==========
draft-ietf-simple-msrp-acm

   1. NIT: The abstract contains several acronyms that need to be
      expanded (MSRP, UA, COMEDIA) -- see section 3.6 of
      http://www.rfc-editor.org/rfc-style-guide/rfc-style

   2. NIT: In the introduction, the sentence "[RFC4975] also allows, but
      does not define, MSRP UAs to use other mechanisms in order to
      create the MSRP transport connection" lacks parallelism. Try
      "[RFC4975] also allows, but does not define, alternate mechanisms
      for MSRP UAs to create MSRP transport connections."

   3. NIT: Also in the introduction: "[RFC4145] defines a mechanism,
      COMEDIA, which endpoints can use..." should read "[RFC4145]
      defines a mechanism, COMEDIA, that endpoints can use..." (the
      phrase at the end of the sentence isn't incidental to its meaning
      -- it is the purpose of the sentence).

   4. SUBSTANTIVE: I agree with earlier comments that the first
      paragraph of section 3 is a bit confusing, as it appears to impose
      a normative requirement on all MSRP UAs. Removal seems a bit of
      overkill, though, as it leaves implementors no information about
      when ACM should be employed.

      The second paragraph of section 3 talks about NAT traversal
      failures under certain circumstances, but provides implementors no
      guidance about how to avoid these failures. I think you need to
      add text that basically recommends that UA implementations that
      can be configured to use ACM as their NAT traversal strategy also
      MUST have the ability to use MSRP relays. (In other words:
      mandatory to implement, optional to use). Otherwise, you're
      encouraging deployment of clients that can perform NAT traversal,
      but only under fairly limited network circumstances.

   5. NIT: in section 4.2, "holdcon" should be spelled "holdconn" (two
      'n's).

   6. SUBSTANTIVE: In section 4.2, I think we need an explanation in the
      document regarding why "holdconn" is normatively prohibited. It's
      not immediately clear to me why we prevent this, and I can't find
      any discussion on the SIMPLE mailing list on the topic.

   7. SUBSTANTIVE: A natural consequence of the rules in section 4.2 is
      that an _offer_ for an MSRP session must never be "passive." To
      avoid misinterpretation, this should be stated as a normative
      requirement.

   8. SUBSTANTIVE: Unlike SIP, I don't think MSRP has rules that require
      recipients to ignore CRLF sequences in a TCP connection. I'm
      pretty sure that the CRLF mechanism described in section 5 for
      pinhole preservation is NOT backwards compatible. However, RFC
      4975 does talk about NAT binding keepalives in RFC 4975, section
      7.1: "Bodiless requests may also be used in certain applications
      to keep Network Address Translation (NAT) bindings alive, etc."

   9. SUBSTANTIVE: Also related to section 5: I'm certain that nothing
      in draft-ietf-mmusic-ice provides guidance here: that document
      deals with UDP, while MSRP is exclusively a TCP protocol. Perhaps
      you intended to cite draft-ietf-mmusic-ice-tcp?

==========
draft-ietf-simple-msrp-sessmatch

   1. NIT: The abstract contains several acronyms that need to be
      expanded (MSRP, UA, ALG) -- see section 3.6 of
      http://www.rfc-editor.org/rfc-style-guide/rfc-style

   2. NIT: The unexpanded acronym issue continues through the
      introduction: SLA, B2BUA, NAPT, ALG.

   3. SUBSTANTIVE: This document updates RFC 4975, section 7.1, which
      talks about ongoing sessions. However, to succeed, we also need to
      modify the matching procedure that takes place during session
      establishment. This is described in RFC 4975, section 5.4.

   4. SUBSTANTIVE: In the security section, we need to talk through the
      implications of this mechanism on TLS connections. After some
      cursory thought on the topic, I think it works correctly: outbound
      connections to MSRP relays will be okay, since the cert presented
      by the relay will match the hostname the client used to connect to
      it; and, for peer-to-peer mode (as described in RFC 4975, section
      14.4), the hostname isn't part of the information used to match
      the certificate. However, just because I think it works doesn't
      mean that it actually does. :) I'd be a lot more comfortable if we
      have a brief treatment of this issue in the security section so
      that it gets some explicit security review.

   5. NIT: Somewhere in the document, it would probably be good to cite
      the text from RFC 4975, section 14.1, regarding MSRP security
      properties: "Most components of the URI, such as the scheme and
      the authority components, are common knowledge.  The secrecy is
      entirely provided by the session-id component." This goes a long
      way towards allaying any concerns that the host portion was
      intended to provide any kind of protection when matching sessions.

/a

---

From: Ben Campbell <[email-masked]>
Date: Mon, 21 Dec 2009 17:44:30 -0600

On Dec 21, 2009, at 5:23 PM, Adam Roach wrote:

> Just for clarification: the fact that we're last calling these at the same time doesn't mean that we intend them to progress as a cluster (http://www.rfc-editor.org/cluster_def.html), does it? There is no normative dependency between them, and I'd hate to see them both be delayed due to issues related to only one of them (e.g., in IETF last call, or IESG review).
<as-chair>
I am not aware of any need for one of them to block the other. We will probably pubreq them together just because it may be easier for the IESG to interpret them together. But if we found a blocking problem with one draft, I don't see a need to delay the other.

If anyone feels this is in error, please let the chairs know asap.

Thanks!

Ben.