Re: [nwcrg] I-D Action: draft-irtf-nwcrg-nwc-ccn-reqs-05.txt

Dear NWCRG and ICNRG members,

We believe we addressed the comments given during the LC
for our NWC-for-ICN draft. (Thanks, Vincent)
We've just submitted the revised draft. 
It's great if you can have a look.

Followings are our reply for the given comments.

Regards,

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.

We modified and added the new explanation of naming example (in 6.1
Content Naming) as below:
----
As in [10], when the generation ID is "g-id", generation size is 4, and
coding vector is (1,0,0,0), the name could be /CCNx.com/video-A/g-id/
1000. Some other identifiers and/or parameters related to the encoding
scheme can also be used as the name components. For instance, the
encoding ID specifying the coding scheme may be used with "enc-id" such
as /CCNx.com/video-A/enc-id/g-id/1000, as defined in the FEC Framework (
FECFRAME) [25]. This naming scheme is simple and can support the
delivery of coded packets with exactly the same operations in the PIT/CS
as those for the content objects.
----

2)
>- 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.

We simply removed "end-to-end coding basis" and modified as below:
----
In the latter case, encoding or recoding is performed to generate the
coded packet at any forwarder that is able to respond to the interest.
----

3)
>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?

We removed "prevent" and modified the related sentences to reflect the
comment (in Sec.8 2nd paragraph), as below:
----
Depending on the adopted caching strategy such as cache replacement
policies, routers should also take caution when storing and retaining
the coded packets in the CS as they could be targeted by cache pollution
attacks. In order to mitigate the cache pollution attacks' impact,
routers should check the content request frequencies to detect the
attack and may limit requests by ignoring some of the consecutive
requests. The routers can then decide to apply or change to the other
cache replacement mechanism.
----

> -------- Forwarded Message --------
> Subject: 	[nwcrg] I-D Action: draft-irtf-nwcrg-nwc-ccn-reqs-05.txt
> Date: 	Fri, 22 Jan 2021 17:52:22 -0800
> From: 	internet-drafts@ietf.org
> Reply-To: 	nwcrg@irtf.org
> To: 	i-d-announce@ietf.org
> CC: 	nwcrg@irtf.org
> 
> 
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Coding for efficient NetWork 
> Communications Research Group RG of the IRTF.
> 
> Title : Network Coding for Content-Centric Networking / Named Data 
> Networking: Considerations and Challenges
> Authors : Kazuhisa Matsuzono
> Hitoshi Asaeda
> Cedric Westphal
> Filename : draft-irtf-nwcrg-nwc-ccn-reqs-05.txt
> Pages : 23
> Date : 2021-01-22
> 
> Abstract:
> This document describes the current research outcomes in Network
> Coding (NC) for Content-Centric Networking (CCNx) / Named Data
> Networking (NDN), and clarifies the technical considerations and
> potential challenges for applying NC in CCNx/NDN. This document is
> the product of the Coding for Efficient Network Communications
> Research Group (NWCRG) and the Information-Centric Networking
> Research Group (ICNRG).
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-irtf-nwcrg-nwc-ccn-reqs/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-irtf-nwcrg-nwc-ccn-reqs-05
> https://datatracker.ietf.org/doc/html/draft-irtf-nwcrg-nwc-ccn-reqs-05
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-irtf-nwcrg-nwc-ccn-reqs-05
> 
> 
> Please note that it may take a couple of minutes from the time of 
submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> 
> _______________________________________________
> nwcrg mailing list
> nwcrg@irtf.org
> https://www.irtf.org/mailman/listinfo/nwcrg
> 