Re: [MMUSIC] WGLC of draft-ietf-mmusic-media-loopback-18
Flemming Andreasen <fandreas@cisco.com> Tue, 10 April 2012 16:39 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 5374D11E8117 for <mmusic@ietfa.amsl.com>; Tue, 10 Apr 2012 09:39:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level:
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
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 Jm7Qlya29Vax for <mmusic@ietfa.amsl.com>; Tue, 10 Apr 2012 09:39:37 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 3420411E80E8 for <mmusic@ietf.org>; Tue, 10 Apr 2012 09:39:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fandreas@cisco.com; l=9475; q=dns/txt; s=iport; t=1334075977; x=1335285577; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=ztYGQ+pHHziKoS1sB2H1KgebuUvxYU2XbK/LNf3VzG4=; b=eadN+QXbosFBE6e4RPkQzTp1VWultL8MPTxJ9KJiRBG1EmPYBkxwCtty aMEXlA1dslulgdEiv58CQqZ9l73LCnNoVJvM+GoWiTzjuke+mxHYFtGP9 XhNXx3dgatz3XF8KcQkOYhR30QdUF+6r6Uqjg7c2UER906QWr3bdQU2yJ 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgAFAH1hhE+tJXG8/2dsb2JhbABEgka2ZYEHggkBAQEEEgEKUQoBEAsYCQwKDwkDAgECAUUGDQEHAQEeh2yaZ6BCiyKCD4MwBJVsjk2BaYMDgUA
X-IronPort-AV: E=Sophos; i="4.75,399,1330905600"; d="scan'208,217"; a="73533988"
Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-5.cisco.com with ESMTP; 10 Apr 2012 16:39:36 +0000
Received: from rtp-fandreas-8717.cisco.com (rtp-fandreas-8717.cisco.com [10.117.7.88]) by rcdn-core2-1.cisco.com (8.14.5/8.14.3) with ESMTP id q3AGdZGE004184; Tue, 10 Apr 2012 16:39:36 GMT
Message-ID: <4F846247.8010309@cisco.com>
Date: Tue, 10 Apr 2012 12:39:35 -0400
From: Flemming Andreasen <fandreas@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.16) Gecko/20101125 Thunderbird/3.0.11
MIME-Version: 1.0
To: "Miguel A. Garcia" <Miguel.A.Garcia@ericsson.com>
References: <4F79A716.3080804@ericsson.com>
In-Reply-To: <4F79A716.3080804@ericsson.com>
Content-Type: multipart/alternative; boundary="------------050407090007050902030204"
Cc: draft-ietf-mmusic-media-loopback.authors@tools.ietf.org, mmusic <mmusic@ietf.org>
Subject: Re: [MMUSIC] WGLC of draft-ietf-mmusic-media-loopback-18
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: Tue, 10 Apr 2012 16:39:38 -0000
I have reviewed loopback-18 and have a couple of comments: General: - I'm missing considerations around SRTP. It needs to be described in here how that works (e.g. what do you copy for RTP packet loopback and just be clear that each side does its normaly SRTP processing on both send and receive). Specific sections: - Abstract and Introduction: Says it defines new SDP media attributes. Should also mention it defines new MIME types - 3.2, first paragraph: Change "specific media types" to "specific media descriptions" I believe the "MAY" should be a "MUST" - 4.1, first paragraph Change "property media attribute" to "value media attribute" and add reference to [RFC4566] - 4.2, first paragraph Change "value media attribute" to "property media attribute" and add reference to [RFC4566] - 5.1, third paragraph Instead of "terminate the session", we should rather just talk about "reject the offer". - 5.2, first paragraph add "and hence MUST NOT be used" to the end. - 5.2 The first two examples use RFC 2119 language ("MUST") whereas the last one does not. Given these are examples, I think they should all use lower-case "must" -6, third paragraph rtp-media-loopback gets congestion considerations, whereas rtp-pkt-loopback in the the preceding paragraph does not. I believe it applies equally well to both. - 7, second paragraph Overall, I find this paragraph difficult to follow - it would be helpful to rephrase and/or elaborate. <quote> To keep the implementation of loopback-mirrors simple it is mandated that no payload format other than encapsulated or direct loopback formats can be used in the packets generated by a loopback-mirror. As described in RFC 3550 [RFC3550], sequence numbers and timestamps in the RTP header are generated with initial random values for security reasons. If this were not mandated and the source payload is sequence number aware, the loopback-mirror will be required to understand that payload format to generate looped back packets that do not violate RFC 3550 [RFC3550]. Requiring looped back packets to be in one of the two formats means loopback-mirror does not have to look into the actual payload received before generating the loopback packets. </quote> Some specific questions: a) If this is only an issue for the loopback-mirror, then why do we need to mandate it ? If it affects the source, then we need to elaborate on this in the O/A section, since it presumably imposes restrictions on the answerer operation (that were not called out there). Also, if we keep it as "mandated", then we need to use RFC 2119 language instead. b) What does "this" refer to in the third sentence. The immediately preceding sentence, or the one before it ? c) The paragraph does not seem to account for the "media loopback" case. This is probably because it is the payload format section where media loopback is not defined and hence it's not intended to. It's confusing as it reads though. - 11, second paragraph s/recommended/RECOMMENDED - 11, third paragraph The "infinite looping" attack seems to suggest there should be some form of rate limiting at the mirror (would be helpful at the source as well of course) - 13.2 Change from MIME to Media Type registration of RTP payload formats per RFC 4855. Text in registrations need to be updated accordingly (s/MIME/media type/). I have a few additional nit fixes which I will forward directly to the authors. Thanks -- Flemming On 4/2/12 9:18 AM, Miguel A. Garcia wrote: > This is to start a 2-week Working Group Last Call for > > draft-ietf-mmusic-media-loopback-18.txt > > The WGLC ends on April 16th, 2012. > > Please reply to this e-mail to send comments, so that the authors and > the mailing list are all copied. > > /Miguel >
- [MMUSIC] WGLC of draft-ietf-mmusic-media-loopback… Miguel A. Garcia
- Re: [MMUSIC] WGLC of draft-ietf-mmusic-media-loop… Miguel A. Garcia
- Re: [MMUSIC] WGLC of draft-ietf-mmusic-media-loop… Flemming Andreasen
- Re: [MMUSIC] WGLC of draft-ietf-mmusic-media-loop… Magnus Westerlund
- Re: [MMUSIC] WGLC of draft-ietf-mmusic-media-loop… Nagarjuna Venna
- Re: [MMUSIC] WGLC of draft-ietf-mmusic-media-loop… Hadriel Kaplan
- Re: [MMUSIC] WGLC of draft-ietf-mmusic-media-loop… Gunnar Hellström
- Re: [MMUSIC] WGLC of draft-ietf-mmusic-media-loop… Miguel A. Garcia
- Re: [MMUSIC] WGLC of draft-ietf-mmusic-media-loop… Hadriel Kaplan