Forward Error Correction (FEC) Building Block
draft-ietf-rmt-fec-bb-revised-07

[Ballot discuss]
Reference [7] should point to the specification for SHA-1, but is says:
  >
  > [7]  Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
  >      April 1992.

  The belated discussion of Elwyn Davies' Gen-ART Review comments do
  not seem to have reached closure.  However, the authors have agreed
  that some document changes are needed.

[Ballot comment]
As noted in the writeup, the current version does not differ
significantly from RFC 3452. The changes do not appear to impact
the security considerations, and the document repeats the security
considerations from RFC 3452.  Since the document was previously
approved with these security considerations, I am entering this
as a comment rather than a discuss.

However, I am uncomfortable with the first sentence in the security
considerations section:
  "Data delivery can be subject to denial-of-service attacks by
  attackers which send corrupted packets that are accepted as
  legitimate by receivers.

While it is true that data delivery without authentication "can be subject
to denial-of-service attacks", there can be other consequences as well.
RFC3453 says "[b]y injecting corrupted encoding symbols, they are
accepted as valid encoding symbols by a receiver, which *at the very least*,
is an effective denial of service attack."  (My emphasis on "at the very least".)
It would be nice if the security considerations addressed some of the other
potential consequences!

[Ballot discuss]
Please replace references to MD5 with references to SHA-1 or SHA-256.

  The belated discussion of Elwyn Davies' Gen-ART Review comments do
  not seem to have reached closure.  However, the authors have agreed
  that some document changes are needed.

[Ballot comment]
Section 1., paragraph 1:
>    This document is a
>    product of the IETF RMT WG and follows the general guidelines
>    provided in [5].

  We don't typically mention which WGs have produced documents.


Section 2., paragraph 3:
>    It was the stated intent of the RMT working group to re-submit this
>    specification as an IETF Proposed Standard in due course.

  We don't typically talk about intentions of WGs or people in our
  documents.


[Editing nits sent to the authors directly.]

[Ballot discuss]
Author's need to respond to comments sent by Gen-Art review:

Document: draft-ietf-rmt-fec-bb-revised-06.txt
Reviewer: Elwyn Davies
Review Date:  11 April 2007
IETF LC End Date: 12 April 2007
IESG Telechat date: (if known) -

Summary:
Almost ready for PS.  There are some minor issues and editorial nits that should
be addressed before it goes to the IESG.

Comments:

Minor Issues:
s6:  As well as data packets, para 1 introduces session-control and
feedback packets, but then para 4 says that we are specifying stuff
about data packets.  Session-control and feedback packets disappear into
the void.  Some words about what is or is not specified about these
other kinds of packets would help - even if only to say they are out of
scope.

s6.1:  The implication of the last para is that an 8 bit field is enough
to hold the FEC Encoding ID (confirmed more or less in 6.2.3).  2 * 128
possible values may be enough but given that proprietary schemes are
allowed and lots of different CDPs might have different schemes, one
wonders if this might be constraining - and I see no means of expanding
the range. Justify?  Also there isn't an experimental range.

s6.2.1, para 4: Make it explicit whether the choice of (a) or (b) for
the encoding is allowed to be per object or per CDP/FEC Scheme.  Even
though it is probably obvious, it would be wise to state that if there
is an option the CDP has to provide means to transmit which choice has
been made.

s6.2.1, last para: The statements about the length of the field read as
if there has been previous statements about the length of Common Object
encodings.  There hasn't been.  Either reword to cover all lengths here
or add words to the earlier paragraphs about the Common Objects.

s6.3:  I would have expected (I think) that a maximum range for FEC
Payload IDs should be given to give a hint to CDPs on the field size
needed, but I may be wrong - perhaps some words of explanation as to why
it is not needed (if that is the case) would help others.

s11: Should we still be, even indirectly, suggesting that MD5 would be a
suitable hash functtion?

Editorial
=========
Global: s/[Aa]n FEC/[Aa] FEC/ (OK, maybe an sounds more euphonious but
it is wrong).  I'm sure the RFC Editor will have a view.

Global: Prefer octet rather than byte.

s1: It would be good to explicitly state the section (4.2 I assume) of
RFC 3048 ([10]) which this draft covers.

s1: Worth expanding RMT for future generations (or remove the note about
the wg that produced it).

s1, para 6: Helpful to add a forward ref to s4 or s6.1 where
Fully/Under-Specified are defined.

s4, para 1:  'A FEC code is a valuable component...':  I am not sure if
this the best phraseology.  Maybe: A FEC coding scheme is a valuable
component...  Actually I found the term 'FEC code' somewhat distracting
throughout - it doesn't sound quite right when referring to the adjuncts
needed to provide the extra FEC information and the encoding used to
generate them.

s4, para 4: s/ancilliary/anciliary/ (last instance)

s5, para 1: Might be good to refer explicitly to s3.2 of RFC 2357.


s6.1, para 5: s/FEc/FEC/

s6.2.2, paras 2 and 3:  It would be better to start these paras with
'Any' rather than 'The'.  At present it is very easy to read paras 2 and
3 as contradictory.

s6.2.4, last para: s/EXT-FTI/EXT_FTI/.  Also need to expand LCT acronym.

s6.3, last para:  The term 'systematic FEC codes' appears to be a term
of art that is not defined.  Explanation would be appreciated.

s11: s/to many receivers/at many receivers/

IANA Additional Comments:

Upon approval of this document, the IANA will perform
the following actions:

Action 1:

Update the references to the registry "Reliable
Mutlicast Transport (RMT) FEC Encoding IDs and FEC
Instance IDs" on the IANA assignments page located at
http://www.iana.org/numbers.html

The old references are:

Encoding ID's RFC3452 RFC required (section 8.1)
Instance ID's RFC3452 FCFS (section 8.1)

The new references are:

Encoding ID's RFC-rmt-fec-bb-revised-06 IETF Consensus
(section 12.1)
Instance ID's RFC-rmt-fec-bb-revised-06 FCFS (section 12.1)


Action 2:

Update the reference in the registry "Reliable
Mutlicast Transport (RMT) FEC Encoding IDs and FEC
Instance IDs" located at

http://www.iana.org/assignments/rmt-fec-parameters


The old reference was:

RMT FEC Encoding IDs and FEC Instance IDs - per [RFC3452]

The new reference will be:

RMT FEC Encoding IDs and FEC Instance IDs - per [RFC-rmt-fec-bb-revised-06]


We understand the above to be the only IANA Actions
for this document.
--

[ NOTE: This document does not mention the name of the existing
registry. The document should get updated to state the name of the
registry, "Reliable Mutlicast Transport (RMT) FEC Encoding IDs and FEC
Instance IDs". ]

IANA Last Call Comments:

Upon approval of this document, the IANA will perform
the following actions:


Action 1:

Upon approval of this document, the IANA will create
the following registry "Forward Error Correction (FEC)
Encodings" located at

http://www.iana.org/assignments/TBD
Initial contents of this registry are two subregistries
(see Actions 2 and 3).
[RFC-rmt-fec-bb-revised-06]


Action 2:

Upon approval of this document, the IANA will in
the following registry "Forward Error Correction
(FEC) Encodings" create a new sub-registry
"ietf:rmt:fec:encoding"
[RFC-rmt-fec-bb-revised-06]

Initial contents of this sub-registry will be:

Value Name Reference
[0-255]
------- ---- ---------
[0-127] Reserved to IANA [RFC-rmt-fec-bb-revised-06]
for Fully-Specified
FEC Schemes
[128-255] Reserved to IANA [RFC-rmt-fec-bb-revised-06]
for non-Fully-Specified
FEC Schemes

Action 3:

Upon approval of this document, the IANA will in
the following registry "Forward Error Correction
(FEC) Encodings" create a new sub-registry "ietf:rmt:fec:encoding:instance"
[RFC-rmt-fec-bb-revised-06]
Initial contents of this sub-registry will be:

Encoding Value Instance Number Name Contact Reference
[128-255] [0-65535]
-------------- --------------- ---- ------- ---------
[0-127] Invalid
[RFC-rmt-fec-bb-revised-06]
[128-255] [0-65535] Reserved to IANA
[RFC-rmt-fec-bb-revised-06]


We understand the above to be the only IANA Actions
for this document.

PROTO Write-up

(1.a) Document Shepherd is Lorenzo Vicisano, who has personally
reviewed this version of the document and believes it is ready
for forwarding to the IESG for publication.

(1.b) The document had adequate review both from key WG members
and from key non-WG members. An earlier version of this
document was approved as Experimental RFC 3452. The rationale for
resubmitting this document as Proposed Standard is described at the
end of Section 1 of the document.

(1.c) No additional reviews needed.

(1.d) The Document Shepherd does not have any concerns or issues
with this document.

(1.e) This document represent a solid consensus of the RMT WG. Most
of the rest of the RMT WG specifications use this document as a
fundamental building block.

(1.f) No notable discontent has been reported about this document.

(1.g) The Document Shepherd has personally verified that the document
satisfies all ID nits.

(1.h) The document has split its references into normative and
informative. All Normative references are in "BCP" state.

(1.i) The Document Shepherd has verified the document IANA
consideration section that is consistent with the body of the
document. The document creates new registries and defines allocation
procedures for future dependent registries. Reasonable names are
suggested. Note: this document takes over the registries already
defined through RFC 3452. All values assigned under the RFC 3452
registries are compatible with the current specification an should be
preserved.

(1.j) The documents contains no section written in formal language.

(1.k) Document Announcement Write-Up follows.

Technical Summary

This document describes how to use Forward Error Correction (FEC)
codes to efficiently provide and/or augment reliability for data
transport. This document defines a framework for the definition of
the information that needs to be communicated in order to use an FEC
code for delivering content, in addition to the encoded data itself,
and for definition of formats and codes for communication of that
information.

The procedures for specifying new FEC codes, defining the information
communication requirements associated with those codes and registering
them with the Internet Assigned Numbers Authority (IANA) are also
described.

This document is a building block upon which other specification of
the RMT WG are based.

Working Group Summary

There is consensus in the WG to publish these documents.

Document Quality

A previous version of this document was reviewed by the IESG and
published as RFC 3452. The current version does not differ
significantly from RFC 3452 and it allows backward compatible
implementation of known protocols that used RFC 3452.

The content of this document is the base for a number of existing
protocol implementations, both complying to this version of the
document and to the previous version documented in RFC 3452. There
are multiple independent implementations of 2 different protocols,
known as NORM and ALC, that use the specification in this document.
Different implementations of each protocols are interoperable.

ALC is also adopted in the 3GPP standard TS26.346.

Lorenzo Vicisano is the Document Shepherd.