Re: [icnrg] FW: [irsg] IRSG Poll: draft-irtf-icnrg-challenges-03

Hi all,

At the interim starting tomorrow, we plan to discuss some of these issues, so if you plan to attend and participate in the discussion, the comments below would be excellent preparation material.

--
Dirk

> Am 04.01.2016 um 20:13 schrieb Dirk Kutscher <Dirk.Kutscher@neclab.eu>:
> 
> Dear all,
> 
> during the IRSG poll for the challenges draft we received this extensive review from Stephen, which I found quite useful, so I'd like to share it and also give people a chance to discuss it.
> 
> The result of this discussion would be reflected by the authors in a potential update of the document.
> 
> Cheers,
> Dirk
> 
> 
>> -----Original Message-----
>> From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie]
>> Sent: Donnerstag, 24. Dezember 2015 21:07
>> To: Dirk Kutscher; Internet Research Steering Group (irsg@irtf.org)
>> Subject: Re: [irsg] IRSG Poll: draft-irtf-icnrg-challenges-03
>> 
>> 
>> Hi all,
>> 
>> I have no objection to this being published however I do think there are a couple
>> of significant weaknesses that really ought be addressed beforehand if the
>> authors/RG are willing to do that.
>> 
>> To repeat: I'm not objecting to publication. These are comments I probably
>> would have made earlier had I had the time, but I didn't, sorry.
>> 
>> Cheers,
>> S.
>> 
>> PS: I didn't cc the rg list in case folk here want to chat 1st, but this or a later
>> version after such a chat probably should be sent to the list. I've no problem if
>> someone just replies to this and cc's the list. (I'm subscribed there.)
>> 
>> PPS: Should dirk be the RG-chair running this poll? Better if a non-author does
>> the paperwork in cases like that isn't it?
>> 
>> 1. stuff that'd really be better addressed...
>> ---------------------------------------------
>> 
>> - The string "authoriz" does not occur in the draft. The word "authorised" does
>> occur once in 4.2.3, not as a challenge though, but rather as a putative way to
>> overcome an ICN challenge, by, as far as I can tell falling back to host based
>> networking.  As far as I know, there is no way to do authorization in an ICN
>> without that fall-back to host based networking and I think omitting that from
>> this document is a major defect.  Or, to put this in terms of issuing a challenge:
>> how can I deploy a purely ICN payroll system?
>> If a technology cannot be used to develop and deploy a payroll system, is that
>> not a challenge worth mentioning?  I think it is.
>> (4.2.5 even says "without access control" implying that access control is
>> impossible in an ICN?)
>> 
>> - Whether or not multiple applications can be run using the same ICN caches is
>> an interesting question with both business and technical aspects. Why is that not
>> covered?
>> 
>> - 3.2: "ICN can support ... encryption" - I claim that this is not true in any useful
>> sense. Can you really justify it? If not, please don't make the claim.
>> 
>> - 4.2.1: Where is "data object authentication" defined?  I had a quick look but
>> didn't find a good definition, though I did find a
>> (very) few uses of the term. Is this perhaps some ill-defined mixture between
>> data origin authentication and data integrity? If so, then I think that may be part
>> of the reason why pepole appear to gloss over the requirement that a PKI is
>> needed to do any better than name-data integrity. (See below for more detail on
>> that.) Anyway, please define this if you keep the term, or, maybe better (only
>> because it'd probably be quicker), see if you can use terms already defined in
>> RFC4949.
>> 
>> 2. nits, near-nits and generally not critical stuff...
>> ------------------------------------------------------
>> 
>> - abstract: this does mention some benefits of ICN but no specific challenges at
>> all, is that a fair reflection of the content?
>> 
>> - intro: why does ICN need to be a "core" network-layer primitive?
>> I think it need not be, and can be useful an an optional network-layer primitive,
>> used for (I think) mostly applications where that makes sense.
>> 
>> - intro: the challenging scenarios point requires that path symmetry not be
>> required. I believe CCN and derivatives still do require that, whereas netinf and
>> others do not. Maybe psirp has a need for symmetry along some parts of the
>> path. I think there is a challenge there to figure out the consequences of
>> requiring
>> (partial) path symmetry and whether or not ICN protocols should or should not
>> be designed assuming path symmetry. (It is possible that someone has done that
>> already though, I've not kept as up to date on ICN as I'd like.) 4.3.1 does ack this
>> issue to an extent but without linking to the challenged n/w scenario where it
>> can be a bigger deal.
>> 
>> - intro: "ICN is expected to..." that kind of statement is sales-talk and out of
>> place in a document like this I think.
>> Perhaps s/expected to/promoted by some as a technolog that will/ would be ok.
>> (If the "by some" is felt to be too weasel-wordy in my suggestion, you could fix
>> that via a reference to some paper(s) that do make that claim.)
>> 
>> - section 2, 4th bullet: I don't think it is correct to say that "n/w unaware of
>> media type => unable to manage access" which is how I read this. (See the
>> Marnew w/s which was largely about that
>> topic.) If you mean something else, then perhaps rephrasing this would be good.
>> 
>> - 3.1: You don't distinguish between NDO and some smaller unit here (e.g. a
>> "chunk" or similar) that may be meaningful to a convergence layer or transport
>> used between ICN caches/routers.  I guess the reason is that you think there's
>> no need for that distinction here, but if that's the case, maybe saying so would
>> be good, to avoid readers getting the wrong impression? (Note: I'm not sure if
>> such a change is needed or would be good, but I did think there was a missing
>> definition on first reading.) 3.2 does mention "segments of NDOs" though, and
>> "chunk" does occur later so maybe this might be worth another look (not sure).
>> 
>> - 3.1: I'm also surprised you don't need a concept related to whatever/whoever
>> creates/publishes an NDO.
>> 
>> - 4.1: "self-certifying" is STILL a crap term and always will be.
>> It is entirely misleading as to what one gets from name-data integrity. I think
>> you should remove all mention of that unless you leave in a statement that it is a
>> challenge for ICN to ovecome the misleading impression that has accrued from
>> use of that bogus term.
>> 
>> - 4.1: Some forms of ICN name-data integrity (e.g. the CCN one) do, I maintain,
>> require a PKI, it is just a different PKI from the WebPKI, in about the same way
>> that DNSSEC is a different PKI from the WebPKI.
>> 
>> - 4.1: What is an "aquainted hashed key"? The description here just does not
>> raise to the level where the "user" (huh, a user checks a digital signature?) can
>> "immediately verify that the data actually`are from the publisher." Such sloppy
>> language does not help describe challenges, but rather hides a challenge which
>> is how to deploy the PKI that is needed by signature based ICN naming schemes.
>> (You do to an extent recognise this challenge later, but that just makes ignoring
>> it here odder.)
>> 
>> - 4.2: Why is it acceptable to say "instead of discussing...
>> technical details, we ... <do something else> " in an IRTF document?
>> 
>> - 4.2.1: RFC5280 does not require a hierarchical PKI, saying that it does is a clear
>> error that needs fixing. I've already commented on the term "self-certifying, so
>> both "approaches" presented here as the 2 options are problematic, and there
>> are of course more options as well.
>> 
>> - 4.3: (just wondering) with the DNS we have only recently recognised the
>> benefits of and documented QNAME minimisation.  Are there any similar issues
>> with routing in ICN and how that impacts on privacy? (I'm not sure how one
>> might render that as a challenge.
>> 
>> - 4.6: s/smooth RTT value/smoothed RTT value/ maybe? if not, then maybe
>> "smooth RTT value" needs a reference
>> 
>> - 4.8: FCAPS could do with a reference maybe.
>> 
>> - 4.8: DTN (and other acronyms, but I know that one well:-) should be expanded
>> on 1st use.
>> 
>> - 4.8: It seems a bit odd for this to be the section where you mention DTN,
>> would the ICN/DTN relationship be better considered elsewhere? (I think a
>> sentence or two and a ref or two would be enough to cover that here.)
>> 
>> - 4.8: "can also leverage upon" is an odd phrase - I don't know what it means
>> myself tbh.
>> 
>> - 4.9.3: So-called IoT generally has an issue that the occurrence of traffic can
>> expose the content of that traffic.  E.g. packets go to light switch when person
>> enters room => seeing (ciphertext or
>> plaintext) packets means a person has entered the room. Does ICN have the
>> same kind of issue?  I'm not sure myself but would be interested in knowing, not
>> sure if it warrants a mention here.
> 
> _______________________________________________
> icnrg mailing list
> icnrg@irtf.org
> https://www.irtf.org/mailman/listinfo/icnrg