From: Samita Chakrabarti <[EMAIL PROTECTED]>
To: gabriel montenegro <[EMAIL PROTECTED]>; [email protected]
Sent: Friday, April 28, 2006 5:45:12 PM
Subject: Comments on the Format-02 document
Nits:
Typo in Introduction:
Likewise, the provisions required for packet delivery in IEEE 802.15.4 meshes <is> defined.
Section 2.
"As usual, hosts learn IPv6 prefixes via router advertisements ([I-D.ietf-ipv6-2461bis])."
Does it make sense to mention about ND for lowpan work in this context as well ?
gab> just mentioned that the WG may be pursuing more work here.
Section 4 ( Reassembly):
Each fragment contains "datagram_size" and datagram_tag and offset.
Should "datagram_size" be replaced by "fragment_size" for the fragmented
packets ? Is there anyway, during re-assembly one would know about the
fragment payload size ? Note that the offset and datagram_size do not
provide the info on the current fragment size.
gab> I left it as datagram_size, because that is what it means: the size of the
entire IP layer datagram. The size of this particular fragment can be inferred
from the PPDU information (the "Frame Length" field in the PHY 802.15.4
packet).
Section 7.
Please have a subheading for defining the IPv6 SLLA, TLLA option formats.
On the first look, it is a bit confusing as it seems IPv6 unicast address
mapping from the 802.15.4 short and long addresses.
gab> Left it as is, since this is exactly the same thing that the IP over ethernet
spec (rfc 2464) says. SLLA/TLLA is already mentioned as in that document:
The Source/Target Link-layer Address option has the following forms
when the link layer is IEEE 802.15.4 and the addresses are EUI-64 or
16-bit short addresses, respectively.
Section 8.
Please clarify that multicast 802.15.4 address is 16bit address.
Q: Can IETF specify such L2 addressing and specification ? Is there
any plan on IEEE to accomodate this feature?
gab> done. dunno about IEEE. I don't expect they're doing this, as this is done here
to map IPv6 multicast addresses specifically. Notice that this support is optional
in our format document, as the full specification is not to be done here, but in other
document.
The rest looks ok to me. The header compression part is a bit tricky
and complex. Should this draft suggest a default header compression
scheme for a suggestion to the implementors?
gab> Dunno, I think there is text already very strongly suggesting this be supported
(otherwise IPv6 is not practical).
thanks,
-gabriel
_______________________________________________ 6lowpan mailing list [email protected] https://www1.ietf.org/mailman/listinfo/6lowpan
