Re: [nwcrg] RG Last Call for "Network Coding for Content-Centric Networking / Named Data Networking: Considerations and Challenges"

[Vincent Roca <[e-mail]>]

Dear authors, all,

Please find below my review of the I-D, version -04 (sorry for the very long delay).
Nothing serious, the I-D is in my opinion reasonably sound, but that’s something
that should be confirmed with ICNRG.

Regards,

  Vincent


# Formal requirements (easy to fix)

- missing text in the abstract:
   This document is the product of the Coding for Efficient Network
   Communications Research Group (NWCRG) and the Information-Centric Networking Research Group (ICNRG).

- missing text in the Introduction:
   This document represents the collaborative work and consensus of the
   Coding for Efficient Network Communications Research Group (NWCRG) and
   the Information-Centric Networking Research Group (ICNRG).
   It is not an IETF product and is not a standard.


# Open questions

- section 6.1:
I am a bit surprised by the proposed format:
        /CCNx.com/video-A/g-id/1000
for naming as it totally ignores any possibility of having several potential codes, or several signaling formats.
Since there is no NWC identifier nor any version identifier, it seems to lack the needed flexibility.
I'm pretty sure there are several solutions to bring this type of flexibility, but I don't see any mention in the ID.

- section 8: "Security considerations"
I'm a bit surprised by the 2nd paragraph on storing coded packets.
I can understand that these packets, being unpopular, are less frequently cached, and therefore propagation of
a corrupted coded packet may be particularly efficient in terms of spreading.
Yet I don't understand what follows:
        "routers could check the request frequencies and store the coded
        packets with certain popularity to prevent the attacks."
We cannot prevent the attack. We can try to minimise its impacts by reducing the number of times a corrupted
coded packet will be replicated. But that's totally different.
And I find the process rather strange and unefficient. Why should a router artificially store less popular packets?


# Typos and minor comments

- I'm wondering if NWC would be preferable to NC to refer to "network coding". The RG uses NWC for some historical
  reasons, but I personnally prefer NC.

- error in [3]: Mdard => Medard

- section 2.1: s/an real-time transport/a real-time transport/

- section 3: s/the interest is required to a full name/the interest is required to carry a full name/

- section 6.1: s/such as the on presented above/such as the one presented above/

- section 6.2.1: it is said:
        "encoding or recoding is performed to generate the coded packet on an end-to-end coding basis"
  I don't understand the meaning of "recoding" if we only perform end-to-end coding. I guess it's either
  a mistake, or the notion of "end" is different.

- section 6.2.2: not sure about the use of "codec" in: "return a matching codec packet". Coded?

- section 6.2.3: s/how to respond to receiving interests/how to respond to received interests/

- section 7.2: s/The Addition/The addition/
        Additionally, a reference to draft-irtf-nwcrg-coding-and-congestion is unavoidable here.

- section 7.3: s/would comprises/would comprise/



> Le 7 sept. 2020 à 16:16, Vincent Roca <[e-mail]> a écrit :
> 
> Dear all,
> 
> We would like to officially start a RG Last Call for the following I-D:
> 	"Network Coding for Content-Centric Networking / Named Data Networking: Considerations and Challenges »
> 	https://datatracker.ietf.org/doc/draft-irtf-nwcrg-nwc-ccn-reqs/ <https://datatracker.ietf.org/doc/draft-irtf-nwcrg-nwc-ccn-reqs/>
> 
> This Last Call is managed by NWCRG but is copied to the ICNRG group as well.
> 
> The call will end on Monday Sept. 28th (3 weeks).
> 
> Please read it and provide feedback to the authors (note that it already went through several reviews). Thanks in advance.
> 
> Regards,
> 
>     Marie-Jose and Vincent