[icnrg] Re: [irsg] IRSG review of draft-irtf-icnrg-ccnxchunking-04

[Hitoshi Asaeda <[e-mail]>]

Jörg,

Thank you so much for your careful review.
(And thank you, Dirk, too.)

We’ll revise the draft based on your feedback and submit it.

Regards,

Hitoshi

> On Jun 9, 2026, at 17:17, Dirk Kutscher <[e-mail]> wrote:
> 
> Thanks, Jörg!
> 
> Authors, can you check these review comments and let us know how you want to proceed?
> 
> Thanks,
> Dirk
> 
> On 8 Jun 2026, at 21:05, Joerg Ott wrote:
> 
> Hi,
> 
> I have read through the draft "CCNx Content Object Chunking" and have the following IRSG review comments.
> 
> The document describes ow to transfer larger objects that won't fit into a single packet using successive Interest packets in CCNx.
> 
> While the technique is basically straightforward and the draft is clearly on the right track there are some minor issues and clarifications that should go into an updated version of the draft.
> 
> Best,
> Jörg
> 
> Detailed comments:
> 
> Sect. 1
> 
> "This means a Content Object is usually within common UDP or jumbo Ethernet size."
> 
> Please be specific about "MTU size" -- which also means that MTU size discovery may be necessary, or how would a sender know what an appropriate size is?
> 
> Sect 3.1
> 
> "A field in the Content Object that a chunk is the last chunk of the object Chunks are denoted by a serial counter, beginning at 0 and incrementing by 1 for each contiguous chunk. Any Interest issued with a chunk number higher than the last chunk number MUST be dropped with no response."
> 
> JO: This text comes too early in the spec, it defines behavior before the remaining context is clear.
> 
> "the publishes names the content" -> JO: "... MUST name the content" ?
> 
> "The first chunk of user daat (a chunk with a payload TLV) may not be chunk 0."
> 
> JO: What is this supposed to say? Please clarify.
> 
> JO: Error handling appears to be missing: What happens if you receive another content item with a chunksize element?
> 
> "Therefore, it is RECOMMENDED that all required cryptographic data, such as public keys or key name links, be included in the leading chunks before the first byte of user data. User data SHOULD then run continuously."
> 
> JO: This seems to create an interesting condition:
> 
> You would like to be able to seek e.g. in multiples of 1024 bytes, i.e,. chuink_size = 1024.
> 
> But, at the same time, you want to include crypto metadata of some sort in the beginning.
> 
> Unless you have an elaborate padding scheme, these metadata will not add up to a multiple of chunk_size.
> 
> Then, you can seek but you start at an offset that is not equal to chunk_size.
> 
> Is this weirdness intentional? Seem counter-intuitive...
> 
> Or is it intended that the first chunk does not contain any user data (as you could somewhat be read into the text earlier)? This would then need clear clarification.
> 
> "To summarize: ...
> 
> The leading chunks MAY have missing or empty Payload TLVs and convey only cryptographic or other information."
> JO: This appears a mismatch to the data paragraph above: there cryptographic data is not included in the user data.
> 
> I think what is needed is a rewrite of parts of this section to make clear what is done how.
> 
> I also don't fancy a "summary": provide an overview in the beginning and then detailed protocol operation, but a summary may lead to more confusion than help understanding.
> 
> Sect 3.2
> 
> "Each subsequent chunk only needs to include the KeyId and signature."
> 
> JO: Does this need an explicit statement that the sum should not exceed MTU size and it is up to the producer to ensure that this property holds after determining MTU size.
> 
> Especially, with post-quantum crypto, signature sizes grow.
> 
> Figure 1:
> 
> JO: Should there be a reference to the encoding of a variable-length integer?
> 
> Sect. 6.2:
> 
> Is the IANA consideration section sufficiently complete?
> 
> Sect. 7:
> 
> JO: At which level are authentication and integrity protection applied? Should just be made explicit.
> 
> I would assume that this does not happen at the chunk but at the object level. An obvious security implication would appear to be that many chunks may need to be gathered before integrity can be verified. This could give rise to DoS attacks on consumer buffer space...
> 
> If individual chunks ought to be signed, should this be stated somewhere?
> 
> _______________________________________________
> icnrg mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]