Re: [MMUSIC] Comments to draft-ietf-mmusic-media-path-middleboxes

"Hannes Tschofenig" <Hannes.Tschofenig@gmx.net> Fri, 31 May 2013 11:31 UTC

Return-Path: <hannes.tschofenig@gmx.net>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C429D21F9195 for <mmusic@ietfa.amsl.com>; Fri, 31 May 2013 04:31:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.38
X-Spam-Level:
X-Spam-Status: No, score=-100.38 tagged_above=-999 required=5 tests=[AWL=0.761, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xnWQYNHumF7S for <mmusic@ietfa.amsl.com>; Fri, 31 May 2013 04:31:05 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id 6455B21F910D for <mmusic@ietf.org>; Fri, 31 May 2013 04:31:05 -0700 (PDT)
Received: from 3capp-gmx-bs43.server.lan ([172.19.170.95]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0MfC3Y-1V2o4j3ITa-00Ommr; Fri, 31 May 2013 13:31:03 +0200
Received: from [194.251.119.198] by 3capp-gmx-bs43.server.lan with HTTP; Fri May 31 13:31:03 CEST 2013
MIME-Version: 1.0
Message-ID: <trinity-5cde67cb-3510-4023-8bc3-6a446c2d4dd9-1369999863681@3capp-gmx-bs43>
From: "Hannes Tschofenig" <Hannes.Tschofenig@gmx.net>
To: "Ivo Sedlacek" <ivo.sedlacek@ericsson.com>
Content-Type: text/html; charset=UTF-8
Date: Fri, 31 May 2013 13:31:03 +0200 (CEST)
Importance: normal
Sensitivity: Normal
In-Reply-To: <39B5E4D390E9BD4890E2B310790061010D77EF@ESESSMB301.ericsson.se>
References: <39B5E4D390E9BD4890E2B310790061010D72D7@ESESSMB301.ericsson.se> <673F23F8-5627-4F4A-A5ED-3A7987A634D0@cisco.com>, <39B5E4D390E9BD4890E2B310790061010D77EF@ESESSMB301.ericsson.se>
X-UI-Message-Type: mail
X-Priority: 3
X-Provags-ID: V03:K0:5HJmCYnzjb/qo+AMLmPqIPKyU9RPZ3ktwYctYI9ql0d zzkyf8YtCKVCxE92Ae/XV3uNb5TWUn9IiOg2wXWEmLOJ3443xG uUHaA2NsX8gssV3zNjKgtYpwYtHDkwxy1nPy4Ab8HHcXdKSfAE BU0UW620pQjNNbsMxHy7wlGNL4MJQmPFEQIWskq0vYqqToaQa3 Q4G9ULEKWnKWt25a5xttj4jc8vPX9zy0p8N9i3hpkKRlm2JR5B gjS/1TYG0ie9qykhMI73dXrYoQlkpsd2JkTss+tC3kGQxZSdAK z5spoA=
Cc: "obsidian97@gmail.com" <obsidian97@gmail.com>, "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] Comments to draft-ietf-mmusic-media-path-middleboxes
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 31 May 2013 11:31:09 -0000

Thanks for the careful reading of the document and for providing actionable feedback, Ivo. 
And thanks to Gonzalo for reacting so quickly with a new draft update. 
 
Ciao
Hannes
 
Gesendet: Freitag, 31. Mai 2013 um 11:49 Uhr
Von: "Ivo Sedlacek" <ivo.sedlacek@ericsson.com>
An: "Gonzalo Salgueiro" <gsalguei@cisco.com>
Cc: "Hannes.Tschofenig@gmx.net" <Hannes.Tschofenig@gmx.net>et>, "obsidian97@gmail.com" <obsidian97@gmail.com>om>, "mmusic@ietf.org" <mmusic@ietf.org>
Betreff: RE: Comments to draft-ietf-mmusic-media-path-middleboxes
Thank you for covering my comments in draft-ietf-mmusic-media-path-middleboxes-07.

Kind regards

Ivo Sedlacek

This Communication is Confidential. We only send and receive email on the basis of the terms set out at http://www.ericsson.com/email_disclaimer" target="_blank" rel="nofollow">www.ericsson.com/email_disclaimer

-----Original Message-----
From: Gonzalo Salgueiro [mailto:gsalguei@cisco.com]
Sent: 30. května 2013 20:03
To: Ivo Sedlacek
Cc: Hannes.Tschofenig@gmx.net; obsidian97@gmail.com; mmusic@ietf.org
Subject: Re: Comments to draft-ietf-mmusic-media-path-middleboxes

Thanks, Ivo. I have posted a new version addressing your and Bruno's comments.

Thanks,

Gonzalo

On May 30, 2013, at 10:11 AM, Ivo Sedlacek <ivo.sedlacek@ericsson.com> wrote:

> Hello,
>
> Comments to draft-ietf-mmusic-media-path-middleboxes-06:
>
> Comment 1:
>
> ISSUE:
>
> http://tools.ietf.org/html/draft-ietf-mmusic-media-path-middleboxes-06" target="_blank" rel="nofollow">http://tools.ietf.org/html/draft-ietf-mmusic-media-path-middleboxes-06 states:
> -------------------
> 3. Architecture
>
> Figure 1 shows the architecture that is being considered in this
> document with respect to firewall and NAT traversal using media
> relaying. The timing and directionality with which media packets are
> allowed to traverse a particular edge device is the subject of this
> investigation. The MIDCOM agent thereby pushes policy rules to the
> middlebox that allow or deny certain flows to >>bypass<<. Additionally,
> in case of media relaying it is important for the MIDCOM agent to
> adjust the signaling messages.
>
>
> SIP +-----------------+ SIP
> +-----+ Signaling | SIP ALG | Signaling +-----+
> | UAC |<----------->+-----------------+<----------->| UAS |
> +-----+ | MIDCOM Agent | +-----+
> ^ +-----------------+ ^
> | ^ |
> | Policy rule(s) | and NAT bindings |
> | v |
> | Media +-------------+ Media |
> +----------------->| Middlebox |<-----------------+
> +-------------+
>
> Figure 1: Analysed Firewalling Architecture
>
> The aspects of packet filtering are described in Section 4 whereas
> NAT traversal is illustrated in Section 5.
> -------------------
>
> The word "bypass" does not seem to be correct.
>
> "bypass" is defined by http://dictionary.cambridge.org/" target="_blank" rel="nofollow">http://dictionary.cambridge.org/ as: "to avoid something by going around it" or " to ignore a rule or official authority".
>
> However, the figure 1 shows media of the flows passing through/via the middlebox, not around the middlebox.
>
>
> PROPOSAL:
> -------------------
> 3. Architecture
>
> Figure 1 shows the architecture that is being considered in this
> document with respect to firewall and NAT traversal using media
> relaying. The timing and directionality with which media packets are
> allowed to traverse a particular edge device is the subject of this
> investigation. The MIDCOM agent thereby pushes policy rules to the
> middlebox that allow or deny certain flows to >>pass through<<. Additionally,
> in case of media relaying it is important for the MIDCOM agent to
> adjust the signaling messages.
>
>
> SIP +-----------------+ SIP
> +-----+ Signaling | SIP ALG | Signaling +-----+
> | UAC |<----------->+-----------------+<----------->| UAS |
> +-----+ | MIDCOM Agent | +-----+
> ^ +-----------------+ ^
> | ^ |
> | Policy rule(s) | and NAT bindings |
> | v |
> | Media +-------------+ Media |
> +----------------->| Middlebox |<-----------------+
> +-------------+
>
> Figure 1: Analysed Firewalling Architecture
>
> The aspects of packet filtering are described in Section 4 whereas
> NAT traversal is illustrated in Section 5.
> -------------------
>
> Comment 2:
>
> ISSUE:
>
> http://tools.ietf.org/html/draft-ietf-mmusic-media-path-middleboxes-06" target="_blank" rel="nofollow">http://tools.ietf.org/html/draft-ietf-mmusic-media-path-middleboxes-06 states:
> -------------------
> REC #4: If signaling on the media path is required before media can
> flow, the >>answer<< should send the SDP answer as soon as possible,
> for example within a provisional SIP response, to allow the media
> path signaling to bypass middleboxes and therefore to avoid
> clipping.
> -------------------
> I believe there is an error.
>
> PROPOSAL:
> -------------------
> REC #4: If signaling on the media path is required before media can
> flow, the >>answerer<< should send the SDP answer as soon as possible,
> for example within a provisional SIP response, to allow the media
> path signaling to bypass middleboxes and therefore to avoid
> clipping.
> -------------------
>
> Comment 3:
>
> ISSUE:
>
> http://tools.ietf.org/html/draft-ietf-mmusic-media-path-middleboxes-06" target="_blank" rel="nofollow">http://tools.ietf.org/html/draft-ietf-mmusic-media-path-middleboxes-06 states:
> -------------------
> REC #4: If signaling on the media path is required before media can
> flow, the answer should send the SDP answer as soon as possible,
> for example within a provisional SIP response, to allow the media
> path signaling to >>bypass<< middleboxes and therefore to avoid
> clipping.
> -------------------
> Same issue as in Comment 1.
>
> PROPOSAL:
> -------------------
> REC #4: If signaling on the media path is required before media can
> flow, the answer should send the SDP answer as soon as possible,
> for example within a provisional SIP response, to allow the media
> path signaling to >>pass through<< middleboxes and therefore to avoid
> clipping.
> -------------------
>
>
> Kind regards
>
> Ivo Sedlacek
>
> Ericsson
> Mobile +420 608 234 709
> ivo.sedlacek@ericsson.com
> http://www.ericsson.com" target="_blank" rel="nofollow">www.ericsson.com
>
> This Communication is Confidential. We only send and receive email on the basis of the terms set out at http://www.ericsson.com/email_disclaimer" target="_blank" rel="nofollow">www.ericsson.com/email_disclaimer