[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)