RE: [Manet-dt] Generalised OLSR packet/message format comments - msg-semantics

>> I think that this is an interesting point, which we may want to
expand
>> on a bit. Generally, there are the following cases, right?
>>
>>         - immutable || mutable
>>         - not-mutated || mutated
>>
>> Other than the semantic usability of this for different protocols, I
>> wonder if this feature is general for a "delivery semantics", or if
it
>> is flags pertaining to the content of the message. I am tempted to
say
>> the latter since if an intermediate note receives a message, how
would
>> knowing the "mutability-status" change that nodes behavior?
>>
>> I agree that receiving this information with a message may change the
>> processing behavior at the destination - in which case it could be
>> either an artifact of the message type (less desirable since it
slices
>> away the message type-space) or a message TLV (preferred).
>
> I have a few comments.
>
> What parts exactly are immutable/mutable? The contents of a message?
> How about the packet? How about the TTL and HopCnt fields?
>
> Thomas, I agree - I don't know that this belongs in the msg-semantics.
> Chris can you explain a bit more about why it belongs in the
> msg-semantics?

I don't say it does belong, I say it might belong. These are at the
"is this a useful idea?" stage.

To step back, the purpose of the message header is to allow a receiving
node to make the two assessments

(a) Should this message be processed, or ignored?
(b) Should this message be forwarded, or discarded?

And (depending on your implementation) allowing this decision to be made
without parsing the message body.

So if deciding whether or not immutable/mutable or non-mutated/mutated
bits belong in the semantics should be judged against these criteria.
(There may be other criteria - I think there's at least an independence
criterion, but that's not an issue here.)

So can those bits help in those decisions? I think in some cases they
can. Suppose you are running a secure protocol, such as an end to end
signature enhanced version of OLSRv2 (similar to published work on
Secure OLSR, but with signatures as message TLVs rather than separate
messages). Then the mutated setting gives a quick answer to these
questions (discard). Of course for this to possibly happen there must
be the possibility of nodes being either secure and insecure, which
may limit the applicability, which is why it only might belong. The
immutable/mutable is partly suggested as a natural companion, and
separating the two (one in semantics, one as message TLV) seems odd.
But the message TLV my well be more appropriate as it probably
doesn't pass either the (a) or (b) test - unless anyone can see an
argument to the contrary.

(It's partly down to resources, which is more valuable, a semantics
bit allocation, or message TLV bandwidth? - and yes, I know that's
comparing two incomparables.)

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

_______________________________________________
Manet-dt mailing list
Manet-dt@ietf.org
https://www1.ietf.org/mailman/listinfo/manet-dt