Raptor Forward Error Correction (FEC) Schemes for FECFRAME
RFC 6681

Note: This ballot was opened for revision 10 and is now closed.

(David Harrington) Yes

(Martin Stiemerling) (was Discuss) Yes

Comment (2012-05-14)
No email
send info
All cleared and thanks for addressing the points.

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

(Benoît Claise) No Objection

Comment (2012-04-23 for -10)
No email
send info
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:

(Ralph Droms) No Objection

(Wesley Eddy) No Objection

(Adrian Farrel) No Objection

(Stephen Farrell) No Objection

Comment (2012-04-23 for -10)
No email
send info
- 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.)

(Brian Haberman) No Objection

(Russ Housley) No Objection

Comment (2012-04-24 for -10)
No email
send info
  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

Barry Leiba No Objection

(Pete Resnick) No Objection

(Robert Sparks) No Objection

Comment (2012-04-24 for -10)
No email
send info
In section 7.2.1.2 did you mean to point to 6.2.1.2 instead of 6.2.2?

(Sean Turner) No Objection

Comment (2012-04-25 for -10)
No email
send info
I guess I'm with Stephen on the security considerations it should really also point to RFCs 5053 or 6330.