Re: [MMUSIC] I-D Action: draft-ietf-mmusic-media-path-middleboxes-06.txt

Flemming Andreasen <fandreas@cisco.com> Mon, 28 January 2013 17:12 UTC

Return-Path: <fandreas@cisco.com>
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 6251921F881A for <mmusic@ietfa.amsl.com>; Mon, 28 Jan 2013 09:12:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Y7N4WjWzZ8F for <mmusic@ietfa.amsl.com>; Mon, 28 Jan 2013 09:12:43 -0800 (PST)
Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id CBB6B21F87FE for <mmusic@ietf.org>; Mon, 28 Jan 2013 09:12:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2054; q=dns/txt; s=iport; t=1359393163; x=1360602763; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=ZbniOQrykF7dETI+RuP5Zp3AOZkFgzAc5r+o3eediDQ=; b=fqFK9dvKWdqWTw5X6ZlH5nX3fJsVv/ZF/DchGvGFaC+lh6I+3zBmUo/5 F06E8AP1gT62uH3AXBMweiq2R/PN0iwU7TPZWv4E+1AIhddzURV5BLaE2 j//EdSML4Hvfq+7YjerqaKmuIZYwtvHqOvk0cpmFz/3Eg5aXwVZgjEU7F M=;
X-IronPort-AV: E=Sophos;i="4.84,553,1355097600"; d="scan'208";a="69818573"
Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 28 Jan 2013 17:12:42 +0000
Received: from Flemmings-MacBook-Pro.local ([10.156.16.34]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r0SHCf6s008508; Mon, 28 Jan 2013 17:12:41 GMT
Message-ID: <5106B189.5090909@cisco.com>
Date: Mon, 28 Jan 2013 12:12:41 -0500
From: Flemming Andreasen <fandreas@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Hadriel Kaplan <HKaplan@acmepacket.com>
References: <20130110224503.20977.89170.idtracker@ietfa.amsl.com> <157CAB7C-8AF8-4F98-9165-10A000DC9EA5@cisco.com> <021201cdef86$96f50ab0$c4df2010$@cisco.com> <A6368A20-007B-4A25-B39F-8FA1E685A7CA@acmepacket.com>
In-Reply-To: <A6368A20-007B-4A25-B39F-8FA1E685A7CA@acmepacket.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: mmusic <mmusic@ietf.org>
Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-media-path-middleboxes-06.txt
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: Mon, 28 Jan 2013 17:12:44 -0000

On 1/25/13 3:53 PM, Hadriel Kaplan wrote:
> On Jan 10, 2013, at 6:02 PM, Dan Wing <dwing@cisco.com> wrote:
>
>> I am glad this document was resurrected.
>>
>> Can the document say SBC instead of the awkward (and inaccurate)
>> "SIP ALG combined with MIDCOM agent"?  Or is saying SBC impolitic.
>>
> I don't think it can or should say "SBC" - because this doc does not describe what an SBC does.  At least not the first half (section 4), which is really about an inline ALG in the router/firewall. (ie, it's not the target/source of the IP addresses of the packets, doesn't change SIP/SDP, etc.)
>
> Anyway, I read this latest draft, and it looks exactly like the older ones, so I don't see it fixing the issues with the older ones:
> 1) It claims to describe the impact on ICE, but doesn't
> 2) Doesn't describe the issues with forked or moved calls on early in-band media signaling (especially if you actually comply with recommendations #2+#4)
> 3) Uses terminology from ancient history (ie, RFC 3303) that no one else uses
> 4) Recommendation #5 is backwards I think - it should recommend protocols not to require/expect to exchange media-plane signaling after the session has been terminated. (in other words, since you can't rely on middleboxes being lenient, don't design a protocol to expect them to be so)
Thanks for taking a look and providing your comments Hadriel. As per 
previous discussions, we wanted to first agree on the scope of the 
document and whether there was still value in pursuing such a document. 
As per Gonzalo's e-mail starting this thread, do you have any 
comments/concerns on that part (if so, please let the authors know what 
those are) ?

Once (/if) we get agreement on the scope, we can then get into detail 
around the technical aspects of the document as per your comments above.

Thanks

-- Flemming (MMUSIC co-chair)


> -hadriel
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>