Re: NAT Control STUN Usage

Melinda Shore wrote:

[snip]
> 
> Look, STUN was "just" going to be used until
midcom was finished.  And
> then it was "just" to be used in cases where
a NAT cannot be modified.
> And then BEHAVE was "just" going to define
NAT behavior so that STUN
> would work across it.  And now it's "just"
putting a STUN server
> inside a NAT so that a NAT is basically a midcom
device.  Take another
> look at the draft - it's *definitely* defining on-path
signaling to
> NATs, and it's doing it without referencing existing
on-path signaling
> protocols.
> 

Tiny little Behave mutates and grows and can potentially
replace big
Midcom .  Looks to me as evolution applied to protocol
engineering.  It
works for operating systems[1], why not for network
protocols?


[1] http://kerneltrap.org/n
ode/11

-- 
Marc Petit-Huguenin           [                             
   ]
Home: marcpetit-huguenin.org [RFC1855-compliant space for rent
]
Work: marc8x8.com            [                                
]


_______________________________________________
Behave mailing list
Behaveietf.org
https:/
/www1.ietf.org/mailman/listinfo/behave