Compression Extensions for WebSocket
draft-ietf-hybi-permessage-compression-28
Yes
(Barry Leiba)
No Objection
(Alia Atlas)
(Alvaro Retana)
(Benoît Claise)
(Brian Haberman)
(Deborah Brungard)
(Jari Arkko)
(Kathleen Moriarty)
(Martin Stiemerling)
(Terry Manderson)
Note: This ballot was opened for revision 24 and is now closed.
Barry Leiba Former IESG member
Yes
Yes
(for -24)
Unknown
Alia Atlas Former IESG member
No Objection
No Objection
(for -24)
Unknown
Alvaro Retana Former IESG member
No Objection
No Objection
(for -24)
Unknown
Ben Campbell Former IESG member
No Objection
No Objection
(2015-07-07 for -24)
Unknown
*** Substantive Comments: *** -- I think Robert Spark's secdir comments concerning an intermediary changing the signaling of extensions deserves some thought. -- section 5, several example paragraphs: It's odd to find normative language in example. I _think_ the actual normative text is all covered elsewhere--if so, it should be written descriptively here. -- section 5, paragraph 6: ""Agreed parameters" MUST represent..." That seems more a statement of fact than a normative statement. If it's intentionally normative, the required condition is vague for a MUST. -- 6.1, Numbered list entry "2", third bullet (and several similar assertions) Do I understand correctly that the PMCE needs to know if the next extension wants frames, in order to determine whether to build them? How would it know that? -- 9: I’m surprised that there’s nothing here about intermediaries. For example, if an endpoint chooses not to compress because of the mentioned issue with encrypting compressed data, does it have to worry that some intermediary might choose to compress it anyway? -- 12.2, [CRIME] Seems like this may need to be normative. I’m not sure the reader can fully understand the security considerations without reading it. ***Editorial Comments:*** -- Section 3, first paragraph, last sentence: That seems true anytime a draft or RFC defines terms--what is special about these? -- 3, third paragraph: "An extension in use next to extension" The construction "next to" usually connotes adjacency, not order. I suggest "The next extension in use" (without the "to"). -- 8, 2nd to last paragraph: While you cited the LZ77 bits earlier, it would be useful to repeat that citation here. This is where the information actually gets used. -- 8.2.3.6: It's odd to refer to anything done by a computer as "manual".
Benoît Claise Former IESG member
No Objection
No Objection
(for -24)
Unknown
Brian Haberman Former IESG member
No Objection
No Objection
(for -24)
Unknown
Deborah Brungard Former IESG member
No Objection
No Objection
(for -24)
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(for -24)
Unknown
Joel Jaeggli Former IESG member
No Objection
No Objection
(2015-07-07 for -24)
Unknown
warren kumari's opsdir review (no further action required) Be ye not afraid. I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. Document reviewed: draft-ietf-hybi-permessage-compression-22 Summary: Ready, no nits, no comments. Details: Well, this is a first -- I have never before performed a review without finding at least some nits (typos, grammar, etc). Because I feel bad about not having *any* comments I'll scrape the bottom of the barrel -- I find the use of underscores jarring in e.g: 'This document references the procedure to _Fail the WebSocket Connection_. ' and think these could be replaced with quotes instead. I'll fully admit this is bikeshedding. Oh, the title on Section 8 also looks a little odd, was the 'p' intended to be uppercase? Could go either way... There are no operational impacts that I can see, other than less traffic on the wire, and more code in network devices if any of them are websocket servers or clients (e.g for management). W -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf _______________________________________________ OPS-DIR mailing list OPS-DIR@ietf.org https://www.ietf.org/mailman/listinfo/ops-dir
Kathleen Moriarty Former IESG member
No Objection
No Objection
(for -24)
Unknown
Martin Stiemerling Former IESG member
No Objection
No Objection
(for -24)
Unknown
Spencer Dawkins Former IESG member
No Objection
No Objection
(2015-07-08 for -24)
Unknown
I support both of Ben's comments that mention intermediaries.
Stephen Farrell Former IESG member
(was Discuss)
No Objection
No Objection
(2015-08-13 for -27)
Unknown
I had a discuss that said: "The secdir reviewer's comment about modifying the signalling seems to me to be something that the hybi WG needs to have debated. Did that happen?" I'm told by the secdir reviewer that that discussion has now happened and indeed the text on intermediaries has been removed which resolves the issue, so I've cleared.
Terry Manderson Former IESG member
No Objection
No Objection
(for -24)
Unknown