[Fecframe] AD Review: draft-ietf-fecframe-rtp-raptor
"David Harrington" <ietfdbh@comcast.net> Tue, 30 August 2011 21:57 UTC
Return-Path: <ietfdbh@comcast.net>
X-Original-To: fecframe@ietfa.amsl.com
Delivered-To: fecframe@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5300121F8F12 for <fecframe@ietfa.amsl.com>; Tue, 30 Aug 2011 14:57:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.526
X-Spam-Level:
X-Spam-Status: No, score=-102.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, 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 bHWAEm8Wh3yp for <fecframe@ietfa.amsl.com>; Tue, 30 Aug 2011 14:57:06 -0700 (PDT)
Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by ietfa.amsl.com (Postfix) with ESMTP id 71D8E21F8E14 for <fecframe@ietf.org>; Tue, 30 Aug 2011 14:57:06 -0700 (PDT)
Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta05.westchester.pa.mail.comcast.net with comcast id SkyF1h0081ei1Bg55lybjk; Tue, 30 Aug 2011 21:58:35 +0000
Received: from davidPC ([67.189.235.106]) by omta24.westchester.pa.mail.comcast.net with comcast id SlyZ1h02u2JQnJT3klyaik; Tue, 30 Aug 2011 21:58:35 +0000
From: David Harrington <ietfdbh@comcast.net>
To: draft-ietf-fecframe-rtp-raptor@tools.ietf.org
Date: Tue, 30 Aug 2011 17:58:27 -0400
Message-ID: <13F059AA83B642759B6FFF44745AB29E@davidPC>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.1.7601.17609
Thread-index: AcxnX/JccXVEzNzIRoiNpCKRWcR69g==
Cc: fecframe-chairs@tools.ietf.org, fecframe@ietf.org
Subject: [Fecframe] AD Review: draft-ietf-fecframe-rtp-raptor
X-BeenThere: fecframe@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion of FEC Framework <fecframe.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/fecframe>, <mailto:fecframe-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/fecframe>
List-Post: <mailto:fecframe@ietf.org>
List-Help: <mailto:fecframe-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/fecframe>, <mailto:fecframe-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Aug 2011 21:57:07 -0000
Hi, I don't know if you missed these comments. I am waiting for a revised ID before starting Last Call. Can you get a revised ID asap? AD Review of draft-ietf-fecframe-rtp-raptor-04: It would be good to use RFC2119 keywords in active voice - "The implementer SHOULD select" (or is it the operator?) rather than "It is RECOMMENDED to select". For example, I recommend changing "The (integer) rate SHALL be larger than 1000". Whose responsibility is it to enforce this SHALL? MUST implementations reject values less than 1000? (if implementations don't enforce this, I don't know how you'll enforce this SHALL. Which means a user MAY choose a lower value; therefore this isn't really a MUST. yada yada yada ... So you should use active voice to be explicit about whose responsibility it is to enforce this MUST. (and similar to RFC 3665, MUST is for implementers; SHOULD is for users). in 5.1.1, rate definition. "rate: The RTP timestamp (clock) rate in Hz. The (integer) rate SHALL be larger than 1000 to provide sufficient resolution to RTCP operations. However, it is RECOMMENDED to select the rate that matches the rate of the protected source RTP stream." The However in this paragraph makes it sound like you recommend using the rate that matches (even if it is below 1000). I recommend removing the "However," in 5.1.1, s/shall/SHALL/ "Restrictions on usage: This media type depends on RTP framing, and hence is only defined for transfer via RTP [[RFC3550]]. Transport within other framing protocols is not defined at this time. " Do we need the "at this time"? Is it envisioned this media type will be exteneded for additional framing protocols at a later time? in 12 s/recommended/RECOMMENDED/, s/may/MAY/g in 8, is Session Announcement Protocol (SAP) [RFC2947] the right reference? I saw no mention of SAP in 2947. in 15.2, rfc2947 seems to refer to the wrong document. I think you need 2974. in 1, "Repair data flows may be sent directly over a transport protocol such as UDP, or they may be encapsulated within RTP." Is RTP the only prootocol that could be used to encapsulate flows? should this be "they may be encapsulated within specialized transports for multimedia, such as RTP"? s/FECs operates/FECs operate/ s/an FEC/a FEC/ Shepherd, Since AVT is the change controller, was this WGLC'd in AVT? Thanks, David Harrington Director, IETF Transport Area ietfdbh@comcast.net (preferred for ietf) dbharrington@huaweisymantec.com +1 603 828 1401 (cell)
- [Fecframe] AD Review: draft-ietf-fecframe-rtp-rap… David Harrington
- Re: [Fecframe] AD Review: draft-ietf-fecframe-rtp… Thomas Stockhammer
- Re: [Fecframe] AD Review: draft-ietf-fecframe-rtp… Ali C. Begen (abegen)
- Re: [Fecframe] AD Review: draft-ietf-fecframe-rtp… Greg Shepherd
- Re: [Fecframe] AD Review: draft-ietf-fecframe-rtp… Ali C. Begen (abegen)
- Re: [Fecframe] AD Review: draft-ietf-fecframe-rtp… David Harrington