Raptor Forward Error Correction (FEC) Schemes for FECFRAME
draft-ietf-fecframe-raptor-11

4.1.  Definitions

   This document uses definitions that apply to FEC Framework in general
   as defined in [RFC6363].  In addition, this document uses the
   following definitions:

Not sure what "that apply to FEC Framework in general" means.
Don't you want to say something such as

   The FEC-specific terminology used in this document is defined in [RFC6363].
   In this document, as in [RFC6363], the first letter of
   each FEC-specific is capitalized along with the new terms defined here:

In section 7.2.1.2 did you mean to point to 6.2.1.2 instead of 6.2.2?

  Please consider the editorial comments from the Gen-ART Review by
  Kathleen Moriarty on 18-Mar-2012.  The review can be found at:
  http://www.ietf.org/mail-archive/web/gen-art/current/msg07284.html

I guess I'm with Stephen on the security considerations it should really also point to RFCs 5053 or 6330.

- Its not clear to me whether the "device" mentioned in the IPR
declaration's licensing section really only means h/w devices or not,
or could badly impact e.g. an OSS implementation of this draft. I
assume the WG have considered this and are happy with the idea of the
license being specific to a "device" or at least don't seem to care (as
implied by the write-up).

- 6.2.1.2 - if the last octet is omitted then all the reserved bits
aren't sent. Would it be worth noting that it'd not be safe to omit
that octet if someone defines meanings for some of those reserved bits
in future? Would "MAY be omitted" be better (i.e. use a 2119 keyword)?
Finally, it'd have been nice if you had said that that octet SHOULD be
sent or SHOULD be omitted - why not do that?

- 7.1 - Would it be better to be explicit here about how the padding
with zeros is done? I.e., rfc6330 says that symbols K through K'-1 are
the padding symbols, the same is true here I think but good to say so,
if so rather than forcing the reader to check in rfc6330.

- 8.1.3 - Similar question about padding, though here the answer is
obvious I guess, but still maybe no harm saying.

- Section 9 defers to 6363 for security considerations, but 6330's and
5053's (identical?) security considerations seem more concrete, e.g.
they RECOMMEND using something like TELSA, whereas 6363 eventually says
"implement IPsec" but doesn't say much about what to use. It'd be good
to be clearer about what, if anything, is mandatory-to-implement or
SHOULD be used here. (This isn't a DISCUSS because all those RFCs
are normative references so in theory implementing this means doing
all of the above I guess.)