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

["Rajeev Koodli" <[e-mail]>]

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