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
>