Dear Brian,
Thanks a lot for these comments.
-------
1- Concerning your technical comment for section "4.2.3. Scheme-Specific
Elements":
You are right, the wording is clumsy.
> 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...
Your understanding is correct.
>Shouldn't all implementations be obliged to support transmission of the
>seed in the FEC OTI, as a "MUST implement, MAY configure" feature?
Our motivation to make the explicit transmission of the seed optional was to
save 32 bits when this FEC OTI is carried within an EXT_FTI header extension
(potentially included in many packets, depending on the developer's choice).
There is of course a risk that independent developers disagree and use
different seed values when this latter is carried out-of-band.
Solving this potential issue requires to use a "MUST implement and MUST
configure" (rather than "MAY configure" which does not solve any problem).
This is also a good incentive to use the EXT_FTI more intelligently...
==> We will correct it.
-------
2- Concerning the IPR comment:
==> we suggest to add the following sentence:
"The code extracts in this document are directly contributed to the IETF
process by their authors, unless otherwise mentionned."
This restriction is required when we (I-D authors) don't own the copyright
of the source code, and therefore cannot contribute it to the IETF. This is
the case for:
- 5.6. Pseudo Random Number Generator
- 6.2. Parity Check Matrix Creation
In the above two sections, the origin of the source code is clearly stated.
** The PRNG source code is public domain:
http://www.firstpr.com.au/dsp/rand31/rand31-park-miller-carta.cc.txt
Other __compatible__ PRNG implementations of the same algorithm exist anyway.
** The Parity Check Matrix generator is (as we explain) copyright by Radford
Neal.
The licence is the following:
http://www.cs.toronto.edu/~radford/ftp/LDPC-2001-11-18/index.html
"Permission is granted for anyone to copy, use, or modify these
programs and documents
for purposes of research or education, provided this copyright notice
is retained,
and note is made of any changes that have been made.
These programs and documents are distributed without any warranty,
express or implied.
As the programs were written for research purposes only, they have not
been tested to
the degree that would be advisable in any important application. All
use of these programs
is entirely at the user's own risk. "
==> We suggest to add this licence in the document too (currently there's only
the web site URL and Radford's copyright).
Regards,
Vincent, on behalf of the authors
Brian E Carpenter wrote:
>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
