Subject: [nwcrg] Fwd: [irsg] Submission of draft-irtf-nwcrg-network-coding-taxonomy for IRSG last call

From: Vincent Roca <[email-masked]>
Date: Wed, 10 Jan 2018 15:43:32 +0100

Dear All,

FYI we received mid-November detailed comments from Laurent C. during the IRSG (the steering group of IRTF) last call review.
You’ll find it below.

We co-authors have started addressing them in a new I-D version. Of course everybody is welcome to participate to this process.
If you want to suggest improvements/new definitions/modifications/whatever, do not hesitate.
You can either send comments to the list and/or add a comment in the Google Drive document that we, co-authors, are using.
In the latter case, ask me and I’ll give you write privileges to the doc.

You’ll find the current version (-05), used during this IRSG last call, here:
	https://datatracker.ietf.org/doc/draft-irtf-nwcrg-network-coding-taxonomy/ <https://datatracker.ietf.org/doc/draft-irtf-nwcrg-network-coding-taxonomy/>

I also take advantage of this occasion to wish you all a happy new year.
Cheers,

  Vincent

> De: "Ciavaglia, Laurent (Nokia - FR/Nozay)" <[email-masked]>
> Objet: RE: [irsg] Submission of draft-irtf-nwcrg-network-coding-taxonomy for IRSG last call
> Date: 15 novembre 2017 à 04:17:42 UTC+1
> À: Vincent Roca <[email-masked]>
> Cc: "Internet Research Steering Group ([email-masked])" <[email-masked]>, Marie-Jose Montpetit <[email-masked]>
> 
> Dear Vincent,
>  
> Below you may find my review of draft-irtf-nwcrg-network-coding-taxonomy.
>  
> Overall, the document provides solid technical definitions and in that respect achieves its objective.
>  
> Best regards, Laurent.
>  
> ---
> Comments:
>  
> List of authors.
> -The current practice lists the editors in the header, and authors/contributors at the end of the document, especially when there are many authors.
> -I remember you’ve discussed this point with Lars previously.
>  
> Abstract.
> -Suggest changing to “in future IRTF and IETF documents on Network Coding”.
> -Suggest changing to “This document is in-line with the terminology used by the RFCs produced...”. If you have written the document to be compliant, then simply state it. (same applies for the same statement in the introduction).
>  
> Introduction.
> -“well-attended audio conferences, each of them gathering 6 to 8 participants”. Maybe 6-8 participants is not always understood as “well-attended”. You may rephrase to state that key experts were involved in all audio conferences 
> -What does “openly co-edited” refer to?
> -Suggest changing “The general feeling was that the document was ready for next step” to a more assertive sentence e.g.  change “general feeling” for decision or conclusion.
> -End of paragraph 2: what’s the criteria for order of the reference (importance)? Why not ascending order?
> -Paragraph 3 is difficult to read and understand. Prior context is lacking, it gets too directly into details of network coding assumptions without giving the reasons/motivations.
> -Paragraph 3, “for instance because of congested routers, routing issues, intermittent connectivity (e.g., a mobile terminal can suddenly go behind an obstacle) and wireless communication issues.” seems to provide very detailed example in stark contrast to the rather “abstract” description at the beginning of the paragraph. A better balance might be feasible.
> -Paragraph 3, “Communications may happen in various types of networks”. Maybe referring to different layers in the stack would be more accurate (as stated later in the paragraph).
> -Paragraph 3, it can be confusing to that the packet may be UDP datagram when the coding is done in transport protocol on top of UDP.      Wouldn’t the layer of coding be the “transport protocol on top of UDP” instead of “UDP” in that case?
> -Paragraph 3, “This document does not try to be exhaustive” somewhat contradicts the statement in the introduction that the document provides “a comprehensive set of terms”.
> -Paragraph 6, suggest to state more simply that both (Intermediate) network coding and end-to-end coding are in scope of the document. The first may be kept and placed at the end of the paragraph.
>  
> Section 2.
> -A simple definition of network coding would be useful.
> -The first two definitions refer to error channels and error correction codes. However without a proper definition (even if out of scope), it is more difficult to understand well the difference, especially for a non-expert and because . Providing simple definition might help ; without making error channels / correction codes in scope, the terms will just be defined to facilitate understanding which is especially important in a terminology document.
> -What is a “communication facility” in definition 1?
> -Definitions for packet and symbol might be added, as mentioned in description of Figure 1: “packets (what is sent in the Packet Erasure Channel) and symbols (what is manipulated during encoding and decoding operations), which are good and simple definitions.
> -Suggest adding “reverse” to the sentence “A similar figure could be done for FEC decoding.”
>  
> Section 3.
> -Suggest to change “(see Fig. Figure 2)” to “(see Figure 2)”.
> -Definition 1, the part of the sentence mentioning the physical layer might create confusion whether physical layer coding is really out of scope as stated in the Introduction.
>  
> Section 4.2.
> -“ Rank of a Payload Set, or (IETF) Rank of the Linear System:  At a rec-eiver,” the word ‘receiver’ is cut in the middle.
>  
> Section 4.3.
> -“ Payload Indices, or (IETF) Encoding Symbol Identifiers (ESI):  An ide-ntifier”, the word ‘identifier’ is cut in the middle.
>  
> Appendix B.
> -Correct “work that involved may authors and contributors” --> ‘many’ authors
> -Suggest changing ”the NWCRG IRTF research group.” to “the IRTF NWCRG”, as RG stands already for research group.
>  
> ---