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

From: Jari Arkko <[email-masked]>
Date: Thu, 13 Dec 2007 23:35:58 +0200

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/mobopts

---

From: "Rajeev Koodli" <[email-masked]>
Date: Fri, 14 Dec 2007 20:43:35 -0800

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

---

From: Fumio Teraoka <[email-masked]>
Date: Mon, 17 Dec 2007 23:57:48 +0900

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