Re: [Mobopts] RG last call

Thanks Jukka.

A brief comment about the experiments: being an RG, we need exposure to
them. So, we should include them appropriately, such as in an Appendix. But,
I also agree that the system description has to be adequately provided so
that folks know what to expect.

Regards,

-Rajeev

On 10/20/06 1:17 AM, "ext Jukka MJ Manner" <jmanner@cs.Helsinki.FI> wrote:

> 
> 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
>> Mobopts@irtf.org
>> https://www1.ietf.org/mailman/listinfo/mobopts
>> 

_______________________________________________
Mobopts mailing list
Mobopts@irtf.org
https://www1.ietf.org/mailman/listinfo/mobopts