Re: MIPSHOP MIH DT

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

Thanks,
-Subir

Michael.G.Williamsnokia.com wrote:
>  
> 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.
>   
  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

> 	- 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. 
>   
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?
 
> 	
> 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. 
>   
   Subir> I am not sure whether this is a transport
requirement.
> 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
>> Mipshopietf.org
>> https:
//www1.ietf.org/mailman/listinfo/mipshop
>>
>>     
>
> _______________________________________________
> Mipshop mailing list
> Mipshopietf.org
> https:
//www1.ietf.org/mailman/listinfo/mipshop
>
> _______________________________________________
> Mipshop mailing list
> Mipshopietf.org
> https:
//www1.ietf.org/mailman/listinfo/mipshop
>   

_______________________________________________
Mipshop mailing list
Mipshopietf.org
https:
//www1.ietf.org/mailman/listinfo/mipshop

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).


 >  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
 >
 >>     - 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.
 > 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?
 >

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:
> Michael,
> Thanks for brining these issues to the DT. I would like
to add few more 
> points.
> 
> Thanks,
> -Subir
> 
> Michael.G.Williamsnokia.com wrote:
>>  
>> 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.
>>   
>  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
> 
>>     - 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.   
> 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?
> 
>>     
>> 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.   
>   Subir> I am not sure whether this is a transport
requirement.
>> 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
>>> Mipshopietf.org
>>> https:
//www1.ietf.org/mailman/listinfo/mipshop
>>>
>>>     
>>
>> _______________________________________________
>> Mipshop mailing list
>> Mipshopietf.org
>> https:
//www1.ietf.org/mailman/listinfo/mipshop
>>
>> _______________________________________________
>> Mipshop mailing list
>> Mipshopietf.org
>> https:
//www1.ietf.org/mailman/listinfo/mipshop
>>   
> 
> _______________________________________________
> Mipshop mailing list
> Mipshopietf.org
> https:
//www1.ietf.org/mailman/listinfo/mipshop
> 
> 


_______________________________________________
Mipshop mailing list
Mipshopietf.org
https:
//www1.ietf.org/mailman/listinfo/mipshop