Re: [dtn] BPbis - time units

[Lloyd Wood <[e-mail]>]

You have to distinguish between immutable immutability and
mutable immutability. In the first a field MUST NOT(SHOULD NOT?) be changed, while in the second it MAY,but SHOULD NOT, be changed

The draft doesn't do a good job of that; at the moment
the concepts are undefined, so they’re uncanonically canonical

if you remember immutability means SHOULD NOT be changed,you’re good. That’s a very clear semantic.



Lloyd Wood [e-mail] http://about.me/lloydwood






On Tuesday, 4 August 2020, 05:45:37 GMT+10, Wiethuechter, Adam <[e-mail]> wrote: 





I've been stewing on this for the past few days and rereading sections 4.1.6 and 4.2.2 that pertain to the issue. I have been approaching this as someone who is attempting to implement the draft without extensive prior knowledge (which I would fall into that category). So if I am missing something obvious sorry.

I agree the core issue here is semantic vs syntactic immutability and even my initial read of the document I scratched my head a bit of which one was being discussed.

To me, immutability is that once it's set it never changes, both in semantic form and syntactic. So this means once the primary block is encoded to be in seconds, it stays that way and no downstream node can change it to say milliseconds as an optimization (I would argue that increasing precision however is not an issue, but the other way is). So I think this falls into what Ran is getting at with the integrity/authentication failure. I will also agree to say we need to clearly define the semantics before proceeding. Also the term "harmlessly recode" is something I would be very cautious with and it makes me nervous.

The precision of milliseconds I think is a good one. It's fine-grained enough for the disruption scenarios (as anything in the microsecond range I would start to wonder why DTN is being used in the first place) and corse enough that the value isn't out of control in delay scenarios.



On Wed, Jul 29, 2020 at 2:34 PM R. Atkinson <[e-mail]> wrote:
> 
> 
>> On Jul 29, 2020, at 12:14, Birrane, Edward J. <[e-mail]> wrote:
>> 
>> Rick,
>>  
>>   BPbis states that the primary block shall be immutable, and then provides a definition of immutability (from section 4.2.2):
>>  
>> The primary block of each bundle SHALL be immutable.  The values of
>>    all fields in the primary block must remain unchanged from the time
>>    the block is created to the time it is delivered.
>>  
>> If we allow flexible time representation, an implementation could say “I, and all downstream from me, prefer milliseconds” and then recode time values in primary blocks from seconds to milliseconds in a well-intentioned attempt to speedup some processing thinking they met the standard of immutability presented in section 4.2.2 because the semantic time value was unchanged.
>>  
>> The text should probably say “the encoded values of all fields in the primary block must remain unchanged…”. Hopefully that is a small and not controversial clarification.
> 
> All,
> 
> If “encoded values” above means in the on-the-wire bit stream, I am fine with that.  
> 
> I really think that both semantics of the bits and the on-the-wire format of that time need to be (a) clearly defined and (b) the same end-to-end.  
> 
> Put another way:
> 
> If the source  is using seconds and it is converted during transit to the destination into milliseconds, then I would expect an integrity/authentication failure at the recipient.
> 
> Yours,
> 
> Ran
> 
> _______________________________________________
> dtn mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dtn
> 


-- 
73's,
Adam T. Wiethuechter
AX Enterprize, LLC

_______________________________________________
dtn mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dtn