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

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

(David Harrington; former steering group member) Yes

Yes ( for -10)
No email
send info

(Martin Stiemerling; former steering group member) (was Discuss) Yes

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

(Adrian Farrel; former steering group member) No Objection

No Objection ( for -10)
No email
send info

(Barry Leiba; former steering group member) No Objection

No Objection ( for -10)
No email
send info

(Benoît Claise; former steering group member) No Objection

No Objection (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:

(Brian Haberman; former steering group member) No Objection

No Objection ( for -10)
No email
send info

(Pete Resnick; former steering group member) No Objection

No Objection ( for -10)
No email
send info

(Ralph Droms; former steering group member) No Objection

No Objection ( for -10)
No email
send info

(Robert Sparks; former steering group member) No Objection

No Objection (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?

(Ron Bonica; former steering group member) No Objection

No Objection ( for -10)
No email
send info

(Russ Housley; former steering group member) No Objection

No Objection (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

(Sean Turner; former steering group member) No Objection

No Objection (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.

(Stephen Farrell; former steering group member) No Objection

No Objection (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.)

(Stewart Bryant; former steering group member) No Objection

No Objection ( for -10)
No email
send info

(Wesley Eddy; former steering group member) No Objection

No Objection ( for -10)
No email
send info