[MLB-WIRELESS] Re: Node x is over this way -was- Applications

[Ben Anderson]

> > > May I just add something:
> > >
> > > Problem A - we don't want anybody to know physically where any of the
> > > nodes are, but we want the link-layer to self-optimise.
> > >
> > > JonSay:  Forget it!  Don't try to solve this problem, its too hard!
> > > Instead:
> >
> > I think it's not too hard to have a self-optimising layer that does
this...
> > At least, I haven't found a good reason as to why it's too hard...
> >
>
> Have a go at designing one.
>
> ;-)

Have been, and continue to iterate the design.  Have been asking for flaws,
got any new bees to throw in my bonnet to solve?


> > > Problem B - even though the nodes use physical location, GPS etc, to
> > > manage link-layer optimisation, we want it to be impossible to _prove_
> > > that a given node is the site of an actionable (eg. unlawful) data
item.
> >
> > Yup, though just that isn't enough for the safety of the node in some
cases,
> > where guilt is assumed and you have to prove the data isn't unlawful.
> >
>
> Not so fast:
> 1. they have to prove association
> 2. we don't have this situation in australia, at least not at the moment

Yet.  I think default encryption should be employed anyway, at least to
future proof it a little.  And also because it's not hard.


> > > JonSay:  Yes!  But its a higher level problem.
> >
> > I think it should be built into the networking stack as a default,
rather
> > than an applicaiton layer tunnel through the rest... it makes it look
like a
> > big nasty hack.
> >
>
> not if you keep your layers nice.

I think you've already made them 'not nice' by the way applicaitons have to
link in encryption, instead of just linking to a socket library that deals
with all that crap.

> > > In other words, I say - just make the link layer as fast as we can.
> > > Approach B is for when we get to the stage of worrying about what we
are
> > > transmitting.
> >
> > Yep, there's certainly elements of what we need to look at.  If we
hadn't
> > had the discussion, we wouldn't have come up with a way of migrating to
our
> > eventual solution from the initial implementation.  So this talk is
> > basically very useful, and a good thing.
> >
> > Ben.
>
> Thanks Ben.
>
> Oh, and thanks for the SS stuff too, for some reason netscape wont let me
send
> back to you.

No problems...  Email me privately if you want know more, or just chat about
it ;)

Ben.


--
To unsubscribe, send mail to minordomo at wireless.org.au with a subject of 'unsubscribe melbwireless'  
Archive at: http://www.wireless.org.au/cgi-bin/minorweb.pl?A=LIST&L=melbwireless
IRC at: au.austnet.org #melb-wireless