Re: [manet] On Forwarding-and-regeneration (was: Re: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)

[Justin Dean <[e-mail]>]

Speaking as participant.

I kind of like the idea of using the experimental message type space.  We
only have a limited amount of these message types.  The TLV assignments
could just use the message type specific space and there isn't an issue
there.  IANA wouldn't assign a number but I don't see why the document
couldn't specify the experimental numbers it was going to use so other
future near term experiential protocols could do the same and generally
avoid conflict.  If the experiment is successful IANA assignments could be
made.  Functionally no real difference with protections vs long term usage
of limited space.

Justin

On Fri, Apr 22, 2016 at 9:35 AM, Dearlove, Christopher (UK) <
[e-mail]> wrote:

> There's rather a contradiction between the concepts of a definition of a
> protocol, even Experimental, and experimental space, which usually assumes
> that the user can do what he or she likes in it.
>
> But chewing up messages types (how many, 3?) of which there are relatively
> few for experimental is long term a problem, although short term not.
>
> TLV space is easier in two regards. It's bigger (though the prime real
> estate of type extension zero isn't) and can have message type specific
> TLVs.
>
> So TLVS can actually be invisible, if that option is chosen. For messages
> something has to give. Least bad option is again one of those we should
> discuss, but time ...
>
> (To be precise, messages types from 224 are defined in RFC 5444 as "
> Experimental Use", of which BCP 26 says "Similar to private or local use
> only, with the  purpose being to facilitate experimentation." The
> alternative 0-223 space is Expert Review. IANA still thinks the experts are
> Joe Macker and the recused Stan Ratliff. But that's a soluble nit.)
>
> --
> Christopher Dearlove
> Senior Principal Engineer
> BAE Systems Applied Intelligence Laboratories
> __________________________________________________________________________
>
> T:  [phone]  |  E: [e-mail]
>
> 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: Thomas Heide Clausen [mailto:[e-mail]]
> Sent: 22 April 2016 14:21
> To: Dearlove, Christopher (UK)
> Cc: Lotte Steenbrink; 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.
> --------------------------------------------------------
>
>
> > On 22 avr. 2016, at 15:05, Dearlove, Christopher (UK) <
> [e-mail]> 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:  [phone]  |  E: [e-mail]
> >
> > 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:[e-mail]]
> > 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) <
> [e-mail]>:
> >>
> >> 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:  [phone]  |  E: [e-mail]
> >>
> >> 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:[e-mail]] 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 <[e-mail]>:
> >>>
> >>> On Fri, Apr 22, 2016 at 11:05 AM, Lotte Steenbrink
> >>> <[e-mail]> 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
> >> [e-mail]
> >> 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/manet
>
> _______________________________________________
> manet mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/manet
>