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
>