Transmission of IPv6 via the IPv6 Convergence Sublayer over IEEE 802.16 Networks
draft-ietf-16ng-ipv6-over-ipv6cs-11
Yes
(Jari Arkko)
No Objection
(Chris Newman)
(Dan Romascanu)
(David Ward)
(Jon Peterson)
(Lisa Dusseault)
(Magnus Westerlund)
(Mark Townsley)
(Ron Bonica)
(Ross Callon)
(Sam Hartman)
(Tim Polk)
Note: This ballot was opened for revision 11 and is now closed.
Jari Arkko Former IESG member
(was Discuss, Yes)
Yes
Yes
()
Unknown
Chris Newman Former IESG member
No Objection
No Objection
()
Unknown
Dan Romascanu Former IESG member
No Objection
No Objection
()
Unknown
David Ward Former IESG member
No Objection
No Objection
()
Unknown
Jon Peterson Former IESG member
No Objection
No Objection
()
Unknown
Lars Eggert Former IESG member
(was Discuss)
No Objection
No Objection
(2007-04-16)
Unknown
Section 3., paragraph 0: > 1. the IP specific part of the Packet CS or, > 2. the 802.3 [802.3] specific part of the Packet CS or, > 3. the 802.1Q [802.1Q] specific part of the Packet CS. Although this document is only concerned with (1), Sections 2 and 4 talk quite a bit about the other sublayers. This seems redundant, given that we've just approved draft-ietf-16ng-ipv6-link-model-analysis. Suggest to clearly state here that this document is about (1) and reference draft-ietf-16ng-ipv6-link-model-analysis for the discussion of various sublayers. Section 3., paragraph 13: > When IPv6 is carried via the IP convergence > sublayer, this specification SHOULD be followed. Why isn't this a "MUST be followed"? Section 3., paragraph 14: > In order to ensure > interoperability the BS SHOULD support the IP specific part of the > packet CS and the Ethernet specific part of the packet CS for IPv6 > transport. Why isn't this a "MUST support"? Section 5., paragraph 0: > 5. Generic network architecture using the 802.16 air interface I suggest to move this section before Section 4, because it explains some terms I struggled with in Section 4 ("transport connection", etc.) Section 6.1., paragraph 1: > In 802.16, the Transport Connection between an MS and a BS is used to > transport user data, i.e. IPv6 packets in this case. A Transport > Connection is represented by a CID (Connection Identifier) and > multiple Transport Connections can exist between an MS and BS. Move this explanation up to where you talk about transport connections for the first time. Section 9.3., paragraph 1: > Stateless address autoconfiguration SHOULD be performed as specified > in [I-D.ietf-ipv6-2461bis], [I-D.ietf-ipv6-rfc2462bis] . I think this should say "SHOULD be performed, and if performed, MUST be performed as in..." Section 9.4., paragraph 1: > Stateful address autoconfiguration SHOULD be performed as specified > in [I-D.ietf-ipv6-2461bis], [RFC3315]. I think this should say "SHOULD be performed, and if performed, MUST be performed as in..." Appendix A., paragraph 1: > The WiMAX (Worldwide Interoperability for Microwave Access) forum > [WMF] has defined a network architecture in which the air interface > is based on the IEEE 802.16 standard. The addressing and operation > of IPv6 described in this document is applicable to the WiMAX network > as well. I'd be good to preface these appendices with a motivation of why they're included in this document. For example, I'm not sure what "is applicable to the WiMAX network as well" means, when WiMAX has made some divergent design choices (MTU, etc.) [More editing nits emailed to the authors directly.]
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
(was Discuss)
No Objection
No Objection
(2007-04-19)
Unknown
I do not see the value of mentioning the ATM CS in the Abstract. s/802.16/IEEE 802.16/ s/802.3/IEEE 802.3/ s/802.1Q/IEEE 802.1Q/
Sam Hartman Former IESG member
(was Discuss)
No Objection
No Objection
()
Unknown
Tim Polk Former IESG member
No Objection
No Objection
()
Unknown