I have been selected as the General Area Review Team (Gen-ART) reviewer
for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-rmt-bb-fec-ldpc-06.txt
Reviewer: Brian Carpenter
Review Date: 2007-10-17
IETF LC End Date: 2007-10-22
IESG Telechat date: (if known)
Summary: Almost ready, two concerns
Comments:
I have one technical and one IPR concern.
Technical:
4.2.3. Scheme-Specific Elements
The following elements MUST be defined with the present FEC Scheme:
o G: a non-negative integer indicating the number of encoding
symbols per group (i.e. per packet). The default value is 1,
meaning that each packet contains exactly one symbol. Values
greater than 1 can also be defined, as explained in Section 5.3.
o PRNG seed: the seed is a 32 bit unsigned integer between 1 and
0x7FFFFFFE (i.e. 2^^31-2) inclusive. This value is used to
initialize the Pseudo Random Number Generator (Section 5.6). This
element is optional. Whether or not it is present in the FEC OTI
is signaled in the associated encoding format through an
appropriate mechanism (Section 4.2.4). When the PRNG seed is not
carried within the FEC OTI, it is assumed that encoder and
decoders use another way to communicate the information, or use a
fixed, predefined value.
At first sight, the word "optional" conflicts with "MUST be defined."
If I understand the intent correctly, this would be better expressed as
something like
This element MAY be present in the FEC OTI... If the PRNG seed
is not carried within the FEC OTI, the encoder and decoders
MUST use another way...
However, if this is a correct description of the intention, I believe it
leaves the way open for interoperability issues. It means that encoders
and decoders from different implementers might be incompatible. This would
scrape past in an Experimental protocol but seems wrong in a Proposed Standard.
Shouldn't all implementations be obliged to support transmission of the
seed in the FEC OTI, as a "MUST implement, MAY configure" feature?
IPR:
There are code extracts in the draft. There is also a statement in
the Introduction that
A publicly available reference implementation of these codes is
available and distributed under a GNU/LGPL license [8].
I believe it would be desirable to add an explicit statement that
the code extracts in the draft are directly contributed to the IETF
process by their authors (i.e., they are are not subject to LGPL).
Nits:
=====
id-nits finds reference errors:
== Outdated reference: draft-ietf-rmt-fec-bb-revised has been published as
RFC 5052
== Outdated reference: A later version (-04) exists of
draft-ietf-rmt-flute-revised-03
== Outdated reference: A later version (-05) exists of
draft-ietf-rmt-pi-norm-revised-04_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
