Subject: [6lowpan] Errata for draft-ietf-6lowpan-hc-06

From: Robert Cragie <[email-masked]>
Date: Fri, 22 Jan 2010 11:20:23 +0000

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

---

---

From: Geoff Mulligan <[email-masked]>
Date: Fri, 22 Jan 2010 15:07:38 -0700

Robert,
  Thank you.

Jonathan can you make these changes and since I have been delayed on
make the WGLC, maybe we can make this simple changes in a new rev and we
will do a 2 week last call on this new rev.

	geoff

On Fri, 2010-01-22 at 11:20 +0000, Robert Cragie wrote:
> http://www.gridmerge.com
> plain text document attachment (6lowpan-hc06-errata.txt)
> p4
> ===
> 
> _______________________________________________
> 6lowpan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lowpan