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

[Fumio Teraoka <[e-mail]>]

Dear Rajeev Koodli and Jari Arkko,

We will revise the document at Rajeev's suggestion.
Since we don't have enough time now, please wait for
1 or 2 weeks.

Regards,
Fumio Teraoka

At 07/12/14 20:43 -0800, Rajeev Koodli wrote:
>Dear Authors,
>
>please address Jari's comments. I see at least two directions:
>
>1. provide clarifications and add some descriptions about the
>interface Jari is referring to. I know you have built a working
>system. So, it should be relatively straightforward to provide some
>additional description.
>
>2. Identify what needs further work or could be improved.
>
>Perhaps you can do both 1) and 2).
>
>Jari: I hope we can do this during the AUTH48 stage. Anything else
>that requires further work is perhaps another ID I guess.
>
>Regards,
>
>-Rajeev
>
>
>On 12/13/07, Jari Arkko <[e-mail]> wrote:
>>
>> FYI -- this document was on the IESG telechat a few weeks ago for the
>> does-not-conflict-with-WG-efforts check. The IESG had no problem in
>> publishing it.
>>
>> However, I also read the document for its technical content and wanted
>> post a personal opinion, as well as copy you on the some comments that
>> we received from other ADs during the review.
>>
>> Basically, I believe the specification of the interface is not detailed
>> enough to be implemented in the general case. Not that this is a
>> requirement for research work, but I hope no one thinks the work is now
>> done.
>>
>> For example, even after re-reading the document and its appendix, it is
>> unclear to me how the document proposes dealing with the intricacies
>> related to what it means to be associated with a wireless end point. In
>> 802.11 having an association, having completed EAP/RSN, and having a
>> working IP interface are all different things. Presumably one would
>> prefer getting an indication when authentication and all required link
>> layer tasks complete, but the document does not say this. Link layer
>> fast handoff designs, web authentication, firewalls, etc complicate this
>> further.
>>
>> Another example is the use of the link quality indicators. They appear
>> simple, but their use is far from trivial. Would you move from FAIR
>> 802.11n to EXCELLENT 802.11b? What about BAD 802.11 to GOOD GPRS?
>>
>> To be usable the interfaces would have to have many of these details
>> worked out. For instance, RFC 4957 focused on one event for one purpose,
>> and it turned out that the interactions are far from trivial.
>>
>> In addition, Tim Polk was not convinced that the points raised in IAB
>> link indications document were adequately addressed. For example,
>> iab-link-indications notes for spoofing attacks: "However, even where
>> the link layer incorporates security, attacks may still be possible if
>> the security model is not consistent." Yet this document addresses
>> spoofing with a single sentence: " "Our proposal is nor more insecure
>> than a particular link layer on which it is implemented". These
>> statements appear to be a contradiction.  Tim believed that the
>> treatment of spoofing
>> and denial of service should be expanded in the security considerations
>> section to clearly demonstrate the issues raised in iab-link-indications
>> have been fully addressed.
>>
>> Also, Dan Romascanu had questions about the usage or some link layer
>> specific terms. For example he was not sure whether the LinkUp and
>> LinkDown terms are aligned with the RFC 2863 terminology.
>>
>> Finally, some editorial issues:
>>
>> The document would probably benefit from a reference to RFC 4957.
>>
>> Draft-iab-link-indications has been published as RFC 4907.
>>
>> Author's name in [7] should be "Aboba", not "Adoba".
>>
>> Jari
>>
>>
>> _______________________________________________
>> Mobopts mailing list
>> [e-mail]
>> https://www1.ietf.org/mailman/listinfo/mobopts
>>


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