Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [STDS-802-21] Comments on 21-12-0067-01-srho-tgc-proposal



Hello Anthony,

I want to join remotely, you can connect me by skype.

Thanks,

Best Regards,
Dapeng Liu

2012/7/17, h chan <h.anthony.chan@xxxxxxxxxx>:
> Let us discuss at the 802.21c TG meeting in San Diego this week.
> The meeting times are
> Tuesday (July 17) 8-10AM Pacific time
> (after discussion on 21-12-0075-02 from Hyunho)
> If additional time is needed, we can continue
> Wednesday (July 18) 8-10AM Pacific time
>
> If anyone wants to join remotely, please email us beforehand to connect to
> you through Skype.
>
> H Anthony Chan
>
> -----Original Message-----
> From: Yoshihiro Ohba [mailto:yoshihiro.ohba@xxxxxxxxxxxxx]
> Sent: Monday, July 02, 2012 4:39 PM
> To: STDS-802-21@xxxxxxxxxxxxxxxxx
> Subject: Re: [STDS-802-21] Comments on 21-12-0067-01-srho-tgc-proposal
>
> Hi Pete,
>
> Thank you very much for reviewing the document.
>
> Please see my comments below.
>
> (2012/07/03 4:55), Peter McCann wrote:
>> Hi,
>>
>> I had promised to send some review comments on this document.
>>
>>
>> In Section 3, the acronym "MN" is expanded to mean "Mobile Network."  I
>> think
>> you meant, "Mobile Node?"
>
> I think it should be "Mobile Node".
>
>>
>> After reviewing the base 802.21 specification, I think the use of the
>> primitives
>> is mostly correct; however, some of the description in the text is a bit
>> wrong.
>>
>> For example, you say in Section 7.4.29.1.1 that the function of the
>> MIH_LL_Transfer.request primitive is to carry link-layer frames between
>> the
>> MN and the serving PoS.  This is incorrect.  It only carries the
>> link-layer
>> frames between the MIH user and the MIHF.  It is the corresponding
>> message
>> in Section 8.6.3.24 that actually carries the frames to the new PoS via
>> the
>> existing network.  This message is generated by the MIHF after receiving
>> an invocation of the MIH_LL_Transfer.request primitive from the MIH user.
>>
>
> You are right.  I think Section 7.4.29.1.1 has to be revised as you
> pointed out.
>
>> In Section 7.4.29.1.3: you say that the primitive is generated by an MIH
>> user
>> to start an authentication and association process based on link-layer
>> frames.
>> Do you really need to be so specific?  This is a general-purpose primitive
>> for
>> sending link-layer frames for any purpose whatsoever, isn't it?
>
> AFAIK, the discussed use of the primitive is pre-registration, and
> sending link-layer frames for any purpose using this primitive has not
> been discussed.  If we expand the usage to allow sending any LL frame
> then the text should be revised.  But we need to agree on expanding
> the usage first.
>
>>
>> Section 7.4.29.1.4: you say the MIH_LL_Transfer.indication is used by a
>> remote
>> MIHF.  I don't think you need to specify that it is a "remote" MIHF.  You
>> just
>> need to say that it is used by an MIHF to notify the local MIH user about
>> the
>> receipt of an MIH_LL_Transfer request message.
>
> I agree.  The text needs to be revised as you suggested.
>
>>
>> I do not think you need to specify the corresponding .response and
>> .confirm
>> messages.  The transfer of a link-layer frame is a one-way, unreliable
>> operation
>> that does not always generate a response.  Specifying a .response just
>> seems
>> redundant; the MIH user that receives an .indication can always generate
>> a
>> brand new .request primitive to transfer a link layer frame in the other
>> direction.
>
> The reason for having .response and .confirm primitives in
> MIH_LL_Transfer is basically inherited from 802.21a MIH_LL_Auth.
>
> I would say the design depends on whether the use of MIH_LL_Transfer
> is for pre-registration only or for carrying any link-layer frame.
>
>>
>> Similarly, I think you can do away with the MIH_N2N_LL_Transfer.response
>> and
>> .confirm primitives.
>
> Again the design depends on whether the use of MIH_LL_Transfer
> is for pre-registration only or for carrying any link-layer frame.
>
> Best Regards,
> Yoshihiro Ohba
>
>>
>> Do these suggestions make sense?
>>
>> --
>> Peter J. McCann
>> Huawei Technologies (USA)
>> Peter.McCann@xxxxxxxxxx
>> +1 908 541 3563
>> Rm. C-0105, 400 Crossings Blvd. (2nd floor), Bridgewater, NJ  08807-2863
>> USA
>>
>


-- 

------
Best Regards,
Dapeng Liu