Before getting to my review, one comment with <= ;Chair hat>.

This seems novel and interesting ICN research deserving o= f more visibility, review, and hopefully publication through the IRTF. Ho= wever, it=E2=80=99s gotten very little visibility and even less review in= ICNRG, so as chair I need to ask - does this have enough interest to war= rant adoption as an ICNRG draft, or should we encourage the authors to pu= rsue other publication options (perhaps as an individual contribution). U= nless we get more reviews and input encouraging adoption, it=E2=80=99s ha= rd to ask the authors to continue to revise the work leaving it in limbo.= PLEASE review this and send comments and indications of whether you supp= ort adopting this as ICNRG work.

</Chair hat>

The remainder of this review message is with <= Chair Hat Off>

General Comments

There are a lot of typos and English language usage p= roblems, so the draft needs some editorial work. I=E2=80=99ve attached a = marked up version with my suggested corrections, but I doubt I caught eve= rything, and in particular was less rigorous about marking corrections la= ter in the draft, since many of the usage problems are of the same genera= l nature throughout.
There needs to be a terminology section, and more car= e taken to define terms and acronyms either before or at their first usag= e. Some examples include:
- data consumer ID (DID?)
- custodian ID
- neighbor (see detailed comment below)
- NFD (also mis-spelled as NDF) on page 16
- ICDTN on page 19
This may be obvious, but you really do need to have F= igure 1, not a TBD.
I am not enough of an expert of the dynamics and opti= mization properties of DTNs to have a confident review of the material on= node/social contact optimization (section 5.1-5.3). I therefore don=E2=80= =99t have much to say on this material - it could of course be perfect.

Detailed Technical Comments

Some of the assumptions in section 1.2 are not actual= ly assumptions, as they are testable. For example, the statement =E2=80=9C= Selecting the best set of neighbors to replicate packets to, may not be e= fficient if based only on connectivity based information=E2=80=9D. I also= had a hard time figuring out why some things were considered assumptions= and others requirements. It might be better to eliminate this distinctio= n and instead articulate these as =E2=80=9Cdesign considerations=E2=80=9D= =2E
Along the same line, why is it a requirement that =E2= =80=9CRouting information must be exchanged based on Interest / Data mes= sages=E2=80=9D. That seems a design choice. It seems a good one, as it me= ans you don=E2=80=99t have to resort to non NDN/CCNx machinery to create = your routing protocol, but that doesn=E2=80=99t make it a requirement. A = requirement would be something more like the statement further down that = you can=E2=80=99t rely on the inverse path the Interest took to reach a p= roducer/custodian to return data, as that path may no longer exist when y= ou want to send the data back.
The role of data consumer IDs and custodian IDs is no= t well explained at all in the introductory material. At least a forward = reference to section 2.3 would help. I also had a hard time thinking clea= rly about their security properties, how easy they are to spoof (especial= ly if interest messages are not signed), what the consequence of unintend= ed value collisions were, etc. This whole part of the design needs to be = explained in more detail, and early in the exposition. Where the terms ar= e introduced (e.g. in section 1.2) a forward reference to the part of the= spec that explains them would be particularly helpful.
The nonce based scheme you explicitly rely on (page = 8) for loop detection has been definitively demonstrated to not work, and= to fail spectacularly if you allow any in-network retransmissions (which= I assume for a DTN-like architecture you=E2=80=99d want to have). CCNx h= as eliminated nonce-based loop detection entirely in version 1.0, and NDN= has added hop counts as a mandatory backup for the cases where nonces fa= il to detect a loop. I suggest finding a better loop detection scheme - i= f hop counts don=E2=80=99t cut it perhaps something based on Brent=E2=80=99= s algorithm (e.g. https://arxiv.org/abs/1612.04430) might be worth consid= ering? Also, I don=E2=80=99t see how disabling a face producing loops hel= ps unless you are getting zero forwarding utility through that face. The = topology is likely to be sparse and you want to use any working face if p= ossible.
in section 2.2, you talk about DABBER querying about = =E2=80=9Cneighbor=E2=80=9D nodes. In the world of DTN with nebulous and c= hanging topology, what exactly is your definition of a neighbor? Any node= the current node has ever talked to directly (i.e. over one radio hop), = any node on a L2 mesh that hides the internal topology from L3? Something= else?
(p.9) How does =E2=80=9Capplication category=E2=80=9D= relate to the metrics that DABBER would actually use? Is this some name = mapping function where by application category you actually mean =E2=80=9C= part of the global namespace=E2=80=9D?
how do you compute node degree in a fluid topology? I= s it the number of nodes contacted in some time window? Usually node degr= ee measures the number of neighbor nodes that can be simultaneous= ly reached, not the number reachable over time. This may or may = not not affect your computation of centrality, The other parameters used = to compute centrality seem intuitively the right ones though.
The term =E2=80=9Cnode similarity=E2=80=9D doesn=E2=80= =99t seem to capture the actual metrics mentioned in this category; perha= ps a better term would be =E2=80=9Cnode connectivity quality=E2=80=9D?
page 11 top - you are a bit sloppy in talking about a= n OPPface being =E2=80=9Cconnected=E2=80=9D - since in NDN and CCNx there= is no real notion of a face being connected, only a neighbor being avail= able over a face. It isn=E2=80=99t clear to me why you need a special fac= e at all, since a regular face queue could get blocked for a long time du= e to link errors or long-baseline link scheduling like you=E2=80=99d see = with LoRa or other low-bandwidth systems. There are other interactions I=E2= =80=99m pretty unclear on as well, such was whether interactions with Int= erest Lifetime get modified for OPPfaces or not. It also seems a bit weir= d to have a single face that has two different MTU values - that seems im= plied by the discussion, however I think you mean that these two transmis= sion modes (TCP or Mac-layer WiFi direct) would actually be different OPP= face instances. The latter seems cleaner, no?
top of page 12 - I don=E2=80=99t see how the selectio= n heuristic minimizes the number of WiFi Direct groups in a certain area.= I=E2=80=99m obviously missing something about the way WiFi direct works,= since I thought the number of groups was essentially undefined since the= re=E2=80=99s no protocol to compute transitive closure of the nodes, henc= e you don=E2=80=99t know how many =E2=80=9Cgroups=E2=80=9D there are, or = even if the notion of a WiFi direct =E2=80=9Cgroup=E2=80=9D is even meani= ngful in the context of DABBER.
at the end of section 2.4.1, you say =E2=80=9CDABBER= would need to encode in the Interest packet information about the ID of = the neighbors that should process the overheard Interest packet.=E2=80=9D= Why is this any different from normal multi-path forwarding in NDN/CCNx?= Do you want to suppress duplicate upstream forwarding of Interests by so= mehow telling which neighbor is intended to be the forwarder? If so, this= is normally done by L2/L3 demultiplexing and not something =E2=80=9Dextr= a=E2=80=9D in an L3 packet.
question: you seem to say DTNFaces only handle Data p= ackets, not Interest packets? Seems right, but more explanation would be = helpful. In particular you don=E2=80=99t explicitly say whether OPPfaces = never handle data packets, only Interest packets; is this the case?
section 2.4.3: you need to say a few words about CMFa= ce rather than TBD. Using a special face type (actually any face at all) = for communicating with the Context manager is actually an internal implem= entation design decision, right? One could have just as easily made the C= ontext manger an application and used the NDN/CCNx APIs for it to talk to= the forwarder, right? If not, and a face is needed semantically, this wo= uld be the place to explain the design, how the FIB directs things here a= nd how the state passes as Interest/Data exchanges over this face.
in the first paragraph of section 3, you claim that b= y using =E2=80=9Cdata reachability cost=E2=80=9D as the metric rather tha= n than path cost, you magically reduce the impact of topological changes = on routing stability. Well, that=E2=80=99s true only if the =E2=80=9Cdata= reachability cost=E2=80=9D doesn=E2=80=99t change when the topology chan= ges, right? And if it doesn=E2=80=99t change based on that, exactly what = does it change based on? This doesn=E2=80=99t seem to map obviously to th= e availability, centrality, and similarity metrics mentioned earlier. You= need to connect the concepts better. It would also help to better explai= n why having the data reachability cost avoids local flooding. Do you onl= y forward to the next hop with the cheapest data reachability metric? Why= would that be different from filtering on any other metric?
It isn=E2=80=99t completely clear whether you are usi= ng the older Chronosync or just the newer PSync, since you reference both= =2E It doesn=E2=80=99t seem you need the full overhead of chronosync, as = is seems PSync (or something with even weaker semantics) would not suffic= e. In any event, it would be useful to cite some newer work, for example = https://named-data.net/wp-content/uploa= ds/2019/01/li2018sync-intro.pdf.
Are LSA Interests sent on OPPfaces or regular faces? = Are the Data replies sent back using DTNfaces? Seems like this would not = be good, as they are one-hop protocols. The other problem could be a lot = of duplicate interests since the OPPface queueing might have many redunda= nt requests queued since nowhere does the face queue know about or try to= suppress duplicate packets.
At the top of page 18, you say =E2=80=9CThe higher th= e values of C, A and S, the most preferential a neighbor is.=E2=80=9D But= this isn=E2=80=99t well defined as you don=E2=80=99t specify a partial o= r total order among the metrics. Is this some sort of linear regression e= quation (ala what EIGRP does with multiple metrics?) Something else?
<= /li>
What is the consequence of different Dabber nodes usi= ng different NFD RIB update policies (as described on p.19)? It seems tha= t if all nodes don=E2=80=99t choose the same policy, even a local loop su= ppression policy like Downward Path won=E2=80=99t suppress loops if some = other node selects Increased Diversity.
I may have missed this, but another fairly deep funda= mental property of NDN/CCNx forwarding is that Data packets which arrive = without matching an existing PIT entry should be preferentially discarded= , and certainly not opportunistically forwarded further. The DTN scheme y= ou use for DABBER seems to quite dramatically violate this principle. The= NDN/CCNx treatment of arriving data packets clearly has to be relaxed to= accommodate DTNs. Part of my confusion is the statement =E2=80=9Cmaking = usage of information stored in the PIT=E2=80=9D since if you don=E2=80=99= t use paths to nodes without an active PIT entry, you can in fact only us= e symmetric routes. There=E2=80=99s a lot of detail on page 23, which dea= ls with the forwarding precedence, but not the (harder?) problem of how t= o manage the CS of one of these nodes opportunistically keeping Data pack= ets for which there is no corresponding PIT entry.
Section 8, beginning, you blithely state =E2=80=9Cens= uring the needed levels of confidentiality=E2=80=9D. What in fact are the= needed levels of confidentiality? I also suspect that a blanket statemen= t like =E2=80=9CMoreover, DABBER ensures the right level of privacy of th= e involved entities, who provide local information to support routing dec= isions.=E2=80=9D might raise hackles. Local information distribution almo= st inevitably leaks, and you don=E2=80=99t really address the level of tr= ansitive trust that you are assuming for these local environments. Some o= f this is covered in section 8.1, so perhaps fewer words in the introduct= ion, or explicit forward reference would keep the reader calm about the a= ssertions.
There seems to be a bit of circular logic in section = 8.1 around the fetching of keys. You need a certain amount of routing inf= ormation to support the fetching of keys from more than one hop away, yet= the authenticity of the routing information in turn depends on your beli= eving the keys. I suspect there is some invariant that ensures the scope = of key storage is deterministically more localized than the routing infor= mation it secures, but it isn=E2=80=99t entirely clear that the key hiera= rchy by itself guarantees this.

Nits

Need a reference for =E2=80=9CEpidemic Routing=E2=80=9D on p5
in the first paragraph of section 2, I think OPPFace and DTNFace are = face types, not faces. Also, forward reference to where these ar= e actually defined and used would help.
On page 9, in the paragraph on contextual awareness, you talk about a= user=E2=80=99s =E2=80=9Cinterests=E2=80=9D, which is normally a fine ter= m to use, but in this context, it has the obvious potential to be confusi= ng. I suggest changing the sentence to =E2=80=9C=E2=80=A6the user configu= res any desired types of information or other types of personal preferenc= es.=E2=80=9D
top of page 9, you say you only need one OPPface per device - but I d= on=E2=80=99t think this is true for a device with multiple radios, right?= It=E2=80=99s one OPPface per radio operating in broadcast mode, plus one= for each radio (or wired connection) operating in point-to-point mode. Y= es?
You don=E2=80=99t seem to specify the size/range of the LSA version. = Is it modular or monotonic? Maximum value?
I thought Chronosync and Psync use Bloom filters to find the diffs. T= he description on pp 14/15 seems to imply otherwise.
Validity seems to be done via a separate Validity timer rather than r= elying on Data Expiry of the Itnerest/Data exchange. Is this because the = individual LSAs are packaged together with multiple name prefixes to each= prefix might be different expiry? In any event, the expire ought to be t= he MIN(LSA Data message expiry, Prefix expiry).
You say =E2=80=9CThe routing table is then ordered by name prefix in = decreased order of validity.=E2=80=9D Why? This only matters when computi= ng the FIB or deciding which LSAs (if any) to filter). Seems unnecessary = overhead to keep the RIB sorted.
In your example on page 20, you don=E2=80=99t say if the validity is = in fact the Data Expiry value of the Data object in the Content store. I = would hope it is, since if you make a separate validity value you can eit= her continue to announce data that has expired, or black hole data that i= s still useful from the data producer=E2=80=99s standpoint. If the LSA co= vers a prefix with data objects of wildly different expirations, then I s= uspect the application needs to be rethought, or at least the structure o= f its namespace rethought.
On page 21, you say =E2=80=9CIndependently of the used forwarding str= ategy, it has to respect the ranking of faces done by DABBER on the RIB.=E2= =80=9D This seems to imply that forwarding has to look at the RIB, which = I don=E2=80=99t think is what you mean. I assume what you mean is that th= e FIB has to correctly reflect the ordering of the RIB with appropriate f= ilters and face eligibility/precedence. In any event this doesn=E2=80=99t= seem to be the right place in the exposition to be saying this.
in section 7.1, you say =E2=80=9CHowever, when DABBER is executing th= e LSA dissemination procedure over a Wi-Fi face, towards an edge router i= t will ignore all notifications that Chronosync will send related to Adja= cency LSAs. Why? A few more words here would be helpful.

[End of Comments]

DaveO