FYI, this thread seems to be going forward really well despite all the drama,
please do chime in before I promise something I don’t understand the
ramifications of ;)
Anfang der weitergeleiteten Nachricht:
Von: Thomas Heide Clausen <ietf@xxxxxxxxxxxxxxxxx>
Betreff: Aw: [manet] On Forwarding-and-regeneration (was: Re:
draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
Datum: 22. April 2016 um 15:21:28 MESZ
An: "Dearlove, Christopher (UK)" <chris.dearlove@xxxxxxxxxxxxxx>
Kopie: Lotte Steenbrink <lotte.steenbrink@xxxxxxxxxxxx>, Mobile Ad Hoc
Networks mailing list <manet@xxxxxxxx>
On 22 avr. 2016, at 15:05, Dearlove, Christopher (UK)
<chris.dearlove@xxxxxxxxxxxxxx <mailto:chris.dearlove@xxxxxxxxxxxxxx>> wrote:
Once you're entirely in AODV2's own space, and AODVv2 is experimental
(working assumption for this discussion) you have more liberty.
Yep.
Taken somewhat by surprise both by the sudden "rush" and the experimental
maturity level, I am wondering (and haven't thought through) about
experimental space vs non-experimental (for message types, and consequently
for message type specific TLV types).
I think that if the AODVv2 experiment specifies the use of Message types from
the Experimental message type space without making actual registrations in
the IANA registry, AND the use of type specific TLV types, this becomes a
non-issue entirely (by design, this is precisely what that experimental space
is for)
Whereas, as you point out, the alternative is a "can open - worms everywhere"
situation that I think time is too short to solve?
Thomas
Then you could try specifying it. But with a very good chance of producing
something you later decide you should have done differently.
I honestly don't know which would go down better (or less badly) - "here's a
mechanism we haven't really thought through in detail, but at least we've
defined one", or "we know the sort of thing we want, and we'll describe it,
but rather than produce something not quite right, we'll not go further".
--
Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence Laboratories
__________________________________________________________________________
T: +44 (0)1245 242194 | E: chris.dearlove@xxxxxxxxxxxxxx
BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow,
Chelmsford, Essex CM2 8HN.
www.baesystems.com/ai
BAE Systems Applied Intelligence Limited
Registered in England & Wales No: 01337451
Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP
-----Original Message-----
From: Lotte Steenbrink [mailto:lotte.steenbrink@xxxxxxxxxxxx] ;
Sent: 22 April 2016 13:59
To: Mobile Ad Hoc Networks mailing list
Cc: Henning Rogge; Dearlove, Christopher (UK)
Subject: Re: [manet] On Forwarding-and-regeneration (was: Re:
draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
----------------------! WARNING ! ---------------------- This message
originates from outside our organisation, either from an external partner or
from the internet.
Consider carefully whether you should click on any links, open any
attachments or reply.
Follow the 'Report Suspicious Emails' link on IT matters for instructions on
reporting suspicious email messages.
--------------------------------------------------------
Hello Christopher,
Am 22.04.2016 um 11:57 schrieb Dearlove, Christopher (UK)
<chris.dearlove@xxxxxxxxxxxxxx>:
Just be careful to note that this concept is as currently being discussed
(a) specific to AODVv2, and (b) not an application of 7182, which has no
knowledge of special TLVs.
This is something we'd want to get right, and need to get right if in any
space not specific to ADODVv2, because getting it wrong produces future
problems.
Makes sense.
I can see some possible approaches, none is ideal and we're rather out
of time to specify. But this is experimental, so I think we might be
able to indicate the shape of the solution without specifying it,
which would be a different RFC, under a bit less time pressure.
(Extensions to existing protocols like 7182 would naturally be in
scope rechartered I think.)
To indicate the range that's open, here are two possible ideas, one of
which has an impact now, so needs to be agreed. Note that I'm not
suggesting (in fact quite the opposite) defining an extension to 7182 here,
rather enabling such an extension, if written, to "do the right thing".
- We have an extension to 7182 that says "zero out all value octets in
protocol specific TLVs. That requires now putting the AODVv2 metric TLV in
that space.
Just to make sure that I understood you correctly– “that space” meaning
making the AODVv2 metric TLV protocol specific? (By “the aodvv2 metric tlv”
I’m referring to the generic TLV we’ve been talking about on this list
earlier this week).
- We have an extension to 7182 that adds extra material to the value field
that indicates (TBD how, by position with sanity check that this is TLV
value perhaps?) which octets are to be zeroed out before the ICV is
calculated.
The way I understand that approach, it wouldn’t warrant any action from
AODVv2 besides saying “if you calculate the ICV, set the Metric value to
zero” (leaving the nitty gritty of how this would be done in detail to
future work)… Is that correct?
We do not have the time to specify this in an acceptable manner within two
weeks though. But the security consideration section could say something
along the lines of "this enables the use of an ICV defined to zero out
these octets“.
Okay. :)
Best regards,
Lotte
--
Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence Laboratories
______________________________________________________________________
____
T: +44 (0)1245 242194 | E: chris.dearlove@xxxxxxxxxxxxxx
BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow,
Chelmsford, Essex CM2 8HN.
www.baesystems.com/ai
BAE Systems Applied Intelligence Limited Registered in England & Wales
No: 01337451 Registered Office: Surrey Research Park, Guildford,
Surrey, GU2 7YP
-----Original Message-----
From: manet [mailto:manet-bounces@xxxxxxxx] On Behalf Of Lotte ;
Steenbrink
Sent: 22 April 2016 10:28
To: Henning Rogge
Cc: Mobile Ad Hoc Networks mailing list
Subject: Re: [manet] On Forwarding-and-regeneration (was: Re:
draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
----------------------! WARNING ! ---------------------- This message
originates from outside our organisation, either from an external partner
or from the internet.
Consider carefully whether you should click on any links, open any
attachments or reply.
Follow the 'Report Suspicious Emails' link on IT matters for instructions
on reporting suspicious email messages.
--------------------------------------------------------
*** WARNING ***
EXTERNAL EMAIL -- This message originates from outside our organization.
Hi Henning,
Am 22.04.2016 um 11:08 schrieb Henning Rogge <hrogge@xxxxxxxxx>:
On Fri, Apr 22, 2016 at 11:05 AM, Lotte Steenbrink
<lotte.steenbrink@xxxxxxxxxxxx> wrote:
Hi Thomas,
Can it?! Iirc, the reason why we adopted the “regeneration” language
in the first place is that we’ve been told that whenever one bit in
the message (apart from its header) is changed, the entire thing has to
be regenerated.
I’m starting to get the feeling we’ve just been misunderstanding
each other for more than a year. :( Anyway, it seems like we’re
getting close now, so yay.
"Modifying" the binary message instead of parsing and generating a
new one will be difficult as soon someone writes an extension to
AODVv2 that adds more TLVs to the message.
D’oh, right. Yeah, if I remember it correctly, that’s what you explained to
me when I got confused about the topic last spring… But– even if a message
contains TLVs that the AODVv2 implementation handling it doesn’t
understand, it will still be able to recognize the Metric TLV, right? Isn’t
that the nifty thing about RFC5444? So, while we really shouldn’t write
“before calculating the ICV, set the n-th 4 octets to 0”, we might say
“identify the octets that make up the metric value and set those to 0”?
Best regards,
Lotte
Henning Rogge
_______________________________________________
manet mailing list
manet@xxxxxxxx
https://www.ietf.org/mailman/listinfo/manet
********************************************************************
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 mailing list
manet@xxxxxxxx <mailto:manet@xxxxxxxx>
https://www.ietf.org/mailman/listinfo/manet ;
<https://www.ietf.org/mailman/listinfo/manet>
