Re: [midcom] Last Call: 'MIDCOM Protocol Semantics' to Proposed Standard (rfc3989)

Juergen Quittek <quittek@netlab.nec.de> Tue, 13 March 2007 11:01 UTC

Return-path: <midcom-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HR4l9-0001V3-OK; Tue, 13 Mar 2007 07:01:39 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HR4l7-0001UC-9Q for midcom@ietf.org; Tue, 13 Mar 2007 07:01:37 -0400
Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HR4l5-0005mI-Ey for midcom@ietf.org; Tue, 13 Mar 2007 07:01:37 -0400
Received: from [10.1.1.104] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id CAAFC13CF81; Tue, 13 Mar 2007 12:01:27 +0100 (CET)
Date: Tue, 13 Mar 2007 12:01:30 +0100
From: Juergen Quittek <quittek@netlab.nec.de>
To: midcom@ietf.org
Subject: Re: [midcom] Last Call: 'MIDCOM Protocol Semantics' to Proposed Standard (rfc3989)
Message-ID: <2015DC0840714E0DFCAD4B7E@n-quittek2.office>
In-Reply-To: <E1GrFXZ-0002jl-57@stiedprstage1.ietf.org>
References: <E1GrFXZ-0002jl-57@stiedprstage1.ietf.org>
X-Mailer: Mulberry/4.0.5 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 83e9494d829b08cc3f644ef6ac1b9bd4
Cc: Cullen Jennings <fluffy@cisco.com>
X-BeenThere: midcom@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: midcom.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/midcom>, <mailto:midcom-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:midcom@ietf.org>
List-Help: <mailto:midcom-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/midcom>, <mailto:midcom-request@ietf.org?subject=subscribe>
Errors-To: midcom-bounces@ietf.org

Dear all,

The IESG carefully reviewed RFC3989 and found one serious issue to fix.

In example for using the MIDCOM protocol given in section 4.2.
describes a SIP proxy that modifies the body of a SIP message.
This is is explicitly forbidden by RFC 3261.

We suggest fixing this by replacing the SIP proxy in the example
with a back-to-back user agent.

The required changes to the document are described in the editor note
below.

Thanks,

    Juergen

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

The editor notes listed below are mainly a replacement of the
term "SIP proxy server" with the term "back-to-back user agent",
or "B2BUA" in section 4.2 of RFC 3989.

In detail, the replacement varies.
First the abbreviation is introduced by replacing "SIP proxy" with
"back-to-back user agent (B2BUA)".  Then only the abbreviated form
"B2BUA" is used.

In RFC 3989, the "SIP proxy server" is sometimes alternatively called
just "SIP server" or "SIP proxy".  In any case the term needs to be
replaced with "B2BUA".

Here is a list of all replacements:

===============
In first paragraph of section 4.2:
replace OLD:
   This elaborated transaction usage example shows the interaction
   between a SIP proxy and a middlebox.  The middlebox itself is a
   traditional Network Address and Port Translator (NAPT), and two SIP
   user agents communicate with each other via the SIP proxy and NAPT,
   as shown in Figure 10.  The MIDCOM agent is co-located with the SIP
   proxy, and the MIDCOM server is at the middlebox.  Thus, the MIDCOM
   protocol runs between the SIP proxy and middlebox.
with NEW:
   This elaborated transaction usage example shows the interaction
   between a back-to-back user agent (B2BUA) and a middlebox.  The middlebox itself is a
   traditional Network Address and Port Translator (NAPT), and two SIP
   user agents communicate with each other via the B2BUA and a NAPT,
   as shown in Figure 10.  The MIDCOM agent is co-located with the B2BUA,
   and the MIDCOM server is at the middlebox.  Thus, the MIDCOM
   protocol runs between the B2BUA and the middlebox.

===============
In Figure 10:
OLD:
               +-------------+
               | SIP Proxy   |
               | for domain  ++++
               | example.com |  +
               +-------------+  +
NEW:
               +-------------+
               | B2BUA       |
               | for domain  ++++
               | example.com |  +
               +-------------+  +

===============
Item list after Figure 10:
OLD:
   For the sequence charts below, we make these assumptions:

      - The NAPT is statically configured to forward SIP signaling from
        the outside to the SIP proxy server -- i.e., traffic to the
        NAPT's external IP address and port 5060 is forwarded to the
        internal SIP proxy.

      - The SIP user agent A, located inside the private network, is
        registered at the SIP proxy with its private IP address.

      - User A knows the general SIP URL of user B.  The URL is
        B@example.org.  However, the concrete URL of the SIP User Agent
        B, which user B currently uses, is not known.

      - The RTP paths are configured, but not the RTCP paths.

      - The middlebox and the SIP server share an established MIDCOM
        session.
NEW:
   For the sequence charts below, we make these assumptions:

      - The NAPT is statically configured to forward SIP signaling from
        the outside to the B2BUA -- i.e., traffic to the
        NAPT's external IP address and port 5060 is forwarded to the
        internal B2BUA.

      - The SIP user agent A, located inside the private network, is
        registered at the B2BUA with its private IP address.

      - User A knows the general SIP URL of user B.  The URL is
        B@example.org.  However, the concrete URL of the SIP User Agent
        B, which user B currently uses, is not known.

      - The RTP paths are configured, but not the RTCP paths.

      - The middlebox and the B2BUA share an established MIDCOM
        session.

===============
One but last paragraph on page 55:
OLD:
   In our example, user A tries to call user B.  The user agent A sends
   an INVITE SIP message to the SIP proxy server (see Figure 10).  The

NEW:
   In our example, user A tries to call user B.  The user agent A sends
   an INVITE SIP message to the B2BUA (see Figure 10).  The

===============
Paragraph before Figure 11, line 3:
OLD:
   media stream.  The SIP proxy requests a policy enable rule at the
NEW:
   media stream.  The B2BUA requests a policy enable rule at the

===============
Figure 11:
OLD:
   User Agent       SIP                        Middlebox   User Agent
    A              Proxy                          NAPT             B
NEW:
   User Agent      B2BUA                       Middlebox   User Agent
    A                                             NAPT             B

===============
Second paragraph after Figure 11, line 4:
OLD:
   supported'.  Nevertheless, the SIP proxy server needs an outside IP
NEW:
   supported'.  Nevertheless, the B2BUA needs an outside IP

===============
Third paragraph after Figure 11, last line:
OLD:
   is not permitted, the SIP proxy server uses the PRR transaction.
NEW:
   is not permitted, the B2BUA uses the PRR transaction.

===============
Paragraph before Figure 12, first line:
OLD:
   By using the PRR request, the SIP proxy requests an outside IP
NEW:
   By using the PRR request, the B2BUA requests an outside IP

===============
Paragraph before Figure 12, line 7:
OLD:
   message, the SIP proxy server replaces the IP address and port number
NEW:
   message, the B2BUA replaces the IP address and port number

===============
Figure 12:
OLD:
   User Agent       SIP                        Middlebox   User Agent
    A              Proxy                          NAPT             B
NEW:
   User Agent      B2BUA                       Middlebox   User Agent
    A                                             NAPT             B

===============
Second paragraph after Figure 12:
OLD:
   Now, the SIP proxy server has sufficient information for establishing
NEW:
   Now, the B2BUA has sufficient information for establishing

===============
Paragraph before Figure 13, one but last line:
OLD:
   streams, the SIP proxy can forward the '200 OK' SIP message to user
NEW:
   streams, the B2BUA can forward the '200 OK' SIP message to user

===============
Figure 13:
OLD:
   User Agent       SIP                        Middlebox   User Agent
    A              Proxy                          NAPT             B
NEW:
   User Agent      B2BUA                       Middlebox   User Agent
    A                                             NAPT             B

===============
Paragraph after Figure 13, line 2:
OLD:
   message to user agent A.  The SIP proxy forwards all SIP messages and
NEW:
   message to user agent A.  The B2BUA forwards all SIP messages and

===============
Figure 14:
OLD:
   User Agent       SIP                        Middlebox   User Agent
    A              Proxy                          NAPT             B
NEW:
   User Agent      B2BUA                       Middlebox   User Agent
    A                                             NAPT             B


--On 04.12.06 10:15 -0500 The IESG wrote:

> The IESG has received a request from the midcom WG to consider the
> following document:
>
> - 'MIDCOM Protocol Semantics '
>   RFC 3989 as a Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send any comments to the
> iesg@ietf.org or ietf@ietf.org mailing lists by 2006-12-21.
>
> The file can be obtained via
> http://www.ietf.org/rfc/rfc3989.txt
>
> Please note that this document contains 4 normative references:
>
>    [MDC-FRM]   Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A.,
>                and A. Rayhan, "Middlebox communication architecture and
>                framework", RFC 3303, August 2002.
>
>    [MDC-REQ]   Swale, R., Mart, P., Sijben, P., Brim, S., and M. Shore,
>                "Middlebox Communications (midcom) Protocol
>                Requirements", RFC 3304, August 2002.
>
>    [NAT-TERM]  Srisuresh, P. and M. Holdrege, "IP Network Address
>                Translator (NAT) Terminology and Considerations", RFC
>                2663, August 1999.
>
>    [NAT-TRAD]  Srisuresh, P. and K. Egevang, "Traditional IP Network
>                Address Translator (Traditional NAT)", RFC 3022, January
>                2001.
>
> These 4 references to informational documents are not what would be
> normally considered normative references in a standards track documents.
> This is a result of the propsed reclassification from informational to
> proposed standard. Therefore this last call explicitly identifies these as
> downrefs. This downref last call according to RFC 3967 shall not be
> considred a precedence for using the above reference in the future as
> normative references without an last call.
>
>
> _______________________________________________
> midcom mailing list
> midcom@ietf.org
> https://www1.ietf.org/mailman/listinfo/midcom



-- 
Juergen Quittek        quittek@netlab.nec.de       Tel: +49 6221 4342-115
NEC Europe Limited,    Network Laboratories        Fax: +49 6221 4342-155
Kurfuersten-Anlage 36, 69115 Heidelberg, Germany   http://www.netlab.nec.de
Registered Office: NEC House, 1 Victoria Road, London W3 6BL, UK
Registered in England 2832014

_______________________________________________
midcom mailing list
midcom@ietf.org
https://www1.ietf.org/mailman/listinfo/midcom