RE: [STDS-802-21] Comments on 21-12-0067-01-srho-tgc-proposal
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
>
>