Simple Reed-Solomon Forward Error Correction (FEC) Scheme for FECFRAME
draft-ietf-fecframe-simple-rs-06

[Ballot comment]

Just one substantive comment (the first one). While I'm not
objecting, I'd like to understand why you haven't put in that
MUST...

- p19, you have m=8 as the default, which is fine, but you only
say that that SHOULD be supported and used. That means that an
imlplementation could claim to conform to this spec that only
supported m=16 or some other value.  It would seem better to
say that m=8 MUST be supported by all implementations, esp.
since you imply that different methods will be used to
implement different m values. Is there a reason to not have
that MUST?

The rest are nits:

- abstract is terminology-rich, would be nicer if simplified.

- p5, "Some of them..." which "them"? (Same on p6)

- p11, it'd be nicer if L[x] was shown twice as wide as F[x] in
the simple FEC encoding diagram

- p12, would it be useful to say that the value of E in an SDP
has to be <2^16?

IANA has reviewed draft-ietf-fecframe-simple-rs-04 and has the following comments:

IANA understands that, upon approval of this document, there is a single action
which IANA must complete.

In the FEC Framework (FECFRAME) FEC Encoding IDs subregistry of the Reliable
Multicast Transport (RMT) FEC Encoding IDs and FEC Instance IDs located at:

http://www.iana.org/assignments/rmt-fec-parameters/rmt-fec-parameters.xml#fecframe-fec-encoding-ids

a single, new FEC Encoding ID will be registered as follows:

ID: [ TBD ]
Description: Simple Reed-Solomon FEC Scheme over GF(2^^m) for Arbitrary Packet
Flows
Reference: [ RFC-to-be ]

IANA understands that this is the only action required to be completed
upon approval of this document.

Note: The actions requested in this document will not be completed
until the document has been approved for publication as an RFC.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Simple Reed-Solomon Forward Error Correction (FEC) Scheme for FECFRAME) to Proposed Standard


The IESG has received a request from the FEC Framework WG (fecframe) to
consider the following document:
- 'Simple Reed-Solomon Forward Error Correction (FEC) Scheme for
FECFRAME'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2012-10-22. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document describes a fully-specified simple FEC scheme for Reed-
  Solomon codes over GF(2^^m), with 2 <= m <= 16, that can be used to
  protect arbitrary media streams along the lines defined by the
  FECFRAME framework.  Reed-Solomon codes belong to the class of
  Maximum Distance Separable (MDS) codes which means they offer optimal
  protection against packet erasures.  They are also systematic codes,
  which means that the source symbols are part of the encoding symbols.
  The price to pay is a limit on the maximum source block size, on the
  maximum number of encoding symbols, and a computational complexity
  higher than that of LDPC codes for instance.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-fecframe-simple-rs/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-fecframe-simple-rs/ballot/


No IPR declarations have been submitted directly on this I-D.

Needs milestone:

AD review goes here:
Dear all,

Here is the AD review of draft-ietf-fecframe-simple-rs-03.

In general, it is a good document and I have only a few places where I have questions, comments, or suggestions for changes.

- Section 3.1, on page 6, it says:
  FEC Source Packet:  At a sender (respectively, at a receiver) a
      payload submitted to (respectively, received from) the transport
      protocol containing an ADU along with an Explicit Source FEC
      Payload ID (that MUST be present in the FEC scheme defined by the
      present document, see Section 5.1.2).

The definition is ok, I just wonder why there is normative text here, i.e., the 'MUST'. I would change the MUST to must, as the normative part is anyhow stated in Section 5.1.2

- Section 3.3:
I would add the abbreviations ADUI and SBN for completeness to this list.


- Section 4.2.
Replace:
  Two kinds of limitations MUST be considered, that impact the ADU

With
  Two kinds of limitations MUST be considered that impact the ADU
                                            ^

No comma in front of 'that'.


- Section 4.2, page 8, bullet list:

  Two kinds of limitations MUST be considered, that impact the ADU
  block creation:
  o  at the FEC Scheme level: the finite field size (m parameter)
      directly impacts the maximum source block size and the maximum
      number of encoding symbols;
  o  at the FECFRAME instance level: the target use-case MAY have real-
      time constraints that MAY define a maximum ADU block size;

The usage of MUST (in capital letters) is not not correct in this place. The text is giving guidance to the implementer, but does not say how must interpret the text to implement the protocol.
The same holds true for the MAY in the 2nd bullet. I propose to change the text to this, also the usage of 'may' indicates a permission but not the ability to do something:
  o  at the FECFRAME instance level: the target use-case can have real-
      time constraints that can/will define a maximum ADU block size;

- Section 5.1.1.2, bottom of page 12, and also Figure 3, about the base64 encoding:
- Is it worth noting that this information must potentially be padded?
- Please add a reference to Figure 3 in the text starting with "If another" to make the link to the figure clear.

- Section 5.2, the bullet list at the beginning of this section:
Is there anything in this list, e.g., SBN values are set to zero in the beginning, that is mandatory? If yes, then the normative language is missing.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? Why is
this the proper type of RFC? Is this type of RFC indicated in the
title page header?

RFC proposed standard due to wg consensus. The title page indicates
Standards Track.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

This specification describes a fully-specified simple FEC scheme for
Reed-Solomon codes over Galois Field(2^^m), with 2 <= m <= 16, that
can be used to protect arbitrary media streams along the lines defined
by the FECFRAME framework.

Working Group Summary

There is consensus within the FECFrame WG to publish this document.
The document has been actively discussed on the wg list and in wg
meetings. There was no controversy with the progression of this
document.

Document Quality

Are there existing implementations of the protocol? Have a
significant number of vendors indicated their plan to implement the
specification? Are there any reviewers that merit special mention as
having done a thorough review, e.g., one that resulted in important
changes or a conclusion that the document had no substantive issues?
If there was a MIB Doctor, Media Type or other expert review, what was
its course (briefly)? In the case of a Media Type review, on what date
was the request posted?

No Implementations.

Who is the Document Shepherd? Who is the Responsible Area Director?

Greg Shepherd is the document shepherd and Martin Stiemerling is the
responsible Area Director.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd. If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

I read the document. The AD read the document. The WG has read the
document. It has been successfully run through idnits. This version of
the document is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

I have no concerns.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

No.

(6) Describe any specific concerns or issues that the Document
Shepherd has with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he or she is
uncomfortable with certain parts of the document, or has concerns
whether there really is a need for it. In any event, if the WG has
discussed those issues and has indicated that it still wishes to
advance the document, detail those concerns here.

No concerns.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP
78 and BCP 79 have already been filed. If not, explain why.

Yes. There is no IPR.

(8) Has an IPR disclosure been filed that references this document? If
so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No IPR.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

There is solid WG consensus behind the document. It has undergone
thorough review within the AVT and FEC communities. The document has
been actively discussed on the WG mailing list and in WG meetings.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarize the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the
Internet-Drafts Checklist). Boilerplate checks are not enough; this
check needs to be thorough.

No nits.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

We had several FEC experts review the draft throughout the process.

(13) Have all references within this document been identified as
either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready
for advancement or are otherwise in an unclear state? If such
normative references exist, what is the plan for their completion?

All normative references are to completed work.

(15) Are there downward normative references references (see RFC
3967)? If so, list these downward references to support the Area
Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are
not listed in the Abstract and Introduction, explain why, and point to
the part of the document where the relationship of this document to
the other RFCs is discussed. If this information is not in the
document, explain why the WG considers it unnecessary.

No, publication of this document will not change the status of any
existing RFCs.

(17) Describe the Document Shepherd's review of the IANA
considerations section, especially with regard to its consistency with
the body of the document. Confirm that all protocol extensions that
the document makes are associated with the appropriate reservations in
IANA registries. Confirm that any referenced IANA registries have been
clearly identified. Confirm that newly created IANA registries include
a detailed specification of the initial contents for the registry,
that allocations procedures for future registrations are defined, and
a reasonable name for the new registry has been suggested (see RFC
5226).

IANA considerations are clear and detailed.

(18) List any new IANA registries that require Expert Review for
future allocations. Provide any public guidance that the IESG would
find useful in selecting the IANA Experts for these new registries.

No expert review necessary.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

Not applicable