| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Dear all, Although not related with this ballot, I just wanted to share some possible aspects regarding the proxy feature in 802.21. In our work, we have implemented this behavior in a 802.21-aligned perspective ( http://www.sciencedirect.com/science/article/pii/S0140366412000734 ). There, we provide a MIH proxy behavior that not only could be used at the PoA or at the PoS, but in a hybrid scenario . Concretely, a sensor gateway would be responsible for forwarding some of the messages between the sensors and entities at the network (Proxy MIHF behavior, or "pure" proxying for 802.21 signaling), but, in other situations, it could act as an actual PoS for certain messages (such as 802.21 discovery and capability exchange procedures). In a nutshell, although there can be several proxy definitions, we could allow the standard to be flexible and allow different entities to be configured to provide different aspects of the proxy behavior (i.e., Proxy MIHF and/or Proxy PoS and/or Proxy PoA). Best regards, Daniel Corujo dcorujo@xxxxxxxx http://re.vu/dcorujo On Jan 15, 2013, at 08:47 , Charles E. Perkins wrote: > Hello Antonio, > > I confess that I find the Proxy usage within 802.21c somewhat > confusing, and I'm not at all comfortable with a "proxy-everything" > box. This is why I started to think that we could finally get to a > more understandable specification if we were more specific about > exactly what is getting "proxied". I'm O.K. to have several possible > proxy functions. I'm not O.K. if I can't tell what is a proxy function > versus what is a server function versus what is a MIHF. > > My hope is that, by having such specific details, it will be more > possible to show the scenarios requiring each of the individual > kinds of proxy functions. > > And, perhaps illustrating my point, I do not know how to > answer whether it's a proxy PoS function or a proxy PoA > function. > > Regards, > Charlie P. > > > On 1/14/2013 11:40 PM, Antonio de la Oliva wrote: >> Hi Charles, >> one question, are we thinking on allowing the new uses cases appearing while splitting the proxy functionality in such way? I mean, the Proxy PoA is something that has been discussed several times in .21 (if I recall properly) but never accepted. The .21c proxy functionality is the PoS one, is not it? >> >> Br >> Antonio >> >> >> On Tue, Jan 15, 2013 at 12:50 AM, Charles E. Perkins <charles.perkins@xxxxxxxxxxxxx> wrote: >> Hello folks, >> >> I've been puzzling over the definition of "proxy" as it is used >> in 802.21. >> >> Here's the current definition: >> >> > Proxy function: A function to bridge the mobility signaling between >> > a mobile node (MN) and a target point of attachment via the >> > source network. To the MN, the Proxy function acts like a >> > virtual point of attachment (PoA) to the target network. >> > It enables such functions as preregistration and proactive >> > authentication of the MN. >> >> I think it's probably better to refocus this definition. >> We possibly could have three proxy functions: >> >> Proxy MIHF: >> an entity that appears to an MN to be an MIHF, but which in >> reality simply interfaces to another device which actually >> performs the MIHF functions >> >> Proxy PoA: >> an entity that appears to an MN to be an PoA, but which in >> reality simply interfaces to another device which actually >> performs the PoA functions >> >> Proxy PoS: >> an entity that appears to an MN to be an PoS, but which in >> reality simply interfaces to another device which actually >> performs the PoS functions >> >> This may still need more refinement, for instance to describe how >> PoS functions are different than MIHF functions, but I think it's >> a lot more understandable. In the body of the text, then, it could >> be explained how a Proxy PoA does "proxy authentication", or >> other proxy preregistration activities. >> >> >> Regards, >> Charlie P. >> >> >> >> -- >> Antonio de la Oliva >> Visiting Professor >> Telematics Department >> Universidad Carlos III de Madrid >> E-mail: aoliva@xxxxxxxxxx >> Phone: +34 91 624 8803 >> Fax: +34 91 624 8749 > >
Attachment:
smime.p7s
Description: S/MIME cryptographic signature