Unified Layer 2 (L2) Abstractions for Layer 3 (L3)-Driven Fast Handover
draft-irtf-mobopts-l2-abstractions-07
Yes
No Objection
(Chris Newman)
(Cullen Jennings)
(David Ward)
(Lisa Dusseault)
(Magnus Westerlund)
(Mark Townsley)
(Ron Bonica)
(Ross Callon)
(Russ Housley)
(Tim Polk)
Note: This ballot was opened for revision 07 and is now closed.
Jari Arkko Former IESG member
(was No Record, Yes)
Yes
Yes
(2007-11-22)
Unknown
I do not see a conflict with ongoing IETF work, though discussion of similar additional information to help mobile nodes has been happening in the DHC, DNA, and MIPSHOP WGs, and in the IEEE 802.21 group. In addition, RFC 4957 was published about a subset of this interface from the DNA WG. Comments: My personal opinion though is that the presented interfaces are not very practical -- not that this is a requirement for research work. So, further work would be needed to actually use these in the the real world or standardize them. To be usable the interfaces would have to be substantially more well specified. For instance, RFC 4957 focused on one event for one purpose, and it turned out that the interactions are far from trivial. For instance, the document does not deal with the intricacies related to what it means to be associated with another wireless end point. For instance, on 802.11 having an association, having completed RSN, and having an IP address are all different situations. Nits: 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".
Chris Newman Former IESG member
No Objection
No Objection
()
Unknown
Cullen Jennings Former IESG member
No Objection
No Objection
()
Unknown
Dan Romascanu Former IESG member
No Objection
No Objection
(2007-11-29)
Unknown
1. The issue is partially dealt with in Tim's DISCUSS. It is not clear to me whether the following statement made twice in the Security Considerations section is sufficient: > Our proposal is nor more insecure than a particular link layer on which it is implemented The proposal is for signaling between L2 and L3. If so, why does this phrase make mention of the particular link layer? Note that if indeed we are dealing with threats for signalling transported over a link layer there are sufficient reasons of concern and the simple reference to RFC 4907 may not be enough. In fact link layer security is ensured by mechanisms like IEEE 802.1AE and these should be explictly refered. 2. Should this document result into IETF standards track work I would have questions about the usage or some link layer specific terms. For example I am not sure whether the LinkUp and LinkDown terms are aligned with the RFC 2863 terminology. At this phase, this being an RFC Editor track Informational document I will not insist.
David Ward Former IESG member
No Objection
No Objection
()
Unknown
Lars Eggert Former IESG member
No Objection
No Objection
(2007-11-28)
Unknown
This document is mostly harmless, but also at least partially useless. Some indications it defines go in the right direction (link up/down), but especially the stuff about link quality is so underdefined that it can't be used for anything: What should the stack do when link quality goes from GOOD to FAIR? What does that even mean? If my 802.11 link is FAIR but my 3G link is GOOD, do I hand over? Even for the link up/down indications, it isn't even clear if "link up" means if we have an IP address or not.
Lisa Dusseault Former IESG member
No Objection
No Objection
()
Unknown
Magnus Westerlund Former IESG member
No Objection
No Objection
()
Unknown
Mark Townsley Former IESG member
No Objection
No Objection
()
Unknown
Ron Bonica Former IESG member
No Objection
No Objection
()
Unknown
Ross Callon Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
No Objection
No Objection
()
Unknown
Tim Polk Former IESG member
(was No Record, Discuss)
No Objection
No Objection
(2007-11-29)
Unknown
This document points to iab-link-indications as the basis for the its brief security considerations, but I am not convinced that the points raised in that 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. I believe 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.