Subject: [apps-discuss] apps-review comments for draft-ietf-fecframe-framework-10

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 21 Sep 2010 22:18:35 -0700

I have been selected as the Applications Area Review Team reviewer for this draft (for background on apps-review, please see http://www.apps.ietf.org/content/applications-area-review-team).

Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft.

Document: draft-ietf-fecframe-framework-10
Reviewer: Murray S. Kucherawy
Review Date: September 21, 2010
IETF Last Call Date: August 9-23, 2010
IESG Telechat Date: September 23, 2010

Summary: This draft is almost ready for publication as a Standards Track RFC.  I believe the technical material is sound, but it has a few substantive document-level issues and numerous grammatical/editorial nits that should be reviewed before publication.

MAJOR ISSUES: None.

MINOR ISSUES: 

General:
- Any discussion of existing interoperating implementations and issues found during that work, if any, might be useful to include in an appendix.

Section 2: Definitions/Abbreviations
- That "Application Data Unit" can be expressed as "ADU" should be stated explicitly, even though the connection is fairly obvious.
- "Application Protocol" references "RTSP" but that is not defined elsewhere in this section.  It should be at least expanded if not defined or even made an informative reference.  (Or if it's merely a typo, it should be corrected.)

Section 3: Architecture Overview
- The paragraph starting "Depending on the FEC Scheme, ..." presents what appears to be an implementation variant.  For the sake of user guidance, the author might consider including some language about why one might choose to do (or be forced to do) what is described there.  If one of the other reference documents does discuss this, perhaps a section-specific reference to that here would be appropriate.

Section 4.1: General
- The language about optionally constructing an FEC Scheme that jointly protects multiple Source Data Flows could use some guidance text as suggested above (i.e. what are the advantages and disadvantages of those choices).  If adding such pedagogy here seems intrusive, it could be included in an appendix and simply referenced here.
- There is mixed use of "may" and "MAY", "must" and "MUST" in this section.  RFC2119 doesn't actually say it applies only to the uppercase form of those words.  Thus, the author might wish to substitute a word like "might" or "could" for the lowercase ones.
- There is again some text about optional ways to implement or transmit Source FEC Payload IDs, and some language about why one approach or the other is appropriate in certain circumstances might be helpful.

Section 5.3: Packet format for FEC Source Packets
- There is an acronym "ROHC" in the fifth paragraph.  It may come from Robust Header Compression earlier in that paragraph; if so, that should be made explicit.

Section 5.5: The normative reference to ABNF is probably not necessary here because the ABNF is actually contained in the referenced document.  This memo itself contains no ABNF.

Section 8: Congestion Control
- The format of this section, namely a large informative preamble to a small normative paragraph, seems awkward to me.  I suggest moving the informative note text into a new "Section 8.2: Discussion".

Section 10: IANA Considerations
- I can't tell if this section is creating a new registry with IANA or referring to an existing one.  I suggest making that more explicit.  More liberal application of RFC5226 is probably appropriate.  If this memo is creating a new registry, a registration template, perhaps even with an example, should be provided.  See RFC4288 for an example of a blank template and registry creation in detail.  RFC5965 creates a registry, provides a template, and then uses the template to declare the registry's initial contents, thus providing examples as well.  It looks like FEC Framework registrations could be quite large, so an abbreviated example is probably appropriate.
- Is 256 possible registrations plenty for the foreseeable future?  It seems kind of small.
- If Section 5.6 defines the registration requirements, then perhaps those should be enumerated here instead and 5.6 can refer to this section.

NITS:

Numerous but all grammatical, and will be sent separately so as not to slow the IESG Review process.

Cheers,
-MSK