Gabriel, First some editorial comments: Section 3 Paragraph 1 Line 12 - occurred should be occurring
Section 5.1 Paragraph on datagram_size (page 8): I think that the NOTE: should read: While it may appear that this field does not need to be in every packet, as one could send it with the first fragment and elide it subsequently, it is included it in every link fragment to ease the task of reassembly in the event that a second (or subsequent) link fragment arrives before the first. ... Section 5.2: Possible rewrite: The recipient of link fragments SHALL use (1) ... I think that the next paragraph in the text, the paragraph starting with "Upon receipt" should be removed since this is an implementation choice. For the same reason and and per the discussion with Phil, I think that the next paragraph (starting with "If a link fragment") should also be removed. And for the same reason, this is an implementation detail, the paragraph starting with "Upon detection of a IEEE" should be removed unless there is a specific reason for the 15 second time out - where did 15 seconds come from? Section 6: Paragraph 2 Line 6: I'm not sure that the phrase "concatenated with" is clear as to the ordering. I'm not sure that "concatenated to" is precise (as used in the previous sentence). Section 10.1: I think that it should be written as: It is possible to use header compression even in advance of setting up the customary state. The following common IPv6 header... Appendix A Paragraph 1 line 18: frament should be fragment. Questions: Section 5.1 Paragraph on datagram_size (page 8): The datagram_size is set to 40 octets more than the Payload Length value in the IPv6 header, but if the IPv6 header is compressed doesn't this lead to the wrong datagram size calculation? Section 5.1 Encapsulation header format (meta question): if we were to allow multiple mesh protocols under this adaptation layer do we think that this should be carried in the prot_type field or should we add or define the "rsv" field for the mesh network type, though 3 bits would probably suffice or should we add one more byte. I think that this is partially what David was asking about. Having this flexibility might be especially important to allow for diagnosing the mesh layer. Section 9 about Multicast Address mapping: Does this preclude a network from using 64-bit addressing for multicasting? It seems to indicate that you must use 16-bit addresses for multicast addresses. Section 10.2 in the Length (bit 2) paragraph: can we really compute the udp length field from the possibly compressed frame length field or the datagram_size field in a fragment header? Is this a simple calculation? Section 11 - It doesn't look like we fixed the problem with the sequence number before the destination address? Did I miss a different solution? _______________________________________________ 6lowpan mailing list [email protected] https://www1.ietf.org/mailman/listinfo/6lowpan
