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

[Vincent Roca <[e-mail]>]

All,

FYI: I’ve just sent our updated version of the taxonomy I-D along with answers in response to comments
received during IRSG review.

If you want to understand the process, it’s explained here: https://trac.ietf.org/trac/irtf/wiki/IRTF-RFCs <https://trac.ietf.org/trac/irtf/wiki/IRTF-RFCs>
Basically:
- We are at the end of the « IRSG review » process.
- If Laurent C. agrees with the way we addressed his comments, we’ll then enter the « IRSG Poll » status.
- After that, if IRSG agrees to go further, there will be the « IESG review ».
- And finally RFC Editor work (final editorial work)
And we’ll be done.
The process is pretty serious but it also represents a lot of work to a lot of people, and not only to authors.
We need to be grateful to them.

Cheers,

     Vincent


> De: Vincent Roca <[e-mail]>
> Objet: Rép : [irsg] Submission of draft-irtf-nwcrg-network-coding-taxonomy for IRSG last call
> Date: 1 février 2018 à 17:05:29 UTC+1
> À: "Ciavaglia, Laurent (Nokia - FR/Nozay)" <[e-mail]>
> Cc: Vincent Roca <[e-mail]>, "Internet Research Steering Group ([e-mail])" <[e-mail]>, Marie-Jose Montpetit <[e-mail]>
> 
> Dear Laurent,
> 
>> Below you may find my review of draft-irtf-nwcrg-network-coding-taxonomy.
> 
> Thanks a lot for your valuable comments and sorry for the long delay addressing them.
> 
> So, we have finally updated our I-D. The new version is available at:
> 	https://datatracker.ietf.org/doc/draft-irtf-nwcrg-network-coding-taxonomy/ <https://datatracker.ietf.org/doc/draft-irtf-nwcrg-network-coding-taxonomy/>
> and here is the diff with version -05 that you reviewed:
> 	https://www.ietf.org/rfcdiff?url2=draft-irtf-nwcrg-network-coding-taxonomy-06 <https://www.ietf.org/rfcdiff?url2=draft-irtf-nwcrg-network-coding-taxonomy-06>
>  
>> Overall, the document provides solid technical definitions and in that respect achieves its objective. 
> 
> Thanks.
>  
>> ---
>> 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.
> 
> [authors] Perfectly right and what I answered to Lars on July still applies IMHO:
> “I know this is a lot of authors and a non usual situation. However this is not the first time it
> happens, see: https://datatracker.ietf.org/doc/rfc7933/ <https://datatracker.ietf.org/doc/rfc7933/>
> 
> We discussed this on the list and came to the conclusion this is the most appropriate option.
> I see two reasons for that:
> 	- as explained, this document has a long history and digging into mail archives to 
> 	  figure out who deserves to be author instead of contributor, based on her/his input, is
> 	  both not easy and also error prone. I want to avoid it;
> 	- given the group history, it’s a good sign to everybody that participating into common
> 	  activities is recognised as it should which is equally important in my opinion.”
> 
>> Abstract.
>> -Suggest changing to “in future IRTF and IETF documents on Network Coding”.
> 
> [authors] Done.
> 
>> -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).
> 
> [authors] Done.
> 
>> 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 
> 
> [authors] Done.
> 
>> -What does “openly co-edited” refer to?
> 
> [authors] We removed “openly”. Co-edited is sufficient.
> 
>> -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.
> 
> [authors] Done.
> 
>> -End of paragraph 2: what’s the criteria for order of the reference (importance)? Why not ascending order?
> 
> [authors] Done.
> 
>> -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.
> 
> [authors] Good point. We tried to simplify paragraph 3, removing useless examples. We also provide an explanation of the goals of network coding that was lacking (but do not try to justify each of the claims) extracted from our NWCRG charter.
> 
>> -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.
> 
> [authors] Many details have been removed to stay focus and keep a uniform level of details.
> 
>> -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).
> 
> [authors] Mostly removed.
> 
>> -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?
> 
> [authors] Good point, this is confusing. Done.
> 
>> -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”.
> 
> [authors] Good point. Removed.
> 
>> -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.
> 
> [authors] Done.
> 
> We rewrote most of this paragraph as follows.
> NEW:
> This document focuses on packet transmissions and packet losses.	
> These losses will typically be triggered by various types of	
> networking issues and/or impairments (e.g., congested routers or	
> intermittent wireless connectivity). The notion of "packet" itself	
> is multiform, depending on the target use-case and the notion of	
> network (e.g., in which layer of the protocol stack does the coding	
> middleware operate?). For instance, a "packet" may be a data unit to	
> be carried as a UDP payload because the coding middleware is located	
> between the application and UDP. In another configuration, coding	
> may be applied within an overlay network and the notion of "packet"	
> will be totally different. In any case the goals of Network Coding	
> can be to improve the network throughput, efficiency, latency, and	
> scalability, as well as providing resilience to partition, attacks,	
> and eavesdropping (NWCRG charter). Both End-to-End Coding and	
> systems that also perform re-coding within intermediate forwarding	
> nodes are considered in this document.
>  
>> Section 2.
>> -A simple definition of network coding would be useful.
> 
> [authors] We moved the two definition of Network Coding and End-to-End Coding in section 2.
> 
>> -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.
> 
> [authors] We tried to extend this definition for readers not familiar with error/erasure codes. We added details to clarify our point.
> 
>> -What is a “communication facility” in definition 1?
> 
> [authors] We removed this term and provided examples to clarify it.
> 
>> -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.
> 
> [authors] Done. We added a high level “Packet versus Symbol” definition before going further into source and repair packet or symbol definitions.
> 
>> -Suggest adding “reverse” to the sentence “A similar figure could be done for FEC decoding.”
> 
> [authors] Good point, done. 
> 
>> Section 3.
>> -Suggest to change “(see Fig. Figure 2)” to “(see Figure 2)”.
> 
> [authors] Done.
> 
>> -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.
> 
> [authors] Clarified.
> 
>> 
>> 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.
> 
> [authors] Strange error (xml2rfc bug?) since nothing in the original XML justifies this caesura that only appears in the txt version. There’s little we can do at this step however.
>  
>> Section 4.3.
>> -“ Payload Indices, or (IETF) Encoding Symbol Identifiers (ESI):  An ide-ntifier”, the word ‘identifier’ is cut in the middle.
> 
> [authors] Same phenomenon as above. No explanation.
> 
>>  
>> Appendix B.
>> -Correct “work that involved may authors and contributors” --> ‘many’ authors
> 
>  [authors] Done.
> 
>> -Suggest changing ”the NWCRG IRTF research group.” to “the IRTF NWCRG”, as RG stands already for research group.
> 
>  [authors] Done.
> 
> Cheers,
> 
>    Vincent, on behalf of the authors
>