Subject: RE: [Mipshop] MIPSHOP MIH DT

From: <[email-masked]>
Date: Fri, 23 Feb 2007 19:06:12 -0600

Hi MIPSHOP folks,

Haven't heard much about how the DT is doing, but here are some points
that came out in the joint 802.11 Tgu and 802.21 ad hoc this week for
consideration.

Two of the points were:

1) An 802.11 AP/AC might wish to simply forward L2 ACTION frames with
the MIH state 1 information service query, to the Information Service
PoS. If so, what L3+ protocol would it use, since it is not implementing
the MIHF, nor acting as a PoS in that model.
	- There were discussions that MIH transaction semantics would be
between the MN and MIIS. 
	- There was also concern that the AP/AC would have nothing to
use to determine which MN to send the MIIS responses to. 
	
2) There was a concern that the MIIS might like to know if the MN was
authenticated or not, to facilitate access control/filtering of the
information in the response, and for imposing other limits.

Best Regards,
Michael

>Stefano Faccin wrote:
>> Hello all,
>> 
>> My apologies for not posting this sooner.
>> 
>> After several discussions with WG members due to high expression of 
>> interest by several parties, the design team for the MIH
>solution for
>> MIPSHOP will be composed by:
>> 
>>     * Robert Hancock (DT leader)
>>     * Srinivas Sreemanthula
>>     * Subir Das
>>     * Juan Carlos Zuniga
>>     * Telemaco Melia
>>     * Sam Xia
>>     * John Loughney (as NSIS and transport expert)
>> 
>> It is the WG chair expectation that the DT will have frequent 
>> interactions (the modality is up to the DT members) to come
>up with a
>> DT draft solution ASAP, as discussed at the last meeting. 
>Please setup
>> also a mailing list for the DT, including the WG chairs.
>> 
>> Wishing you fruitful interactions,
>> 
>> BR
>> 
>> Stefano
>> 
>
>_______________________________________________
>Mipshop mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/mipshop
>

_______________________________________________
Mipshop mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mipshop

_______________________________________________
Mipshop mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mipshop

---

From: Subir Das <[email-masked]>
Date: Mon, 26 Feb 2007 11:41:08 -0500

Michael,
Thanks for brining these issues to the DT. I would like to add few more 
points.

Thanks,
-Subir

> the MIHF, nor acting as a PoS in that model.
  Subir> TGu does not want to restrict the placement of Information 
Server within the same subnet
              where AP/AC belongs. Also AP/AC can not be used as a 
bridge.  So the model is:

                         L2                                   L3+
     STA  <-------------->AP/AC <------------------->IS Server

> use to determine which MN to send the MIIS responses to. 
Subir> This is one of the options. These problems will not exist if  
AP/AC implements some of the
            MIH functionalities similar to 802.16g. If it uses L2 
between STA and AP/AC,  how the
            response will be send is an implementation issue. On the 
other hand, the important point
            is:  do we support the above model whereby the intermediary 
is not an MIHF but
            communicating with the IS server with a L3+ transport protocol?
 
> information in the response, and for imposing other limits. 
   Subir> I am not sure whether this is a transport requirement.

---

From: Hong Cheng <[email-masked]>
Date: Tue, 27 Feb 2007 10:30:01 +0800

Hi Subir and Michael,

TGu cannot mandate where the IS Server is, since it is a function out of 
scope of 802.11. TGu only provides the transport over the air. As for 
how the AP/AC treats the received MIH contents, it is really up to 
802.21 to define. I think it is very similar to the support of EAP 
(802.1x, not 802.11, defines the EAP frame treatments). The difference 
is now that we need to support the frame exchanges at state 1 (in 802.11 
context).

 >> between the MN and MIIS.        - There was also concern that the
 >> AP/AC would have nothing to
 >            MIH functionalities similar to 802.16g. If it uses L2 between
 > STA and AP/AC,  how the

In the case of EAP support, the L3+ transport between AP/AC would be the 
AAA protocols (e.g. RADIUS/Diameter). So, similar thing could be done 
here for MIH support. Maybe the DT is also looking at something here?

cheers

Cheng Hong

Subir Das wrote:
>> between the MN and MIIS.        - There was also concern that the 
>> AP/AC would have nothing to
>            MIH functionalities similar to 802.16g. If it uses L2 between 
> STA and AP/AC,  how the