[icnrg] Review of draft-irtf-nwcrg-nwc-ccn-reqs

["David R. Oran" <[e-mail]>]

ICNRG’ers:
We have a deadline coming up in two days to submit comments on this 
before NWCRG sends it to last call.

We will obviously have a chance to give further comments during last 
call since this is a joint RG document managed by NWCRG, but the sooner 
the better in order to have the document in the best possible shape 
coming out of RG last call.

Thanks!

DaveO

Forwarded message:

> From: Marie-Jose Montpetit <[e-mail]>
> To: David R. Oran <[e-mail]>, nwcrg <[e-mail]>, 
> icnrg <[e-mail]>
> Subject: Re: [icnrg] Review of draft-irtf-nwcrg-nwc-ccn-reqs
> Date: Fri, 13 Dec 2019 08:23:43 -0800
>
> Thank you for your comments.
>
> In order to push this draft to last call we will limit the further 
> comments
> to January 15 2020 to account for the upcoming Holidays.
>
> Marie-José/Vincent
>
>
> On December 7, 2019 at 8:55:36 AM, David R. Oran 
> ([e-mail])
> wrote:
>
> With <ICNRG Chair Hat On>
> A reminder to ICNRG’ers to please review this document soon, as the 
> NWCRG
> would like to progress to last call in the near future.
>
> With <ICNRG Chair Hat Off>
> Here are my comments as individual on draft-irtf-nwcrg-nwc-ccn-reqs. 
> They
> are divided into general, technical, and editorial/nits.
> General Comments
>
>    -
>
>    The document contains a lot of thought-provoking material, and is
>    technically sound in terms of its discussion of the issues and 
> tradeoffs..
>    Therefore, I think it’s appropriate to advance it now as it can 
> form the
>    basis to guide future research work and experimentation with the
>    combination of ICN and NWC.
>    -
>
>    While not a pre-condition to advancing this to RG last call in 
> NWCRG,
>    the writing does need a fair amount of work on clarity of English 
> language
>    exposition, grammar and usage. It would be very helpful if this 
> could be
>    done before sending it to IRSG review, as IRSG members are neither 
> NWC nor
>    ICN experts, and could very easily be left scratching their heads 
> in a
>    number of places.
>    -
>
>    The introductory tutorial material on ICN is appropriate to 
> level-set
>    for the NWC community, but there’s a need for an equivalent 
> tutorial
>    section on NWC to level set for the ICN community. Concepts like 
> “degrees
>    of freedom”, “innovative packets”, “RLNC”, don’t appear 
> in the (terse)
>    terminology list in the Definitions section. It might be good to 
> expand
>    this with more tutorial text.
>    -
>
>    There are a number of places where the document confounds security 
> with
>    privacy; these need to be clearly separated and the considerations
>    articulated.
>    -
>
>    A pass needs to be done to align the text here with the current RFC
>    status of CCNx. I have some specific comments on this in the 
> technical
>    comments below, but I may have missed some places so an overall 
> scrub ought
>    to be done, either now, or during RG last call.
>
> Technical Comments
>
>    -
>
>    In the second paragraph on page 8, you discuss the interaction of 
> the
>    naming scheme choices with forwarding, but don’t address which, 
> if any, of
>    the characteristics would necessitate a change to the semantic-free
>    matching currently done by CCNs and NDN, and/or the prefix match 
> semantics
>    of NDN versus exact match of CCNx. Instead you concentrate on the 
> size of
>    the TLV headers, which doesn’t seem to be a first-order problem.
>    -
>
>    Material touching on in-network recoding is scattered around in 
> various
>    places and probably ought to be consolidated or alternatively 
> summarized in
>    a section near the end to pull things together. One approach you 
> don’t
>    consider (but probably ought to) is exploiting multi-signature 
> capability
>    some signing schemes that would work with CCNx. This way you can 
> use
>    different signing keys for the original and coded packets, allowing 
> the
>    entities responsible for coding to be different from the authors of 
> the
>    original content. This way in-network recoding could be allowed by 
> giving
>    the signing keys for coded packets to routers - this would not 
> require them
>    to be trusted to maintain the integrity of the original data since 
> they
>    would not have the original signing keys.
>    -
>
>    In section 4.2.2 you bring up video streaming, and seem to have an
>    assumption that your network code is systematic rather than 
> non-systematic
>    (aside: another thing probably needing some material in the 
> introductory
>    section), further asserting that sequential delivery is important, 
> and
>    hence there’s some disadvantage to fetching coded packets first. 
> I had a
>    somewhat hard time following this, and unless I’m misreading your 
> logic, I
>    think it’s actually wrong since today’s streaming decoders 
> don’t care at
>    all about packet arrival order and need enough computing capacity 
> to decode
>    NWC packets within the playout deadline in order to work decently 
> anyway..
>    -
>
>    In the second paragraph of 4.3, you seem to be unaware that CCNx 
> has
>    exactly the feature you want for packets you don’t want to 
> cache.. The
>    producer just sets the RCT (Recommended Cache Time) to zero.
>    -
>
>    The discussion about whether routers need to decode and validate 
> coded
>    packets is a bit confused and I think actually wrong in some 
> places. There
>    are two issues. First, the text confounds cache pollution with 
> cache
>    poisoning; these are separate phenomena that need different
>    mitigation/avoidance approaches. Second, while you probably ought 
> to
>    discuss both, cache poisoning is pretty thoroughly addressed in the 
> current
>    CCNx design (less so in NDN) in a way that does *not* require 
> routers to
>    validate signatures on packets, or in the case of NWC, decode them.
>    -
>
>    I didn’t get the use of the term “virtual logical link” when 
> talking
>    about fetching content from multiple producer sites. None of the 
> transport
>    or congestion control schemes I’m familiar with for ICN use this 
> term, and
>    in fact I’m not sure the concept is at all useful in the context 
> of
>    multi-path/multi-destination forwarding in CCNx o NDN. Instead you 
> might
>    just reference existing work on multi-path/multi-destination 
> congestion
>    control and transport.
>    -
>
>    As the first sentence of a security considerations section, saying 
> “This
>    document does not impact the security of the Internet” is a big 
> red flag in
>    front of a bull. Get rid of it (see may editorial suggestion to 
> consolidate
>    all of the security and privacy material see rather than a separate 
> section
>    earlier).
>
> Editorial Comments & Nits
>
>    -
>
>    Need to do a global replace of CCN with CCNx.
>    -
>
>    Get rid of the first paragraph of section 2 and the normative 
> reference,
>    since this document doesn’t use any of the RFC2119 terminology.
>    -
>
>    Everywhere you say “seamless mobility” it needs to say 
> “seamless
>    *consumer* mobility”.
>    -
>
>    the second paragraph on page 7 (which begins “the CCN/NDN core
>    abstraction”) is really hard to follow. There’s also a 
> confounding between
>    what NDN cals the “Strategy layer” and 
> “specific…transport” since in NDN
>    forwarding strategy does not provide what are classically 
> considered to be
>    transport functions.
>    -
>
>    Section 4 probably should not be called “requirements” since 
> (a)this
>    document is not an appropriate vehicle for expressing NWC/ICN 
> integration
>    requirements, and (b)it doesn’t really state requirements, but 
> rather some
>    general technical considerations.
>    -
>
>    the first paragraph of section 4.1 is under naming, but talks 
> mostly
>    about fragmentation. Some re-organization might help by moving the
>    fragmentation issues to the end of 4.1 rather than the beginning.
>    -
>
>    page 8, second paragraph s/not be able to obtain degrees of 
> freedom/not
>    be able top obtain sufficient degrees of freedom/
>    -
>
>    Page 11, Section 4.3 Caching is *not* essential for improving 
> throughput
>    and latency. It’s useful, but not essential.
>    -
>
>    Given the paucity of material in section 4.5 on security and 
> privacy, it
>    might be better to just move this (and hopefully expand it a bit) 
> to
>    section 6 as a conventional security considerations section.
>
> [End of Comments]
>
> On 21 Nov 2019, at 0:47, David Oran wrote:
>
> This is joint work of NWCRG and ICNRG, managed out of NWCRG. It has 
> needed
> serious review from the ICNRG participants for quite some time, and at 
> this
> point our review is what is holding up its last call and progression.
>
> You can find the current version at
> https://datatracker.ietf.org/doc/draft-irtf-nwcrg-nwc-ccn-reqs/
>
> PLEASE review this and send comments to both the ICNRG and NWCRG 
> mailing
> lists.
>
> I would like to set a deadline of three weeks (December 13) after 
> which if
> no comments that need to be addressed prior to further advancement are
> received, I’ll advise the NWCRG chairs to proceed with RG Last call 
> in
> NWCRG.
>
> Thanks, and have a good trip home for those of you who joined us in
> Singapore.
>
> DaveO (for Dirk and Börje), ICNRG co-chairs.
>
>
> ___________________________
> iDevice - please excuse typos.
>
> _______________________________________________
> icnrg mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/icnrg
>
> DaveO
> _______________________________________________
> icnrg mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/icnrg


> _______________________________________________
> icnrg mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/icnrg