RE: [STDS-802-21] Comments on 21-12-0067-01-srho-tgc-proposal
Hi, Charles,
Yes, I think we only need a single message type and two primitives,
one for sending and one for receiving. Link-layer frames are one-way
unreliable datagrams.
-Pete
Charles E. Perkins wrote:
>
> Hello Pete,
>
> In general, I am O.K. with removing .confirm, but I reckon the
> .response message would often be useful.
>
> Your point about generalizing the link-layer frame message to enable
> signaling unrelated to authentication is also valid I think. However,
> unless there is a particular case within the jurisdiction of 802.21
> for doing so, I'm not sure if there is any process that we could
> charter for that purpose.
>
> If you mean to say that we only need a single message for any generic
> cross-domain link-layer communication, I'm intrigued but haven't spent
> enough time thinking about it to decide. Do you think we should have
> a discussion about it?
>
> Regards,
> Charlie P.
>
> On 7/3/2012 11:13 AM, Peter McCann 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
>>>
>>>
>
>