daveoran
commented
4 years ago These are addressed in the-07 version
Closed daveoran closed 4 years ago
daveoran
commented
4 years ago These are addressed in the-07 version
Vincent Roca wrote:
section 2: the FIB, PIT and CS definitions are key to ICN but are not visible (hidden inside the « forwarding plane » definition). They deserve more visibility. We expect the usage model for this document to be more “lookup/search” rather than “Read end-to-end”, so there isn’t a lot of general exposition or attention to the order of the definitions part from the category groupings. By this logic the three data structures are all forwarding-related (as opposed to end-to-end semantics) so that’s where we put them. Unless you feel strongly about this, I’d prefer to leave this as is.
section 3.4, « Manifest » definition. Is this facility used when a content is split into several Data packets? An example of its possible use would be welcome I think. Yes, and potentially also for “directory-like” functions for multiple content object under the same prefix. The current Manifest specification (FLIC - an expired draft we are refreshing any day now) is mostly oriented toward the former usage. While we want to err on the side of being general and not biasing with particular concrete examples, it may be appropriate to add something here. Would the following rewrite be better? Old: “A type of Data packet that contains Full Name Links to one or more Data Packets. Manifests group collections of related Data packets under a single Name. This has the additional benefit of amortizing the signature verification cost for each Data packet referenced by the inner Links. Manifests typically contain additional metadata, e.g., the size (in bytes) of each linked Data packet and the cryptographic hash digest of all Data contained in the linked Data packets.” New: “A type of Data packet that contains Full Name Links to one or more Data Packets. Manifests group collections of related Data packets under a single Name. Manifests allow both large Data objects to be conveniently split into individual Content Objects under one name, and to represent sets of related Content Objects as a form of “directory”. Manifests have the additional benefit of amortizing the signature verification cost for each Data packet referenced by the inner Links. Manifests typically contain additional metadata, e.g., the size (in bytes) of each linked Data packet and the cryptographic hash digest of all Data contained in the linked Data packets.”
section 3.5: A figure is missing to explain the relationships between the « Name » (defined as a « Data packet identifier ») and the « Packet ID » (that is also a « unique crypto identifier for a Data packet ») which includes the « Name » in the hashed information, and the relationships between the « Exact Name » and « Full Name ». There are concurrent Data packets identifiers, with additional properties for the Packet ID, all of this being a bit confusing. Perhaps this is all a bit confusing without the context of understanding many pieces of the NDN or CCNx architecture. No disagreement on that. However, there are two downsides of trying to fix this with a figure: (a) it would likely need a whole bunch of additional explanation, winding up recapitulating things that are already documented in detail in specifications like RFC8569, (b) the relationships are not neatly captured graphically without slipping into specifying an algorithm by which you ascertain how, for example, to derive an Exact Name from the Full Name, or how Packet-ids are used in particular forwarding/matching algorithms. Again, our usage model for this document is that you’d start with some other specification, and get pointed here for formal definition terms used, as opposed to having this be the first thing you pick up when wanting to learn about CCNx or NDN. If you feel that we really need to “show our work” here, we’ll be happy to take a crack.
section 6 « security considerations » Instead of saying there’s nothing new, I’d rather point to the security considerations of already existing documents. This is more constructive since this type of architecture raises many security questions. Agree that the architecture does have lots new, and Stephen Farrell brought up a bunch of good points about the specifics of the crypto-related definitions (which we addressed in the current version). We can of course add references beyond the ones already in the document (especially RFC8569 and RFC8609) if you think that helps and cross-reference them in the Security Considerations section. Given that the terse language in the existing text raise a red flag for you, perhaps we could write the following for the security considerations: “While the terms defined in this specification do not in and of themselves present new security considerations, the architectures which utilize the terms most certainly do. Readers should look at those specifications (e.g. RFC8569, NDN) where various security considerations are addressed in detail”. What do you think? Adequate? Typo and minor comments:
intro: « in this draft… » => « in this document » seems preferable yes, will fix
section 3.1: « without that hange being detected » => change yes, will fix
section 3.2: I don’t understand sentence « Note do not have all the properties of data mules… » Missing word? Yes, should be “Note that such ICN data mules do not have all the properties of data mules as employed in the Delay Tolerant Networking (DTN) [RFC4838] specifications.”
section 3.3, « interest match in FIB » item: this is the first time the notion of prefix is mentioned, please add a link to section 3.5 where it is defined. ok, will do. Good idea.
Section 3.6, « fragmentation » definition. « A process of splitting PDUs into frames « => Frames as it refers to the « Frame » definition. assuming you mean just fix the capitalization of “Frames”, yes, will fix.