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
- [midcom] Last Call: 'MIDCOM Protocol Semantics' t… The IESG
- Reminder: [midcom] Last Call: 'MIDCOM Protocol Se… Melinda Shore
- FW: Reminder: [midcom] Last Call: 'MIDCOM Protoco… Melinda Shore
- Re: [midcom] Last Call: 'MIDCOM Protocol Semantic… Juergen Quittek