RE: [16NG]I-DACTION:draft-ietf-16ng-ip-over-ethernet-over-802.16-01.txt

Burcak,

First, even when there are examples out how to provide IP multicast and
broadcast on link layers providing uplink unicast and downlink
multicast, the IEEE802.16 specification does not provide the details how
to accomplish this over an 802.16 transport connection (... as stated in
the I-D). 

Second, I agree with you that there is not enough normative language in
this revision. More normative language is due for the next version when
we have established the right framework for it. When reviewing all the
comments on -00.txt we found that most of the comments were addressing
just clarifications on how the pieces are fitting together.

Bye
Max

-----Original Message-----
From: Burcak Beser [mailto:Burcak.Beser@telsima.com] 
Sent: Saturday, March 17, 2007 1:08 AM
To: 16ng@ietf.org
Subject: RE:
[16NG]I-DACTION:draft-ietf-16ng-ip-over-ethernet-over-802.16-01.txt 

I have two basic issues before going into a detailed readout fo the
draft.

First, the draft states that (from section 5.2.) "Current IEEE 802.16
[IEEE802.16][IEEE802.16e] does not define any transport connection for
IP broadcast and multicast data." 

Even though it is true that the IEEE 802.16 MAC does not natively
support bi-directional broadcast domains, it is my understanding that
IEEE 802.16 has both broadcast and multicast downlink CID's defined,
which is being used effectively to transport IP broadcast and multicast
data on downlink direction for various deployments today. 

If the aim of the draft is "(from the abstract) transmission of IPv4 as
well as IPv6 over Ethernet in a network deploying the IEEE 802.16
cellular radio transmission technology", the subject is well researched
and there are many simpler schemes alrady deployed for this purpose on
systems where uplink is unicast and broadcast downlink exists. If there
are other implied requirements I would like to see them on a problem
statement section since these are beyond the published scope of this
draft.

Second, the use of minimal normative language with only one "SHOULD"
statement along with a single non-normative "shall" statement alludes to
the fact that it is possible and highly probable that various
implentations will not behave the same manner. One example is whether a
Proxy ARP (section 6.2.) is required or not; further where should it
reside?

It can further be said that the draft does not even meet its own purpose
of emulating broadcast domains for the purpose of IPv4 and IPv6
transmissions. The draft will be improved greately by the careful
addition of normative statements which would also make sure that all
implentations based on this draft will behave in a predictable manner.

Regards,
-burcak

_______________________________________________
16NG mailing list
16NG@ietf.org
https://www1.ietf.org/mailman/listinfo/16ng

_______________________________________________
16NG mailing list
16NG@ietf.org
https://www1.ietf.org/mailman/listinfo/16ng