Re: [Mobopts] RG last call

[Koshiro MITSUYA <[e-mail]>]

Hi Jukka,

I am sorry for the delayed reply.
Please find my comment inline:


On 2006/10/20, at 17:17, Jukka MJ Manner wrote:

>
> Hi all,
>
> I promised Rajeev to give a review of the draft, so here goes.

Thank you!


> In overall, I liked the document. Yet, I would remove all the sections
> (Appendix B.3 and D) that discuss the experiments, since those are
> difficult to verify, and do not really provide any important  
> information,
> just that the scheme seems to work in some use case.
>

We thought these appendixes will help reader to understand our proposal.
However, I agree with you.  I will remove.


> Some more detailed comments:
>
> - Section 3 does not really discuss the Response primitive. In  
> general,
>   what is the use of the Response? Why would L3 really need to  
> acknowledge
>   an asynchronous Indication from L2?

I do not see any strong reason now, but I would keep the Response for  
future usage.

One of our architectural feature is that all message (command and  
indication) go
through the same inter-layer communication method.  It is possible to  
e.g.
accept the handover command after receiving the response of ToBeDown  
indication.


> - Section 4:
>
>   * is the proposal only for so-called Managed Mode (AP mode)
>     link layers? How would this be applicable to ad-hoc or mesh  
> radios?
>     E.g., would L2-PeerList provide info about only L2 APs, but  
> also other
>     terminals? Would L2-LinkUp/Down tell which links to other ad- 
> hoc nodes
>     are up/down?

Some primitives may work on ad-hoc mode.  However, ad-hoc mode or
mesh is out of scope so far.  If WG requests, we can work on the study.


>   * How do channels come into play? Does the L2-PeerList allow getting
>     peers on different channels? Can L3 somehow control the use of
>     channels?
>

Yes, L2-PeerList allow to get peers on different channels.
However, L3-* do not need to play with channels.
L3 specify a Peer, and L2 understand which channel the Peer is using.


>   * After reading the whole spec, you actually later talk about  
> quality of
>     the signal in relation to the L2-PeerFound, i.e., only certain  
> peers
>     are told about to L3. That is not mentioned in Section 4.

Sorry, I don't see your point.


>   * Related to the above, and other requests, would there be a need to
>     define some filters about which notifications are of interest?  
> E.g.
>     the above, a peer is announced only if the quality of the link  
> to the
>     peer is of some relative quality.

Same here.  Could you explain explain more?


>   * L2-PeerLost: provide info about which peers disappeared, but since
>     when? Does L2 e.g. send a notification every second, and tell  
> which
>     peers disappeared within the past second? Or everytime there is  
> even a
>     one peer change in the list?

We assume that L2 creates and maintains a list of APs when it  
performs scanning.
When It performs scanning again, the comparing is performed and a  
notification
is sent if needed.  The timing of scanning is  implementation issues.


>   * Is there any need to add some kind of security awareness to the
>     primitives, i.e., is the link secure or not (how secure?)?  
> E.g., to
>     the link status primitive, or to a filter associated to the  
> PeerFound?

I would hear the WG voice :)


> - Section 6.2 Condition: should the SNR be also provided? What is this
>   "available bandwidth? If we talk about 802.11, if the link layer  
> says I
>    have full 54 Mbps connectivity, everybody knows that is about  
> half the
>    actual bandwidth I get for my IP packets.

It is out of scope in our spec.
Such information is very useful for transport or application,
but not so useful for L3.


> - Section 7:
>   * [2]: As above, why is the Response needed in the first place?

see above.

>   * [5]: You don't need congestion control in the transport, but you
>          surely need rate limitation for how often indications are  
> sent
>          from L2 to L3.
>

Good point.   I will add a text to mention this.


> - Appendix A, p.20, 2nd sentence: I think the L2 and L3 are mixed: "L2
>   handover begins after the L2 sends L2-LinkConnect.confirm to the  
> L3."
>
>
> - C.4: "is got lost"
>
> - C.6: "...frame to the AP, or the" > "...frame to the AP, and the" ?
>
> - C.7: "...and becomes under" > "...and falls unders"?
>

Thank you.   I will fix them!

regards,
Koshiro


>
> Hope these comments help.
>
> Regards,
> Jukka
>
> On Tue, 3 Oct 2006, Rajeev Koodli wrote:
>
>>
>> Folks,
>>
>> This is the last call for comments on
>>
>> draft-irtf-mobopts-l2-abstractions-01.txt
>>
>> The last call expires on October 20, 06.
>>
>> Please provide your input by then.
>>
>> Thanks,
>>
>> -Rajeev
>>
>>
>>
>> _______________________________________________
>> Mobopts mailing list
>> [e-mail]
>> https://www1.ietf.org/mailman/listinfo/mobopts
>>
>
> _______________________________________________
> Mobopts mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/mobopts


_______________________________________________
Mobopts mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/mobopts