Transport Layer Security (TLS) Protocol Compression Using Lempel-Ziv-Stac (LZS)
RFC 3943

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

(Steven Bellovin) (was Discuss, Yes) Yes

(Harald Alvestrand) No Objection

Comment (2004-05-26 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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

(Margaret Cullen) No Objection

(Ted Hardie) No Objection

Comment (2004-05-25 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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.

(Scott Hollenbeck) No Objection

Comment (2004-05-20 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
The I-D referenced as [TLSComp] was recently published as RFC 3749.

(Russ Housley) No Objection

Comment (2004-05-26 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
  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."

(David Kessens) No Objection