Re: [nwcrg] Symbol representation draft updated

[Salvatore Signorello <[e-mail]>]

Dear Heide and other authors,

thank you very much for working on the new draft. Follow some more 
comments from my side. Apologies in advance if I miss something, still 
this area is pretty new to me.

- /"Coding coefficient vector"/ (a) vs /"coding vector"/ (b). Both terms 
are used interchangeably throughout both the RLNC-background and the 
symbol-representation drafts. More precisely, in the background draft 
(a) is used 6 times, while (b) only 4. In the symbol-representation 
draft, (a) is used 19 times, while (b) only 7. I am sorry if this 
re-opens a similar previous thread, but my feeling is still that 
converging towards a single term (where possible) would smooth the 
reading and avoid any unnecessary confusion. Assuming both (a) and (b) 
meant the same thing, I would opt for (a) which is already defined on pp 
3 of the background draft, considering (b) is never defined. While, if 
anywhere (a) and (b) meant different things (for example, like I wrote 
in our previous exchange respectively non-wire and wire representation 
of the coefficients), I would state that down somewhere in the drafts.

- Sec. 2.1, representation Setup: "and where subsequent coding vectors 
are deduced from the first *one*", I fear that is not clear which *one*, 
do you mean the symbol or the coding vector or yet the seed?

- Sec. 2.2, field ENCODER RANK: the last bullet point /"Coded 
symbols....in the coded symbols(s)" /sounds to me more like the general 
field definition rather than a specific property. So, I would expect 
that to be included into the field description at the beginning. For 
example, like this:

/"ENCODER RANK represents the current rank of the encoder, that is, the 
number of original symbols included in the coded symbols(s). It has the 
following properties:"/

btw, I am not sure /included /was the best choice here, I would like to 
see something like /"used to compute" /instead.

- Sec. 2.2, field SEED: the last bullet point /"In the case where no 
random generator....by setting the TYPE flag to '3'" /sounds to me more 
like a description/purpose of having different formats rather than a 
property of this field. Indeed, this subsection is called "Field Types 
and Formats", but it only explains the fields. You say sth about the 
formats in the "Representation setup" section, where, imho, it could be 
the place where to explain the supported formats and then only quickly 
refer to them when needed to explain the related fields in Sec. 2.2.

- Sec. 2.2., field CODING COEFFICIENTS: in the last bullet point, you 
use for the first time /"a predetermined field size", /I am not sure it 
is clear that refers to a negotiated coding parameter. So, may be, you 
could either refer to the background document or to the sec. 2.3. or 
simply to remove this second part of the sentence /"each coding 
coefficient having a predetermined field size"/

- Sec. 2.3, I understand the point that the following two sentences aim 
to make /"Typically these parameters will be static throughout  the 
instantiation of a protocol and can therefore be globally defined.  
Consequently, there is little to gain by incorporating these parameters 
into the representation but conversely it would add additional 
overhead"/,  however it looks to me like this paragraph might need some 
rephrasing. W.r.t. the first sentence, I would at least change 
"throughout the instantiation" with "at the initialization", since I 
guess that mostly refers to the possible initialization of a protocol 
session, or yet with "throughout a protocol session" . By consequence, I 
am not sure that "globally defined" is appropriate either since that 
would only refer to the involved parties.

- some times /generation/window size/ is written in lower case (e.g., in 
Sec 2.3), some others in upper case (e.g., representation setup). Is 
this intended?


Finally, two typos in Sec. 2.3. : {instantitaion, incorperating}


I hope the above comments help. Once again, thank you very much for 
producing this document.

Regards,

Salvatore

On 11/07/19 14:34, Janus Heide wrote:
> All,
>
> A new version of the symbol representation draft have been uploaded.
>
> Thanks for comment received verbally at the meeting and in writing on 
> the list. In particular thanks to Salvatore for his detailed comments 
> and the subsequent discussion.
>
> One comment received was that figures 8,9,10 could be removed, if we 
> could here some inputs to whether these are worth keeping or should be 
> omitted that would be helpful, thanks.
>
>
> https://datatracker.ietf.org/doc/draft-heide-nwcrg-rlnc/
>
> https://www.ietf.org/rfcdiff?url1=draft-heide-nwcrg-rlnc-01&url2=draft-heide-nwcrg-rlnc-02&difftype=--html 
>
>
> Best Janus
>
> _______________________________________________
> nwcrg mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/nwcrg