Unified Layer 2 (L2) Abstractions for Layer 3 (L3)-Driven Fast Handover
RFC 5184
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2017-05-16 |
07 | (System) | Changed document authors from "Fumio Teraoka" to "Fumio Teraoka, Koshiro Mitsuya, Kazutaka Gogo, Rie Shibui, Koki Mitani" |
2015-10-14 |
07 | (System) | Notify list changed from tera@ics.keio.ac.jp, draft-irtf-mobopts-l2-abstractions@ietf.org, rajeev.koodli@nsn.com to rajeev.koodli@nsn.com |
2012-08-22 |
07 | (System) | post-migration administrative database adjustment to the No Objection position for Tim Polk |
2008-05-30 |
07 | Cindy Morgan | State Changes to RFC Published from RFC Ed Queue by Cindy Morgan |
2008-05-30 |
07 | Cindy Morgan | [Note]: 'RFC 5184' added by Cindy Morgan |
2008-05-29 |
07 | (System) | RFC published |
2008-04-16 |
07 | Amy Vezza | State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza |
2008-04-09 |
07 | (System) | IANA Action state changed to No IC from In Progress |
2008-04-09 |
07 | (System) | IANA Action state changed to In Progress |
2008-04-08 |
07 | Amy Vezza | IESG state changed to Approved-announcement sent |
2008-04-08 |
07 | Amy Vezza | IESG has approved the document |
2008-04-08 |
07 | Amy Vezza | Closed "Approve" ballot |
2008-02-20 |
07 | (System) | New version available: draft-irtf-mobopts-l2-abstractions-07.txt |
2008-02-07 |
06 | (System) | New version available: draft-irtf-mobopts-l2-abstractions-06.txt |
2008-01-07 |
05 | (System) | New version available: draft-irtf-mobopts-l2-abstractions-05.txt |
2007-11-29 |
07 | Amy Vezza | State Changes to Approved-announcement to be sent from IESG Evaluation by Amy Vezza |
2007-11-29 |
07 | Tim Polk | [Ballot comment] 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 … [Ballot comment] 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. |
2007-11-29 |
07 | Tim Polk | [Ballot Position Update] Position for Tim Polk has been changed to No Objection from Undefined by Tim Polk |
2007-11-29 |
07 | Tim Polk | [Ballot Position Update] Position for Tim Polk has been changed to Undefined from Discuss by Tim Polk |
2007-11-29 |
07 | David Ward | [Ballot Position Update] New position, No Objection, has been recorded by David Ward |
2007-11-29 |
07 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica |
2007-11-29 |
07 | Dan Romascanu | [Ballot Position Update] New position, No Objection, has been recorded by Dan Romascanu |
2007-11-29 |
07 | Dan Romascanu | [Ballot comment] 1. The issue is partially dealt with in Tim's DISCUSS. It is not clear to me whether the following statement made twice in … [Ballot comment] 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. |
2007-11-29 |
07 | Mark Townsley | [Ballot Position Update] New position, No Objection, has been recorded by Mark Townsley |
2007-11-29 |
07 | Chris Newman | [Ballot Position Update] New position, No Objection, has been recorded by Chris Newman |
2007-11-28 |
07 | Ross Callon | [Ballot Position Update] New position, No Objection, has been recorded by Ross Callon |
2007-11-28 |
07 | Amanda Baber | IANA Evaluation comments: This document has NO IANA Considerations section. We understand this document request NO actions from IANA. |
2007-11-28 |
07 | Tim Polk | [Ballot discuss] 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 … [Ballot discuss] 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. |
2007-11-28 |
07 | Tim Polk | [Ballot discuss] 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 … [Ballot discuss] 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" I believe that the treatment of spoofing and denial of service should be expanded in the security considerations section. |
2007-11-28 |
07 | Tim Polk | [Ballot Position Update] New position, Discuss, has been recorded by Tim Polk |
2007-11-28 |
07 | Magnus Westerlund | [Ballot Position Update] New position, No Objection, has been recorded by Magnus Westerlund |
2007-11-28 |
07 | Lars Eggert | [Ballot comment] This document is mostly harmless, but also at least partially useless. Some indications it defines go in the right direction (link up/down), but … [Ballot comment] 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. |
2007-11-28 |
07 | Lars Eggert | [Ballot Position Update] New position, No Objection, has been recorded by Lars Eggert |
2007-11-27 |
07 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded by Russ Housley |
2007-11-25 |
07 | Cullen Jennings | [Ballot Position Update] New position, No Objection, has been recorded by Cullen Jennings |
2007-11-23 |
07 | Lisa Dusseault | [Ballot Position Update] New position, No Objection, has been recorded by Lisa Dusseault |
2007-11-22 |
07 | Jari Arkko | [Ballot comment] I do not see a conflict with ongoing IETF work, though discussion of similar additional information to help mobile nodes has been happening … [Ballot comment] 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". |
2007-11-22 |
07 | Jari Arkko | [Ballot comment] I do not see a conflict with ongoing IETF work, though discussion of additional information to help mobile nodes has been happening in … [Ballot comment] I do not see a conflict with ongoing IETF work, though discussion of 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 problem 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. 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". |
2007-11-22 |
07 | Jari Arkko | [Ballot comment] I do not see a conflict with ongoing IETF work, though discussion of additional information to help mobile nodes has been happening in … [Ballot comment] I do not see a conflict with ongoing IETF work, though discussion of 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 problem 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. 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. |
2007-11-22 |
07 | Jari Arkko | [Ballot comment] I do not see a conflict with ongoing IETF work, though discussion of additional information to help mobile nodes has been happening in … [Ballot comment] I do not see a conflict with ongoing IETF work, though discussion of 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 problem 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. 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: Draft-iab-link-indications has been published as RFC 4907. |
2007-11-22 |
07 | Jari Arkko | [Ballot Position Update] Position for Jari Arkko has been changed to Yes from Undefined by Jari Arkko |
2007-11-22 |
07 | Jari Arkko | [Ballot comment] I do not see a conflict with ongoing IETF work, though discussion of additional information to help mobile nodes has been happening in … [Ballot comment] I do not see a conflict with ongoing IETF work, though discussion of 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 problem from the DNA WG. My personal opinion though is that the presented interfaces are not very practical -- not that this is a requirement for research work. 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. Nits: Draft-iab-link-indications has been published as RFC 4907. |
2007-11-22 |
07 | Jari Arkko | Area acronymn has been changed to int from gen |
2007-11-22 |
07 | Jari Arkko | Intended Status has been changed to Experimental from None |
2007-11-22 |
07 | Jari Arkko | [Ballot Position Update] Position for Jari Arkko has been changed to Undefined from Yes by Jari Arkko |
2007-11-22 |
07 | Jari Arkko | [Ballot Position Update] New position, Yes, has been recorded for Jari Arkko |
2007-11-22 |
07 | Jari Arkko | Ballot has been issued by Jari Arkko |
2007-11-22 |
07 | Jari Arkko | Created "Approve" ballot |
2007-11-22 |
07 | (System) | Ballot writeup text was added |
2007-11-22 |
07 | (System) | Last call text was added |
2007-11-22 |
07 | (System) | Ballot approval text was added |
2007-11-22 |
07 | Jari Arkko | Draft Added by Jari Arkko in state IESG Evaluation |
2007-11-22 |
07 | Jari Arkko | [Note]: 'This is an IRTF submission' added by Jari Arkko |
2007-08-24 |
04 | (System) | New version available: draft-irtf-mobopts-l2-abstractions-04.txt |
2007-05-08 |
03 | (System) | New version available: draft-irtf-mobopts-l2-abstractions-03.txt |
2007-02-21 |
02 | (System) | New version available: draft-irtf-mobopts-l2-abstractions-02.txt |
2006-09-26 |
01 | (System) | New version available: draft-irtf-mobopts-l2-abstractions-01.txt |
2006-07-28 |
00 | (System) | New version available: draft-irtf-mobopts-l2-abstractions-00.txt |