Telechat Review of draft-ietf-hybi-permessage-compression-24

Request Review of draft-ietf-hybi-permessage-compression
Requested rev. no specific revision (document currently at 28)
Type Telechat Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2015-07-07
Requested 2015-06-25
Authors Takeshi Yoshino
Draft last updated 2015-07-06
Completed reviews Genart Last Call review of -22 by Dan Romascanu (diff)
Genart Telechat review of -24 by Dan Romascanu (diff)
Secdir Last Call review of -21 by Robert Sparks (diff)
Opsdir Last Call review of -22 by Warren Kumari (diff)
Assignment Reviewer Dan Romascanu 
State Completed
Review review-ietf-hybi-permessage-compression-24-genart-telechat-romascanu-2015-07-06
Reviewed rev. 24 (document currently at 28)
Review result Ready with Issues
Review completed: 2015-07-06


I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at





Please resolve these comments along with any other Last Call comments you may receive.


Document: draft-ietf-hybi-permessage-compression-21

Reviewer: Dan Romascanu

Review Date: 6/16/15

IETF LC End Date: 6/24/15

IESG Telechat date: 7/9/15


Summary: Ready with minor issues


I do not know if this is an issue, but I am asking the question. Some implementations are mentioned in the write-up, but they seem to have been written and deployed based on very old versions of the document – 05 and earlier, dating
 three years back. I am wondering if this is a problem of the write-up not being updated. If not – have the changes brought to the document since draft-05 impacted the negotiation and algorithms described in the document?  


Major issues:


Minor issues:




In Section 5: 



The server must keep the original

   bytes of data that it recently compressed and sent to the client.

   The client must keep the result of decompressing the bytes of data

   that it recently received from the server.

   The two ‘must’ here seem to deserve capitalization.




In Section 8.2.1: 


Note that

   for non-final fragments, the removal of 0x00 0x00 0xff 0xff must not

   be done.

‘must not’ here seems to deserve capitalization.


Nits/editorial comments:




In Section 4: ‘One PMCE extension is defined …’ – the word extension can be dropped, E already stands for extension



In Section 10.2 – It would be good to explain in ‘Meaning’ the significance of the values 0 and 1 of the RSV1 bit



In section 11:  s/Thank you to the following people/Thanks to the following people/