Re: [Mobopts] RG last call

[Jukka MJ Manner <[e-mail]>]

Hi all,

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

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.

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?

- 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?

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

  * 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.

  * 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.

  * 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?

  * 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?

- 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.

- Section 7:
  * [2]: As above, why is the Response needed in the first place?
  * [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.

- 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"?


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