6LoWPAN-GHC: Generic Header Compression for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)
RFC 7400

Note: This ballot was opened for revision 04 and is now closed.

(Brian Haberman) Yes

(Jari Arkko) No Objection

(Alia Atlas) No Objection

(Richard Barnes) (was Discuss) No Objection

Comment (2014-09-18 for -04)
No email
send info
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.

Alissa Cooper No Objection

Spencer Dawkins No Objection

(Adrian Farrel) No Objection

(Stephen Farrell) No Objection

Comment (2014-09-16 for -04)
No email
send info
- 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:-)

(Joel Jaeggli) No Objection

(Barry Leiba) No Objection

Comment (2014-09-17 for -04)
No email
send info
   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

(Ted Lemon) No Objection

(Kathleen Moriarty) No Objection

(Pete Resnick) No Objection

(Martin Stiemerling) No Objection