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

[Ballot comment]
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."

[Ballot comment]
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  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

[Ballot comment]
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.