IP over IEEE 802.16 Problem Statement and Goals
draft-ietf-16ng-ps-goals-04

[Ballot comment]
These comments are based on the OPS-DIR review by Bert Wijnen.

I think document is in good shape. I have some minor comments/nits/

Detailed comments/nits

1. Pls expand acronyms when used for the first time. For example, 3rd para in section 1 uses BS and SS. I think (but am not sure) BS means Base Station, but SS?? Anyway pls expand. (Note: I see that you do expand in the Terminology Section. Still I think it would be good to also expand when used for the bvery first time in the doc).

2. 3rd para sect 1:
  (Ethernet CS) of Packet CS is within the current 16ng WG scope.
I think I would s/16ng WG/IETF 16ng WG/
The reason is that you also speak about non-IETF WGs, and so it is probably best to be specific for all/anyt WG you list.

3. 4th para in sect1:
  except into individual addresses as specified from [RFC4903].
For my feeling of English, I would: s/from [RFC4903]/in [RFC4903]/

4. In 3rd para on page 8 I see:

  multicast and broadcast connection for IP packet transfer.  There
  needs mechanisms like IEEE 802.1D to realize multicast and broadcast
  for Ethernet CS.  Moreover, the frequent IP multicast and broadcast
  signaling within the IP subnet like Ethernet needs to be avoided not
  to wake up sleep/idle [IEEE802.16e] SSs.

s/There needs mechanisms/There need to be mechanisms/ ??
s/sleep/sleeping/ ??

5. Sect 4.3 end of 1st para:
  the problem of waking up the sleep/idle [IEEE802.16e] SSs.
s/sleep/sleeping/ ??

6. In the acknowledgement section I see:

  The authors would like to express special thank to David Johnston for
  amending the section 4, "Overview of the IEEE 802.16-2006 MAC layer"

while in the (Informative References) I see:

  [IEEE802.16]
              IEEE Std 802.16-2004, "IEEE Standard for Local and
              metropolitan area networks, Part 16: Air Interface for
              Fixed Broadband Wireless Access Systems", October 2004.

  [IEEE802.16e]
              IEEE Std 802.16e, "IEEE standard for Local and
              metropolitan area networks, Part 16:Air Interface for
              fixed and Mobile broadband wireless access systems",
              October 2005.

So the overview seems to discuss a newer version of the IEEE 802.16 specs than the ones pointed to in the references. Is there a good reason for that?
In fact, I do see that section 4 is NOT an overview of 802.16. Instead, section 3 seems to be an overview of 802.16-2004. SO is that what the acknowledgement is (should be) for?

[Ballot comment]
These comments are based on the OPS-DIR review by Bert Wijnen.

I think document is in good shape. I have some minor comments/nits/

Detailed comments/nits

1. Pls expand acronyms when used for the first time. For example, 3rd para in section 1 uses BS and SS. I think (but am not sure) BS means Base Station, but SS?? Anyway pls expand. (Note: I see that you do expand in the Terminology Section. Still I think it would be good to also expand when used for the bvery first time in the doc).

2. 3rd para sect 1:
  (Ethernet CS) of Packet CS is within the current 16ng WG scope.
I think I would s/16ng WG/IETF 16ng WG/
The reason is that you also speak about non-IETF WGs, and so it is probably best to be specific for all/anyt WG you list.

3. 4th para in sect1:
  except into individual addresses as specified from [RFC4903].
For my feeling of English, I would: s/from [RFC4903]/in [RFC4903]/

4. In 3rd para on page 8 I see:

  multicast and broadcast connection for IP packet transfer.  There
  needs mechanisms like IEEE 802.1D to realize multicast and broadcast
  for Ethernet CS.  Moreover, the frequent IP multicast and broadcast
  signaling within the IP subnet like Ethernet needs to be avoided not
  to wake up sleep/idle [IEEE802.16e] SSs.

s/There needs mechanisms/There need to be mechanisms/ ??
s/sleep/sleeping/ ??

5. Sect 4.3 end of 1st para:
  the problem of waking up the sleep/idle [IEEE802.16e] SSs.
s/sleep/sleeping/ ??

6. In the acknowledgement section I see:

  The authors would like to express special thank to David Johnston for
  amending the section 4, "Overview of the IEEE 802.16-2006 MAC layer"

while in the (Informative References) I see:

  [IEEE802.16]
              IEEE Std 802.16-2004, "IEEE Standard for Local and
              metropolitan area networks, Part 16: Air Interface for
              Fixed Broadband Wireless Access Systems", October 2004.

  [IEEE802.16e]
              IEEE Std 802.16e, "IEEE standard for Local and
              metropolitan area networks, Part 16:Air Interface for
              fixed and Mobile broadband wireless access systems",
              October 2005.

So the overview seems to discuss a newer version of the IEEE 802.16 specs than the ones pointed to in the references. Is there a good reason for that?
In fact, I do see that section 4 is NOT an overview of 802.16. Instead, section 3 seems to be an overview of 802.16-2004. SO is that what the acknowledgement is (should be) for?

[Ballot discuss]
There is no reference in the document about operational and manageability considerations. At least i would suggest that the document include a goal in 4.4 about 'define management requirements and specifically the interfaces and specific management model (objects) for IP over 802.16'

[Ballot discuss]
Following the Gen-ART Review and comments from others during IETF
  Last Call, the authors said that the next revision will apply the
  corrections.  However, there has not been an updated Internet-Draft.
  There is a note to the RFC Editor, but it only reflects the change
  that resulted from the SecDir Review.

Also, from my review of the archives I did not see enough
review of this document. I also did not see actual discussion
about this document recorded in the minutes of last three
IETFs. When you send the document back to me, please
ensure that you have at least two additional reviews
from WG members.

I have made my AD review of this document. The document is
in relative good shape and I fully agree with the goals. However,
there were a few substantial issues and a number of editorial
issues that I discovered.

Please discuss these issues and/or revise the document
accordingly. Also, I would like to ask the chairs to initiate
a review in IEEE 802.16 through our liaison.

Substantial:

> This Ethernet like link model assumes that underlying
> link layer provides the equivalent functionality like Ethernet, for
> example, native broadcast and multicast.  It seems feasible to apply
> the 802.16's Ethernet CS to configure this link model.  However,
> there exists a discrepancy between the assumption from the Ethernet
> like link model and the 802.16's MAC feature which is connection-
> oriented and not providing multicast and broadcast connection for IP
> packet transfer.

Why would this be any different traditional wired & switched ethernet
case? There is no native multicast over a set of wires...

>    Blocking ARP or the address resolution of NDP needs to be implemented
>    by SS itself in an implementation manner.
There is no mention of such blocking in the 16ng's IPv6
document (ipv6-over-ipv6cs). Would blocking NDP packets
break IPv6 NUD?

>    Because MAC address is not used for transmission in case of IP CS, it
>    is unclear whether source link layer address need to be carried in
>    the RS (Router Solicitation).  The RS may need to have source IP
>    address specified so that the RA (Router Advertisement) can be sent
>    back.  This may require the completion of the link local address
>    configuration before sending an RS.
Why would you need the source address? This is the point-to-point
link model...

> If there
>    exists multiple ARs (so the default routers), it is unknown if the
>    NUD is required if an AR is not serving any 802.16 MAC connection.

How can you have multiple devices at the end, if this is a
point-to-point link?

Editorial:

>    sublayer (CS) is at the uppermost of the MAC that is responsible for

... uppermost part ...

>    assigning transmit-direction SDUs (originating from a higher layer

Expand the acronym SDU

>    [I-D.thaler-intarea-multilink-subnet-issues].

RFC 4903.

>    Blocking ARP or the address resolution of NDP needs to be implemented
>    by SS itself in an implementation manner

This probably should read: Blocking ARP or NDP address resolution packets
needs to be implemented by SS itself in an implementation specific
fashion.

> To acquire that address, the
>    address resolution should be performed throughout conventional
>    broadcast and multicast based ARP or NDP.  However, this multicast
>    and broadcast packets results in the problem of waking up the sleep/
>    idle [IEEE802.16e] SSs.
Yes, but you should probably say ... if not filtered (e.g., RFC 4541), these
multicast and broadcast packets ...

Also, s/this/these/

> 2.  Requirements
>
>    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>    document are to be interpreted as described in [RFC2119] .

Remove this section and reference if the keywords are not used.

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?

Daniel Park is the Document Shepherd for this document.
I've reviewed this document and it is ready for advancing to the
IESG for publication.

(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?

Several 802.16 and IPv6 experts reviewed this document to enhance the
quality of this document. This document went through the 2 weeks WGLC
in the 16ng WG. I have no concern about the depth or breadth of the
reviewrs that have been performed.

(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?

None.

(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.

None.

(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?

There is strong WG consensus in advancing this document. Also,
selected reviewers are ok with this document to be moved forward.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise 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.

(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?

No major issues found here. There are minor nits that reported by
the idnits tool.
- The page length (page 13) should not exceed 58 lines.
- The document does not use any RFC 2119 keywords.
In addition, author should not exceed 5 people. These will be fixed
in the subsequent revision.

(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].

The document splits its references into normative and informative.

(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body
of the document? If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggested a
reasonable name for the new registry? See
[I-D.narten-iana-considerations-rfc2434bis]. If the document
describes an Expert Review process has Shepherd conferred with
the Responsible Area Director so that the IESG can appoint the
needed Expert during the IESG Evaluation?

The IANA considerations section exists. This document has no
actions for IANA.

(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?

Does not apply to this document.

(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Writeup? Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary
Relevant content can frequently be found in the abstract
and/or introduction of the document. If not, this may be
an indication that there are deficiencies in the abstract
or introduction.

Relevent content can frequently and easily be found in the abstract
and introduction of this document.

Working Group Summary
Was there anything in WG process that is worth noting? For
example, was there controversy about particular points or
were there decisions where the consensus was particularly
rough?

None.

Document Quality
Are there existing implementations of the protocol? Have a
significant number of vendors indicated their plan to
implement the specification? Are there any reviewers that
merit special mention as having done a thorough review,
e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues? If
there was a MIB Doctor, Media Type or other expert review,
what was its course (briefly)? In the case of a Media Type
review, on what date was the request posted?

This document specifices problems in running the IETF protocols over
IEEE 802.16 network and identifies specific gaps in the 802.16 MAC for
IPv4 and IPv6 support.Also, this document spells out several goals to
point at relevant works to be done in IETF. The quality of the document is
good.

Personnel
Who is the Document Shepherd for this document? Who is the
Responsible Area Director?

Daniel Park is the Document Shepherd for this document.
Jari Arkko is the Responsible Area Director.