[Mobopts] Re: draft-irtf-mobopts-l2-abstractions-04.txt comments

Jari,

Thanks for comments. Replies are inline:

At 08/01/09 15:36 +0200, Jari Arkko wrote:
(snip)

>> We modified the document as follows:
>>
>> - Sec. 4.5 L2-LinkUp (Type 2):
>>   - old: The L2-LinkUp.indication primitive is asynchronously provided to
>>          an upper layer when a new link is connected.
>>
>>   - new: The L2-LinkUp.indication primitive is asynchronously provided to
>>          an upper layer when a new link is connected and IP packets can be
>>          transmitted through the new link. As described in RFC 4957[7],
>>          what "link is connected" means depends on link types. 
>
>Good.
>
>>  For example,
>>          in case of the infrastructure mode in IEEE802.11 (WiFi), this
>>          primitive is provided when an association to an access point is
>>          established.
>>   
>
>Really? I was under the impression that association was an early phase
>and you would need to wait for something else if security was applied. I
>could be mistaken, but this discussion is an example of the sort of
>detail level that a fully defined interface would have to go to.

In my understanding of the IEEE802.11 infrastructure mode, at first,
a mobile node is in Unauthenticated & Unassociated State. Next,
the mobile node is authenticated and then the state changes to
Authenticated & Unassociated State. Finally, an association is
established with the AP and then the state changes to Authenticated
and Associated state. Thus, we defined that L2-LinkUp is provided
when an association is established in WiFi.

(snip)

>> The quality levels of a device are independent of those of other devices.
>> We added sentences at the last of "Sec. 6.2 Condition" as follows:
>>
>>   The quality levels of a L2 device are independent of those of other
>>   devices.  An example of the thresholds among the five levels are described
>>   in Appendix E.
>>
>> We also added the description about the example thresholds in Appendix E.
>>   
>
>The added text is good, but I'm still not convinced that you have a
>generic solution capable of operating in different conditions. It might
>be more useful to simply acknowledge that making decisions based on
>these metrics is error prone and not guaranteed to result in optimal
>choice of links.

I agree that "decisions based on these metrics is error prone and
not guaranteed to result in optimal choice of links."
I'll attend this sentence at the last of "6.2 Condition".

(snip)

Best Regards,

Fumio Teraoka 

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