[16NG] AD review of draft-ietf-16ng-ps-goals

[Jari Arkko <[e-mail]>]

Hi all,

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.

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.

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.

Jari




_______________________________________________
16NG mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/16ng