Transport Layer Security (TLS) Protocol Compression Using Lempel-Ziv-Stac (LZS)
draft-friend-tls-lzs-compression-04

Reviewed by John Loughney, Gen-ART

Comments:
Looks OK, couple of points:

1) Is there an external reference to the LZS compression mechanism?
   I wasn't clear if this is something that is entirely described within 
   the draft.
2) SSL used in some places (section 1.1) - should it be TLS?


NITS: 

1) 2026 broilerplate - needs updating
2) Should LZS be expanded in title, abstract & first usage?
3) Section 2.1 has a IANA request, might want to put a note for
   IANA to fill in the TBA, and perhaps put a back reference 
   to this section in the IANA considerations section.

   IANA has assigned <TBD> as compression method identifier for applying
   LZS compression to TLS record payloads.

4) Section 3.1, 'HiFn' I guess is a company, but I didn't quite get that
   point in section 3.1, would it be better to drop it?

old text:
   Starting with a sliding window compression history, similar to [LZ1],
   Hifn developed a new, enhanced compression algorithm identified as
   LZS. The LZS algorithm is a general-purpose lossless compression
   algorithm for use with a wide variety of data types.  It's encoding
   method is very efficient, providing compression for strings as short
   as two octets in length.

new text:

   Starting with a sliding window compression history, similar to [LZ1],
   a new, enhanced compression algorithm identified as LZS was developed.
   ....

John

  Reword the Abstract to avoid "[TLSComp]" and "[RFC2246]".

  In section 3.4.1, last paragraph, why aren't they called "compressed
  record" instead of "compressed packet" as well as "uncompressed record"
  instead of "uncompressed packet."  The TLS term is "record."

The I-D referenced as [TLSComp] was recently published as RFC 3749.

In 1.1, the draft says:

For example, SSL is now increasingly being
   used as an alternative VPN connection.  Compression services have 
   long been associated with IPSec and PPTP VPN connections, so 
   extending compression services to SSL VPN connections preserves the user 
   experience for any VPN connection.

This should be updated to read TLS.  I also don't think TLS qualifies as a
VPN in all cases (it is not always used as a topology-changing tunnel),
and that this compression is valuable in cases where it is not a
tunnel.  So the authors may want to consider whether this is a valuable
statement.