IPv6 Deployment Scenarios in 802.16 Networks
RFC 5181
Revision differences
Document history
| Date | Rev. | By | Action |
|---|---|---|---|
|
2017-05-16
|
07 | (System) | Changed document authors from "Myung-Ki Shin" to "Myung-Ki Shin, Sang-Eon Kim, Youn-Hee Han, Domagoj Premec" |
|
2015-10-14
|
07 | (System) | Notify list changed from v6ops-chairs@ietf.org to (None) |
|
2012-08-22
|
07 | (System) | post-migration administrative database adjustment to the No Objection position for Tim Polk |
|
2012-08-22
|
07 | (System) | post-migration administrative database adjustment to the No Objection position for Dan Romascanu |
|
2012-08-22
|
07 | (System) | post-migration administrative database adjustment to the No Objection position for Russ Housley |
|
2008-05-09
|
07 | Cindy Morgan | [Note]: 'RFC #5181' added by Cindy Morgan |
|
2008-05-09
|
07 | Cindy Morgan | State Changes to RFC Published from RFC Ed Queue by Cindy Morgan |
|
2008-05-09
|
07 | (System) | RFC published |
|
2008-04-15
|
07 | Amy Vezza | State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza |
|
2008-04-14
|
07 | (System) | IANA Action state changed to No IC from In Progress |
|
2008-04-14
|
07 | (System) | IANA Action state changed to In Progress |
|
2008-04-14
|
07 | Amy Vezza | IESG state changed to Approved-announcement sent |
|
2008-04-14
|
07 | Amy Vezza | IESG has approved the document |
|
2008-04-14
|
07 | Amy Vezza | Closed "Approve" ballot |
|
2008-04-11
|
07 | Ron Bonica | State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Ron Bonica |
|
2008-04-09
|
07 | Tim Polk | [Ballot Position Update] Position for Tim Polk has been changed to No Objection from Undefined by Tim Polk |
|
2008-04-09
|
07 | Tim Polk | [Ballot Position Update] Position for Tim Polk has been changed to Undefined from Discuss by Tim Polk |
|
2008-04-07
|
07 | Dan Romascanu | [Ballot Position Update] Position for Dan Romascanu has been changed to No Objection from Discuss by Dan Romascanu |
|
2008-02-28
|
07 | Jari Arkko | [Ballot Position Update] Position for Jari Arkko has been changed to Yes from No Objection by Jari Arkko |
|
2008-02-28
|
07 | Jari Arkko | [Ballot comment] |
|
2008-02-28
|
07 | Jari Arkko | [Ballot Position Update] Position for Jari Arkko has been changed to No Objection from Discuss by Jari Arkko |
|
2008-02-28
|
07 | Jari Arkko | [Ballot discuss] |
|
2008-02-21
|
07 | Russ Housley | [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss by Russ Housley |
|
2008-01-28
|
07 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
|
2008-01-28
|
07 | (System) | New version available: draft-ietf-v6ops-802-16-deployment-scenarios-07.txt |
|
2008-01-24
|
07 | Amy Vezza | State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Amy Vezza |
|
2008-01-24
|
07 | Lisa Dusseault | [Ballot Position Update] New position, No Objection, has been recorded by Lisa Dusseault |
|
2008-01-24
|
07 | Magnus Westerlund | [Ballot Position Update] New position, No Objection, has been recorded by Magnus Westerlund |
|
2008-01-23
|
07 | David Ward | [Ballot comment] I put no object only because others have covered my concerns and I will let them carry the discusses |
|
2008-01-23
|
07 | David Ward | [Ballot Position Update] New position, No Objection, has been recorded by David Ward |
|
2008-01-23
|
07 | Ross Callon | [Ballot Position Update] New position, No Objection, has been recorded by Ross Callon |
|
2008-01-23
|
07 | (System) | State Changes to IESG Evaluation from IESG Evaluation - Defer by system |
|
2008-01-20
|
07 | Cullen Jennings | [Ballot Position Update] New position, No Objection, has been recorded by Cullen Jennings |
|
2008-01-11
|
07 | (System) | Removed from agenda for telechat - 2008-01-10 |
|
2008-01-10
|
07 | Samuel Weiler | Request for Telechat review by SECDIR Completed. Reviewer: Julien Laganier. |
|
2008-01-10
|
07 | Ron Bonica | [Ballot comment] These comments from Bert Wijnen: Here are my comments: - Security Considerations section points to sect 2.5 But that section only concludes … [Ballot comment] These comments from Bert Wijnen: Here are my comments: - Security Considerations section points to sect 2.5 But that section only concludes that But, we do not have PKIs across organizations and IPsec is not integrated with IEEE 802.16 network mobility management. IEEE 802.16 network threats may be different from IPv6 and IPv6 transition threat models [RFC4942]. It should be also discussed I wonder if this is acceptable. nits/TYPOS: - SECTION 1.1, first bullet: o Base Station (BS): A generalized equipment sets providing connectivity, management, and control between the subscriber station and the 802.16 networks. s/sets/set/ ?? At least to my ear - Pls expand acronyms the furst time they are used. Examples are DAD, MN - Section 2.6 talks about 3 connections. The first is the "base connection", then it speaks about "primary" and "secondary" connections. It feels somewhat strange to consider the 2nd connection the "primary" and the 3rd connection the "secondary". It is not tstated that way... but I had to read a few times to understand what was meant. Maybe the text can be improved? - 3rd para in section 2.6 IPv6 based IEEE 802.16 networks can be managed by IPv4 or IPv6 when network elements are implemented dual stack. For example, network I think I would s/managed by/manager over/ or s/managed by/managed via/ - same 3rd para of section 2.6 related object identifiers. Also, an NMS can use IPv6 for SNMP requests and responses including IPv4 related OID. Not sure I understand what is meant with "IPv4 related OID." ??? - IDnits states: == Outdated reference: A later version (-04) exists of draft-ietf-16ng-ps-goals-03 Bert Wijnen |
|
2008-01-10
|
07 | Mark Townsley | State Changes to IESG Evaluation - Defer from IESG Evaluation by Mark Townsley |
|
2008-01-10
|
07 | Tim Polk | [Ballot discuss] As noted in Julien Laganier's secdir review, there are some problems with the current text on security, as well as the security considerations … [Ballot discuss] As noted in Julien Laganier's secdir review, there are some problems with the current text on security, as well as the security considerations section. Section 2.5 IPv6 Security It would be helpful if the implications for paragraphs one and two were spelled out. Paragraph three needs to move to security considerations and the discussion added. Paragraph 1: When initiating the connection, an MS is authenticated by the AAA server located at its service provider network. All the parameters related to authentication (username, password and etc.) are forwarded by the BS to the AAA server. The AAA server authenticates the MSs and when an MS is once authenticated and associated successfully with BS, IPv6 an address will be acquired by the MS through stateless autoconfiguration or DHCPv6. Note the initiation and authentication process is the same as used in IPv4. This implies that one important aspect of security for IPv6 over 802.16 is that authentication of an MS is required before an IPv6 address is assigned. If that is the point, it would be helpful if was stated explicitly. I am no 802.16 expert, but I understand there are some scenarios where both user and device authentication are incorporated in a deployment scenario. Are any of these scenarios viable for IPv6, or are we restricted to device authentication only? The security implications are very different in these cases... It might also be helpful to note that a wide range of authentication mechanisms are in use, and that very different levels of assurance may be achieved. This probably be relegated to the security considerations section. Paragraph 2: IPsec is a fundamental part of IPv6. Unlike IPv4, IPsec for IPv6 may be used within the global end-to-end architecture. But, we do not have PKIs across organizations and IPsec is not integrated with IEEE 802.16 network mobility management. I assume the authors saying that end-to-end security is obviously out of scope, but can be achieved using IPsec (with the noted practical limitations.) Again, if that is the case it would be helpful to be more explicit. What isn't stated is the degree of security that is (or can be) achieved within the scope of the 802.16 deployment scenarios. One could argue that would be more appropriate in the security considerations section, but it should probably go somewhere. Paragraph 3: IEEE 802.16 network threats may be different from IPv6 and IPv6 transition threat models [RFC4942]. It should be also discussed. This is really important, and deserves an expanded treatment in the security considerations section. To paraphrase RFC 3552, the security considerations section needs to describe how the IPv6 threat models are impacted: Does it change the attacks that are in or out of scope, increase susceptibility to certain attacks, or provide provide any new protections against those attacks? [If these topics are covered adequately in the security considerations of other RFCs, or in publicly available document from other SDOs, then references are sufficient. I didn't find them myself.] |
|
2008-01-10
|
07 | Tim Polk | [Ballot Position Update] New position, Discuss, has been recorded by Tim Polk |
|
2008-01-10
|
07 | Jari Arkko | [Ballot discuss] This document is needed and should be published, but given that work on it started a long time ago, it is now out … [Ballot discuss] This document is needed and should be published, but given that work on it started a long time ago, it is now out of sync with some of the actual specifications for running IP over 802.16. Please correct the following: > The mechanism of transporting IP traffic over IEEE 802.16 networks is > outlined in [IEEE802.16]. [IEEE802.16] only specifies the > convergence sublayers and the ability to transport IP over the air > interface. The details of IPv6 (and IPv4) operations over IEEE > 802.16 are being discussed now in the 16ng WG. The first sentence seems contradictory to the fact that 16ng defines "IP over 802.16". Please drop the first sentence, and indicate in the second sentence that the IPv6 over IPCS definition is already an approved specification (currently in RFCEd queue); the above text makes it sound the matter is still being discussed. > Some architectural characteristics of IEEE 802.16 networks > may affect the detailed operations of NDP (Neighbor Discovery > Protocol) [RFC4861], [RFC4862]. ... > If stateless auto-configuration is used to get an IPv6 address, > router discovery and DAD operation should be properly operated over > IEEE 802.16 links. In case of the shared IPv6 prefix link model, the > DAD (Duplicate Address Detection) [RFC4861] does not adapt well to > the 802.16 air interface as there is no native multicast support. An > optimization, called Relay DAD, may be required to perform DAD. > However, in case of the point-to-point link model, DAD is easy since > each connection to a MN is treated as a unique IPv6 link. All the above is out of sync with what the 16NG WG eventually decided to do. They only support the p2p link model. They will later also publish an RFC how to support IP over Ethernet mode in 802.16, but this is expected to operate using standard mechanisms (bridging, mld snooping, etc). Please align this document to the current models in 16NG. > In this scenario, IEEE 802.16 > BSs have only MAC and PHY layers without router functionality and > operate as a bridge. The BS should support IPv6 classifiers as > specified in [IEEE802.16]. However, if IPv4 stack is loaded to them > for management and configuration purposes, it is expected that BS > should be upgraded by implementing IPv6 stack, too. Its not clear to me why we need to recommend upgrading the management network in conjunction of IPv6 support. Indeed, as the experiences from cable world show, the two can be upgraded independently and for different reasons. > Under fixed access model, the IEEE 802.16 BS will be deployed using > an IP backbone rather than a proprietary backend like cellular > systems. Thus, many IPv6 functionalities such as [RFC4861], > [RFC4862] will be preserved when adopting IPv6 to IEEE 802.16 > devices. Cellular systems are these days running on IP backbones. The word proprietary is not an appropriate characterization today, or even during the previous generation of systems. In any case, this document talks about 802.16, which will always be deployed on an IP backbone. Finally, the approved 16NG IPv6 document specifies the use 4861 and 4862 as-is (well, some timing parameters are adopted, but that is something that IP over Foo specs can do) for 802.16. Please delete this text. > Fixed/Nomadic Deployment Scenarios I am confused by the contents of this section. Is this talking about the Ethernet CS, or the application of any 802.16 technology in a particular business setting? I get the feeling that its the latter, but if so, much of the content in this section is incorrect. I would recommend talking about specific CS and deployment model. > 2.2.2.3. IPv6 Transport > > Note that in this scenario Ethernet CS > [I-D.ietf-16ng-ip-over-ethernet-over-802.16] may be more appropriate > than IPv6 CS [I-D.ietf-16ng-ipv6-over-ipv6cs] to transport IPv6 > packets, since the scenario needs to support plain Ethernet end-to- > end connectivity. However, the IPv6 CS can also be supported. The > MS and BS will consider the connections between the peer IP CSs at > the MS and BS to form a point to point link. In the Ethernet CS > case, an Ethernet bridge may provide implementation of an > authoritative address cache and Relay DAD. An Authoritative address > cache is a mapping between the IPv6 address and the MAC addresses of > all attached MSs. > > The bridge builds its authoritative address cache by parsing the IPv6 > Neighbor Discovery messages used during address configuration (DAD). > Relay DAD means that the Neighbor Solicitation message used in the > DAD process will be relayed only to the MS which already has > configured the solicited address as its own address (if such an MS > exist at all). Again, this does not seem to be in line with what the 16NG WG recommends. Please delete. > 2.2.2.5. Mobility > > No mobility functions are supported in the fixed access scenario. > However, mobility can be supported in the radio coverage without any > mobility protocol like WLAN technology. Therefore, a user can access > Internet nomadically in the coverage. This seems incorrect in a number of ways: - I could not parse the second sentence. - Are you saying that the network can support mobility without hosts being aware (as is commonly done in WLAN)? Yes, but then the network needs those mobility features. Were you assuming they were available in the fixed deployment? If so, please state it. - Obviously, any host can implement host based mobility and move around, even if the network does not support this in any way > 2.3. IPv6 Multicast > > In IEEE 802.16 air link, downlink connections can be shared among > multiple MSs, enabling multicast channels with multiple MSs receiving > the same information from the BS. Multicast and Broadcast Service > (MBS) may be used to efficiently implement multicast. However, it is > not clear how to do this, as currently CID is assigned by BS, but in > MBS it should be done at an AR and it's network scope. It is not > clear how this mapping will happen for MBS, so MBS discussions have > been postponed in WiMax for now. Note that it should be intensively > researched later, since MBS will be one of the killer services in > IEEE 802.16 networks. > > In order to support multicast services in IEEE 802.16, Multicast > Listener Discovery (MLD) [RFC2710] must be supported between the MS > and AR. Also, the inter-working with IP multicast protocols and MBS > should be considered. > > MBS defines Multicast and Broadcast Services, but actually, MBS seems > to be a broadcast service, not multicasting. MBS adheres to > broadcast services, while traditional IP multicast schemes define > multicast routing using a shared tree or source-specific tree to > deliver packets efficiently. > > In IEEE 802.16 networks, two types of access to MBS may be supported: > single-BS access and multi-BS access. Therefore, these two types of > services may be roughly mapped into Source-Specific Multicast. This section should make it clear that multicast as already defined works for 802.16 and IPv6. Its really very similar to how multicast works in bridged Ethernet networks. However, the more efficient MBS transmission has not been standardized, its integration to how IP works has not been defined, etc. Just state that its work in progress rather than try to specify all the above details. |
|
2008-01-10
|
07 | Jari Arkko | [Ballot comment] > IPsec is a fundamental part of IPv6. Unlike IPv4, IPsec for IPv6 may > be used within the global end-to-end architecture. But, … [Ballot comment] > IPsec is a fundamental part of IPv6. Unlike IPv4, IPsec for IPv6 may > be used within the global end-to-end architecture. But, we do not > have PKIs across organizations and IPsec is not integrated with IEEE > 802.16 network mobility management. > > IEEE 802.16 network threats may be different from IPv6 and IPv6 > transition threat models [RFC4942]. It should be also discussed. These paragraphs did not provide much information. Consider deleting them. |
|
2008-01-10
|
07 | Jari Arkko | [Ballot discuss] > The mechanism of transporting IP traffic over IEEE 802.16 networks is > outlined in [IEEE802.16]. [IEEE802.16] only specifies the > convergence sublayers … [Ballot discuss] > The mechanism of transporting IP traffic over IEEE 802.16 networks is > outlined in [IEEE802.16]. [IEEE802.16] only specifies the > convergence sublayers and the ability to transport IP over the air > interface. The details of IPv6 (and IPv4) operations over IEEE > 802.16 are being discussed now in the 16ng WG. The first sentence seems contradictory to the fact that 16ng defines "IP over 802.16". Please drop the first sentence, and indicate in the second sentence that the IPv6 over IPCS definition is already an approved specification (currently in RFCEd queue); the above text makes it sound the matter is still being discussed. > Some architectural characteristics of IEEE 802.16 networks > may affect the detailed operations of NDP (Neighbor Discovery > Protocol) [RFC4861], [RFC4862]. ... > If stateless auto-configuration is used to get an IPv6 address, > router discovery and DAD operation should be properly operated over > IEEE 802.16 links. In case of the shared IPv6 prefix link model, the > DAD (Duplicate Address Detection) [RFC4861] does not adapt well to > the 802.16 air interface as there is no native multicast support. An > optimization, called Relay DAD, may be required to perform DAD. > However, in case of the point-to-point link model, DAD is easy since > each connection to a MN is treated as a unique IPv6 link. All the above is out of sync with what the 16NG WG eventually decided to do. They only support the p2p link model. They will later also publish an RFC how to support IP over Ethernet mode in 802.16, but this is expected to operate using standard mechanisms (bridging, mld snooping, etc). Please align this document to the current models in 16NG. > In this scenario, IEEE 802.16 > BSs have only MAC and PHY layers without router functionality and > operate as a bridge. The BS should support IPv6 classifiers as > specified in [IEEE802.16]. However, if IPv4 stack is loaded to them > for management and configuration purposes, it is expected that BS > should be upgraded by implementing IPv6 stack, too. Its not clear to me why we need to recommend upgrading the management network in conjunction of IPv6 support. Indeed, as the experiences from cable world show, the two can be upgraded independently and for different reasons. > Under fixed access model, the IEEE 802.16 BS will be deployed using > an IP backbone rather than a proprietary backend like cellular > systems. Thus, many IPv6 functionalities such as [RFC4861], > [RFC4862] will be preserved when adopting IPv6 to IEEE 802.16 > devices. Cellular systems are these days running on IP backbones. The word proprietary is not an appropriate characterization today, or even during the previous generation of systems. In any case, this document talks about 802.16, which will always be deployed on an IP backbone. Finally, the approved 16NG IPv6 document specifies the use 4861 and 4862 as-is (well, some timing parameters are adopted, but that is something that IP over Foo specs can do) for 802.16. Please delete this text. > Fixed/Nomadic Deployment Scenarios I am confused by the contents of this section. Is this talking about the Ethernet CS, or the application of any 802.16 technology in a particular business setting? I get the feeling that its the latter, but if so, much of the content in this section is incorrect. I would recommend talking about specific CS and deployment model. > 2.2.2.3. IPv6 Transport > > Note that in this scenario Ethernet CS > [I-D.ietf-16ng-ip-over-ethernet-over-802.16] may be more appropriate > than IPv6 CS [I-D.ietf-16ng-ipv6-over-ipv6cs] to transport IPv6 > packets, since the scenario needs to support plain Ethernet end-to- > end connectivity. However, the IPv6 CS can also be supported. The > MS and BS will consider the connections between the peer IP CSs at > the MS and BS to form a point to point link. In the Ethernet CS > case, an Ethernet bridge may provide implementation of an > authoritative address cache and Relay DAD. An Authoritative address > cache is a mapping between the IPv6 address and the MAC addresses of > all attached MSs. > > The bridge builds its authoritative address cache by parsing the IPv6 > Neighbor Discovery messages used during address configuration (DAD). > Relay DAD means that the Neighbor Solicitation message used in the > DAD process will be relayed only to the MS which already has > configured the solicited address as its own address (if such an MS > exist at all). Again, this does not seem to be in line with what the 16NG WG recommends. Please delete. > 2.2.2.5. Mobility > > No mobility functions are supported in the fixed access scenario. > However, mobility can be supported in the radio coverage without any > mobility protocol like WLAN technology. Therefore, a user can access > Internet nomadically in the coverage. This seems incorrect in a number of ways: - I could not parse the second sentence. - Are you saying that the network can support mobility without hosts being aware (as is commonly done in WLAN)? Yes, but then the network needs those mobility features. Were you assuming they were available in the fixed deployment? If so, please state it. - Obviously, any host can implement host based mobility and move around, even if the network does not support this in any way > 2.3. IPv6 Multicast > > In IEEE 802.16 air link, downlink connections can be shared among > multiple MSs, enabling multicast channels with multiple MSs receiving > the same information from the BS. Multicast and Broadcast Service > (MBS) may be used to efficiently implement multicast. However, it is > not clear how to do this, as currently CID is assigned by BS, but in > MBS it should be done at an AR and it's network scope. It is not > clear how this mapping will happen for MBS, so MBS discussions have > been postponed in WiMax for now. Note that it should be intensively > researched later, since MBS will be one of the killer services in > IEEE 802.16 networks. > > In order to support multicast services in IEEE 802.16, Multicast > Listener Discovery (MLD) [RFC2710] must be supported between the MS > and AR. Also, the inter-working with IP multicast protocols and MBS > should be considered. > > MBS defines Multicast and Broadcast Services, but actually, MBS seems > to be a broadcast service, not multicasting. MBS adheres to > broadcast services, while traditional IP multicast schemes define > multicast routing using a shared tree or source-specific tree to > deliver packets efficiently. > > In IEEE 802.16 networks, two types of access to MBS may be supported: > single-BS access and multi-BS access. Therefore, these two types of > services may be roughly mapped into Source-Specific Multicast. This section should make it clear that multicast as already defined works for 802.16 and IPv6. Its really very similar to how multicast works in bridged Ethernet networks. However, the more efficient MBS transmission has not been standardized, its integration to how IP works has not been defined, etc. Just state that its work in progress rather than try to specify all the above details. |
|
2008-01-10
|
07 | Jari Arkko | [Ballot discuss] > The mechanism of transporting IP traffic over IEEE 802.16 networks is > outlined in [IEEE802.16]. [IEEE802.16] only specifies the > convergence sublayers … [Ballot discuss] > The mechanism of transporting IP traffic over IEEE 802.16 networks is > outlined in [IEEE802.16]. [IEEE802.16] only specifies the > convergence sublayers and the ability to transport IP over the air > interface. The details of IPv6 (and IPv4) operations over IEEE > 802.16 are being discussed now in the 16ng WG. The first sentence seems contradictory to the fact that 16ng defines "IP over 802.16". Please drop the first sentence, and indicate in the second sentence that the IPv6 over IPCS definition is already an approved specification (currently in RFCEd queue); the above text makes it sound the matter is still being discussed. > Some architectural characteristics of IEEE 802.16 networks > may affect the detailed operations of NDP (Neighbor Discovery > Protocol) [RFC4861], [RFC4862]. ... > If stateless auto-configuration is used to get an IPv6 address, > router discovery and DAD operation should be properly operated over > IEEE 802.16 links. In case of the shared IPv6 prefix link model, the > DAD (Duplicate Address Detection) [RFC4861] does not adapt well to > the 802.16 air interface as there is no native multicast support. An > optimization, called Relay DAD, may be required to perform DAD. > However, in case of the point-to-point link model, DAD is easy since > each connection to a MN is treated as a unique IPv6 link. All the above is out of sync with what the 16NG WG eventually decided to do. They only support the p2p link model. They will later also publish an RFC how to support IP over Ethernet mode in 802.16, but this is expected to operate using standard mechanisms (bridging, mld snooping, etc). Please align this document to the current models in 16NG. > In this scenario, IEEE 802.16 > BSs have only MAC and PHY layers without router functionality and > operate as a bridge. The BS should support IPv6 classifiers as > specified in [IEEE802.16]. However, if IPv4 stack is loaded to them > for management and configuration purposes, it is expected that BS > should be upgraded by implementing IPv6 stack, too. Its not clear to me why we need to recommend upgrading the management network in conjunction of IPv6 support. Indeed, as the experiences from cable world show, the two can be upgraded independently and for different reasons. > Under fixed access model, the IEEE 802.16 BS will be deployed using > an IP backbone rather than a proprietary backend like cellular > systems. Thus, many IPv6 functionalities such as [RFC4861], > [RFC4862] will be preserved when adopting IPv6 to IEEE 802.16 > devices. Cellular systems are these days running on IP backbones. The word proprietary is not an appropriate characterization today, or even during the previous generation of systems. In any case, this document talks about 802.16, which will always be deployed on an IP backbone. Finally, the approved 16NG IPv6 document specifies the use 4861 and 4862 as-is (well, some timing parameters are adopted, but that is something that IP over Foo specs can do) for 802.16. Please delete this text. |
|
2008-01-10
|
07 | Jari Arkko | [Ballot Position Update] New position, Discuss, has been recorded by Jari Arkko |
|
2008-01-10
|
07 | Chris Newman | [Ballot Position Update] New position, No Objection, has been recorded by Chris Newman |
|
2008-01-09
|
07 | Russ Housley | [Ballot discuss] The authors have agreed to make changes based on the Gen-ART Review by Brian Carpenter. A revisee document has not been posted … [Ballot discuss] The authors have agreed to make changes based on the Gen-ART Review by Brian Carpenter. A revisee document has not been posted yet. The review text can be found at: http://www.alvestrand.no/ietf/gen/reviews/ draft-ietf-v6ops-802-16-deployment-scenarios-06-carpenter.txt |
|
2008-01-09
|
07 | Russ Housley | [Ballot Position Update] New position, Discuss, has been recorded by Russ Housley |
|
2008-01-08
|
07 | Amanda Baber | IANA Evaluation comments: As described in the IANA Considerations section, we understand this document to have NO IANA Actions. |
|
2008-01-08
|
07 | Lars Eggert | [Ballot Position Update] New position, No Objection, has been recorded by Lars Eggert |
|
2008-01-07
|
07 | Dan Romascanu | [Ballot discuss] From Section 2.6: IPv6 based IEEE 802.16 networks can be managed by IPv4 or IPv6 when network elements are implemented dual … [Ballot discuss] From Section 2.6: IPv6 based IEEE 802.16 networks can be managed by IPv4 or IPv6 when network elements are implemented dual stack. For example, network management systems (NMS) can send SNMP messages by IPv4 with IPv6 related object identifiers. Also, an NMS can use IPv6 for SNMP requests and responses including IPv4 related OID. The terminology that is being used here is slightly flawn, there is no such thing as IPv4 or IPv6 related OIDs. OIDs in MIBs point to managed objects which most of them are independent of either IPv4 or IPv6 and only a few of them (the objects not the OIDs) are IPv4 or IPv6 related. What I believe the authors mean is that all objects in all MIB modules may be accessed equally if IPv4 or IPv6 is used to carry the SNMP messages. |
|
2008-01-07
|
07 | Dan Romascanu | [Ballot Position Update] New position, Discuss, has been recorded by Dan Romascanu |
|
2008-01-03
|
07 | Samuel Weiler | Request for Telechat review by SECDIR is assigned to Julien Laganier |
|
2008-01-03
|
07 | Samuel Weiler | Request for Telechat review by SECDIR is assigned to Julien Laganier |
|
2007-12-27
|
07 | Ron Bonica | [Ballot Position Update] New position, Yes, has been recorded for Ronald Bonica |
|
2007-12-27
|
07 | Ron Bonica | Ballot has been issued by Ron Bonica |
|
2007-12-27
|
07 | Ron Bonica | Created "Approve" ballot |
|
2007-12-27
|
07 | (System) | Ballot writeup text was added |
|
2007-12-27
|
07 | (System) | Last call text was added |
|
2007-12-27
|
07 | (System) | Ballot approval text was added |
|
2007-12-27
|
07 | Ron Bonica | Placed on agenda for telechat - 2008-01-10 by Ron Bonica |
|
2007-12-27
|
07 | Ron Bonica | State Changes to IESG Evaluation from Waiting for Writeup by Ron Bonica |
|
2007-12-27
|
07 | Ron Bonica | State Changes to Waiting for Writeup from AD is watching by Ron Bonica |
|
2007-12-21
|
06 | (System) | New version available: draft-ietf-v6ops-802-16-deployment-scenarios-06.txt |
|
2007-12-19
|
07 | (System) | State Changes to AD is watching from Dead by system |
|
2007-12-18
|
05 | (System) | New version available: draft-ietf-v6ops-802-16-deployment-scenarios-05.txt |
|
2007-12-14
|
07 | (System) | State Changes to Dead from AD is watching::Revised ID Needed by system |
|
2007-12-14
|
07 | (System) | Document has expired |
|
2007-12-13
|
07 | Ron Bonica | State Changes to AD is watching::Revised ID Needed from Publication Requested by Ron Bonica |
|
2007-06-21
|
07 | Dinara Suleymanova | PROTO Write-up (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, … PROTO Write-up (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? I am the shepherd for this document. I have read this version, and believe that it is ready for publication as an RFC. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? I believe that it has had adequate review. It was originally posted in March 2006 and discussed in that meeting of the working group, and resubmitted as a working group document in May of that year. It was proposed as an extension of the v6ops broadband work, specifically addressing 802.16/Wimax networks. There were various issues raised and dealt with during subsequent revisions. Comment on the mailing list came from Jonne Soininen, Brian Carpenter, Eric Klein, Bruno Miguel Sousa (speaking for the 16NG working group in a solicited review), Jim Bound, and JinHyeock Choi. A review was also solicited from mip6; I believe that the response was directly to the authors, as I have no copy of it. The document was last-called in January 2007 and sent to the Area Director, David Kessens, in February, who responded asking whether we had received any comments to the effect that the document was needed. In a re-last-call in April, undertaken to solicit additional review and address the AD's concern, the comments both in the meeting and on the list were supportive, and specifically Jim Bound stated that he considered the draft to be helpful in 802.16 deployment. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization, or XML? Given that review has already occurred in v6ops, mip6, and 16ng, I don't see a need for further review. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. If such concerns exist, they have not been raised to me. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. No IPR disclosure was discussed in the working group. I looked at https://datatracker.ietf.org/public/ipr_search.cgi a moment ago, which reported: > Internal Server Error > > The server encountered an internal error or misconfiguration and > was unable to complete your request. > > Please contact the server administrator, webmaster@ietf.org and > inform them of the time the error occurred, and anything you might > have done that may have caused the error. > > More information about this error may be available in the server > error log. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? IPv6 Operations tends to be a group in which projects are done by small groups with relevant expertise and reviewed by others. The sense I have had in meetings and on the list has been that there is general support. That said, the primary cognitive input has come from the authors and a few others, listed above. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No such conflicts have been brought to my attention. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/.) Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type, and URI type reviews? If the document does not already indicate its intended status at the top of the first page, please indicate the intended status here. yes. I note the iddnits report here. The "intended status" of the document is "informational, not "proposed standard" as the tool presumed, and the "unused reference" was in fact used but broken across a line ending. The normative reference to RFC 4779 is a spurious note given that both 4779 and this document are informative. The other checklist items were not issues with this document. The RFC Editor will note that the authors speak English as a second language, which will necessitate a certain level of copy editing. I find the document quite readable even so, so this should not be onerous. > idnits 2.04.09 > - The downloaded file seems to be corrupt, proceeding with outdated > information.) > > tmp/draft-ietf-v6ops-802-16-deployment-scenarios-04.txt: > - Failure fetching the file, proceeding without it.) > > Checking boilerplate required by RFC 3978 and 3979, updated by > RFC 4748: > > ---------------------------------------------------------------------- > ------ > > No issues found here. > > Checking nits according to http://www.ietf.org/ietf/1id- > guidelines.txt: > > ---------------------------------------------------------------------- > ------ > > == No 'Intended status' indicated for this document; assuming > Proposed > Standard > > > Checking nits according to http://www.ietf.org/ID-Checklist.html: > > ---------------------------------------------------------------------- > ------ > > No issues found here. > > Miscellaneous warnings: > > ---------------------------------------------------------------------- > ------ > > No issues found here. > > Checking references for intended status: Proposed Standard > > ---------------------------------------------------------------------- > ------ > > (See RFC 3967 for information about using normative references to > lower-maturity documents in RFCs) > == Unused Reference: 'I-D.ietf-mipshop-fmipv6-rfc4068bis' is > defined on > line 657, but no explicit reference was found in the > text > '[I-D.ietf-mipshop-fmipv6-rfc4068bis] Koodli, R., "Fast > Handovers for...' > > ** Downref: Normative reference to an Informational RFC: RFC 4779 > > > Summary: 1 error (**), 2 warnings (==), 0 comments (--). > > ---------------------------------------------------------------------- > ---------- (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. Yes it has divided its references. The "normative" references are all to RFCs, and therefore have no publication issue. (1.i) Has the Document Shepherd verified that the document's IANA Considerations section exists and is consistent with the body of the document? The document creates no registries, and says as much in its IANA considerations section. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? There are no such sections. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document provides a detailed description of IPv6 deployment and integration methods and scenarios in wireless broadband access networks in coexistence with deployed IPv4 services. It discusses the main components of IPv6 IEEE 802.16 access networks, their differences from IPv4 IEEE 802.16 networks, and how IPv6 is deployed and integrated in each of the IEEE 802.16 technologies. Working Group Summary The document was reviewed by participants from both the IPv6 Operations WG and the 16NG Working Group. No lingering concerns remained as it completed its review. Document Quality As described in the IPv6 Operations charter, this document's purpose was to review the issues that might arise in deploying IPv6 in an IEEE 802.16 network. The document uses "IEEE 802.16" as essentially equivalent to "Wimax", although one could argue that they differ. It builds on the structure and considerations of RFC 4779, which is a more general document looking at IPv6 deployment in broadband networks in general. It notes issues such as the fact that 802.16 QoS definitions differ from and have to be operationally mapped to IP Differentiated Services concepts, and specifically comments on the use of IPv6 Multicast, QoS, Security, and Network Management in IEEE 802.16 fixed and mobile access networks. Personnel The Document Shepherd is Fred Baker. The Responsible AD is Ron Bonica. |
|
2007-06-21
|
07 | Dinara Suleymanova | Draft Added by Dinara Suleymanova in state Publication Requested |
|
2007-04-27
|
04 | (System) | New version available: draft-ietf-v6ops-802-16-deployment-scenarios-04.txt |
|
2007-02-16
|
03 | (System) | New version available: draft-ietf-v6ops-802-16-deployment-scenarios-03.txt |
|
2007-01-17
|
02 | (System) | New version available: draft-ietf-v6ops-802-16-deployment-scenarios-02.txt |
|
2006-10-02
|
01 | (System) | New version available: draft-ietf-v6ops-802-16-deployment-scenarios-01.txt |
|
2006-05-30
|
00 | (System) | New version available: draft-ietf-v6ops-802-16-deployment-scenarios-00.txt |