Re: [STDS-802-21] Comments on 21-12-0067-01-srho-tgc-proposal
Hi Peter,
I agree with you that there should be a generic mechanism to carry L2
frames, that was the original idea of the LL_Transfer. The reason for
adding the extra parameters was to help with the authentication. Do
you think the use of this primitives, defining as optional the
security parameters will be enough?
I have no answer yet to the response primitives, I am not sure if they
are needed or not in current spec.
BR
Antonio
On Tue, Jul 3, 2012 at 8:13 PM, Peter McCann <Peter.McCann@xxxxxxxxxx> wrote:
> Hi, Charles,
>
> What do you think about eliminating the .response and .confirm primitives
> from the link layer transfer?
>
> I read 802.21a which contains Auth Request/Response messages and I guess
> Yoshi is saying that was the inspiration for making separate link layer
> frame request/responses. However, I don't see why we have to do this.
>
> There may be reasons other than authentication to send a link-layer frame
> to a remote PoA. The setup of the link may involve several messages
> prior to or after authentication. It would seem appropriate to have a
> generic way to carry these messages.
>
> -Pete
>
> Charles E. Perkins wrote:
>>
>> Hello Pete,
>>
>> I am in agreement with Yoshi on all of these points. They should be
>> reflected in the next revision of the proposal.
>>
>> Would you be willing to review the diagrams and make suggestions about
>> how they might be clearer? It seems to me that the differences
>> between the various scenarios could be highlighted somehow, or
>> irrelevant detail omitted, so that the main points are easier to grasp.
>>
>> Regards,
>> Charlie P.
>>
>>
>> On 7/2/2012 4:39 PM, Yoshihiro Ohba wrote:
>>
>>
>> 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
>>
>>
--
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