6LoWPAN-GHC: Generic Header Compression for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)
draft-ietf-6lo-ghc-05

   where 0 stands for 0, 1 for 1

I can't tell you how relieved I am to see that.

   For the purposes of the IANA registry,
   the bits are numbered in most-significant-bit-first order from the
   16th bit of the option onward, i.e., the G bit is flag number 15.

A minor thing -- but I had to read the paragraph a couple of times before I got the point this sentence is making:  Perhaps...

NEW
   For the purposes of the IANA registry,
   the bits are numbered in most-significant-bit-first order from the
   16th bit of the option onward: the 16th bit is flag number 0, and
   the 31st bit (the G bit) is flag number 15.
END

Has consideration been given to the security impacts of compressing headers withing encrypted payloads?  In the context of HTTPS, there have been several attacks that exploited TLS compression in order recover information about secret values.  These attacks are possible because the compression used a dictionary that was dynamically constructed based on the content sent over the channel.  This allows an attacker to probe for a secret value by sending guesses and seeing if the response is compressed.  It seems like the backreference mechanism in this document could have similar repercussions if backreferences were allowed over a sufficiently broad scope.  

It may be helpful to consult the Security Considerations in the HTTP header compression draft:
https://tools.ietf.org/html/draft-ietf-httpbis-header-compression-09

"that can be defined on a single page" - I note that this document is more than one page long, even discounting boilerplate :)

It would nice if you would explain where the magical 16-byte dictionary comes from.

What do the underscores in Figure 5 mean?  If this notation is defined elsewhere, please reference.

- abstract: 23 pages isn't very short:-)

- GHC is used before expansion I think.

- Has anyone had a look to see if there is a way to craft
compressed packets that would be (very) costly on the
receiver when decompressed? (As a DoS acceleraor say.) That
can be an issue for some compression schemes but I'n not sure
if its one here or not. (Sorry, haven't had time to figure
that out myself yet, and maybe its quicker to ask:-)