Re: [dtn] "Block data length" field in BPbis

["Marc Blanchet" <[e-mail]>]

On 30 May 2018, at 15:10, Felix Walter wrote:

> Scott,
>
> great, I think removing the field is the best solution.
>

much safer to have one single place for authority. However, does that 
require more parsing from the intermediate nodes if they need to 
somewhat parse some blocks for policy decisions for example?

Marc.

> Felix
>
> Am 30.05.2018 um 20:54 schrieb Burleigh, Scott C (312B):
>> Felix, sorry, I am finally replying to this email: you are right that 
>> CBOR representation would provide all of the individual lengths of 
>> the block-type-specific data fields that are summed in the block data 
>> length field, and as such the block data length field is redundant.  
>> My first impulse on re-reading your email was simply to revise the 
>> definition of "Block data length" as you suggest.  But on reflection 
>> I think it actually makes more sense to remove block data length from 
>> the specification and instead specifically require that all 
>> block-type-specific data fields appear in CBOR representation.
>>
>> I want to post version 11 of this specification later today, before 
>> version 10 expires, and at this point I plan to go ahead with removal 
>> of the block data length field.  If anyone has a technical argument 
>> to make in defense of retaining block data length in bpbis, please 
>> speak up this afternoon?
>>
>> Scott
>>
>> -----Original Message-----
>> From: dtn <[e-mail]> On Behalf Of Felix Walter
>> Sent: Friday, March 23, 2018 9:22 AM
>> To: [e-mail]
>> Subject: [dtn] "Block data length" field in BPbis
>>
>> Hi,
>>
>> We just had a short talk with Scott, Ed, and Rick about the "Block 
>> data length" [1] field of the canonical block in BPbis that I would 
>> like to forward to the list. As far as I understand it, this value is 
>> the count of (serialized) bytes still belonging to the block, but 
>> following the length field.
>>
>> Because CBOR is used for the block-type-specific data, the length 
>> field by itself is redundant. For example, in the payload block, it 
>> will always be followed by a "CBOR byte string" representing the 
>> payload data. (This contains a length as well.) It needs to be 
>> considered in implementations that all these length fields are 
>> variable-length themselves - however, this turned out to be no big 
>> issue. I also see the point of having the "Block data length"
>> available to the parser, to be able to skip over the whole block data 
>> of complex extension blocks without even parsing them.
>>
>> Are there any further reasons for having the "Block data length"
>> available which I have missed? Or does anyone have a strong opinion 
>> on whether this should be removed or kept?
>>
>> By the way, the language concerning the "Block data length" should 
>> probably be modified slightly as it refers to "[...] the aggregate 
>> length of all remaining fields of the block, i.e., the 
>> block-type-specific data fields.", though, this may (now) be followed 
>> by the CRC checksum.
>>
>> Felix
>>
>> [1] https://tools.ietf.org/html/draft-ietf-dtn-bpbis-10#section-4.2.3
>>
>> _______________________________________________
>> dtn mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dtn
>>
>> _______________________________________________
>> dtn mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dtn
>
> _______________________________________________
> dtn mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dtn