Re: [manet] On Forwarding-and-regeneration (was: Re: draft-ietf-manet-aodvv2-13 review

> On 22 avr. 2016, at 15:05, Dearlove, Christopher (UK) <chris.dearlove@baesystems.com> 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@baesystems.com
> 
> 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@fu-berlin.de] 
> 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@baesystems.com>:
>> 
>> 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@baesystems.com
>> 
>> 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@ietf.org] 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@gmail.com>:
>>> 
>>> On Fri, Apr 22, 2016 at 11:05 AM, Lotte Steenbrink 
>>> <lotte.steenbrink@fu-berlin.de> 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@ietf.org
>> 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@ietf.org
> https://www.ietf.org/mailman/listinfo/manet