I have found a few minor errata with draft-ietf-6lowpan-hc-06, see attached.
Robert -- Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 (0) 1924 910888 http://www.gridmerge.com <http://www.gridmerge.com/>
p4 === "is often used for verify" should be "is often used to verify" --- "This specification enables to compress the IPv6 Hop Limit field in those common cases, whereas LOWPAN_HC1 does not." should be "This specification enables compression of the IPv6 Hop Limit field in those common cases, whereas LOWPAN_HC1 does not." --- "which enables to save an additional pair of octets" would be better as "which enables saving of a further two octets" as the octets are not 'additional' as such. --- "can not" should be "cannot" --- "<a href="http://tools.ietf.org/html/rfc4944#section-10";>Section 10</a> decompression, but SHOULD NOT send section-10-compressed packets." should be "decompression according to <a href="http://tools.ietf.org/html/rfc4944#section-10";>Section 10 of [RFC4944]</a>, but SHOULD NOT send packets compressed according to <a href="http://tools.ietf.org/html/rfc4944#section-10";>Section 10 of [RFC4944]</a>." as "section-10-compressed packets" is not a formal term. --- p5 === "LOWPAN_IPHC assumes the following will be the common case for 6LoWPAN communication: Version is 6; Traffic Class and Flow Label are both zero;" should be "LOWPAN_IPHC assumes the following will be the common case for 6LoWPAN communication: Version is 6;" --- "single routable prefix assigned..." - is this still the case with the context IDs? --- p7 === "The remaining 64 bits are computed from the link-layer address as defined in [<a href="http://tools.ietf.org/html/rfc4944";>RFC4944</a>]." would be clearer as: "The remaining 64 bits are computed from the link-layer address as defined in [<a href="http://tools.ietf.org/html/rfc4944#section-8";>Section 8 of [RFC4944]</a>]." --- "11: 0 bits. The address is derived using context information and possibly the link-layer addresses." This statement is imprecise as it stands. Either the link layer address is used or it isn't, although it's difficult to see how the source IPv6 address can be inferred any other way unless one of the 16 contexts implies a specific address. --- p11 === DAM = 10. 32-bit Compressed Multicast Address (FFfs:00gg:gggg). should be DAM = 10. 32-bit Compressed Multicast Address (FFfs::00gg:gggg). --- p14 === CANNOT should be MUST NOT assuming this is requirements language --- p16 === May need to consider TCP header compression as well ---
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
