Re: [Spud] New Version Notification for draft-hildebrand-spud-prototype-02.txt

[Patrick McManus <[e-mail]>]

On Tue, Mar 10, 2015 at 5:15 PM, Brian Trammell <[e-mail]> wrote:

> What I can see being useful here is a facility built in to the "core" spud
> vocabulary that says "this tube is related to some other tube, here's the
> ID", for a small set of values of "related". This is more a signal to the
> remote endpoint than the path, though, so it's not clear it needs to be
> exposed in SPUD.



I think you can extend the use case under discussion to think about this as
a second tube initiated in the opposite direction.

If I have tube (a->b) started on my home lan that goes through my nat.. and
I get back tube (c->a [related to a->b]) then the tube is implicitly asking
to be allowed through the "nat/firewally-properties" based on the fact that
a->b is alive and was initiated from the a side. That's probably got some
ugly properties - but for handoff it has some nice ones (no rendezvous or
simultaneous open tricks, etc..).. maybe worth exploring. Or maybe we've
explored it here already ;)

It just seems if we're going to be signalling middleboxes, this is one of
the roles they play.