Skip to main content

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