Last Call Review of draft-kucherawy-dispatch-zstd-01
review-kucherawy-dispatch-zstd-01-genart-lc-gurbani-2018-04-19-00

Request Review of draft-kucherawy-dispatch-zstd
Requested rev. no specific revision
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2018-04-23
Requested 2018-03-26
Other Reviews Secdir Last Call review of -01 by Scott Kelly
Opsdir Last Call review of -01 by Susan Hares
Review State Completed
Reviewer Vijay Gurbani
Review review-kucherawy-dispatch-zstd-01-genart-lc-gurbani-2018-04-19
Posted at https://mailarchive.ietf.org/arch/msg/gen-art/Tjfs_winDEbz1LJufdFCrNsvgtw
Reviewed rev. 01
Review result Ready with Nits
Draft last updated 2018-04-19
Review completed: 2018-04-19

Review
review-kucherawy-dispatch-zstd-01-genart-lc-gurbani-2018-04-19

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-kucherawy-dispatch-zstd-01
Reviewer: Vijay K. Gurbani
Review Date: 2018-04-19
IETF LC End Date: 2018-04-23
IESG Telechat date: Not scheduled for a telechat

Summary: Ready with 1 minor issue and some nits.

Major issues: 0

Minor issues: 2
 
Nits/editorial comments:  3

Minor:
- S4: "... and the usual precautions apply."  Here, what are the "usual
 precautions"?  Are they the ones enumerated below?  If so, then
 perhaps restate as "... and the usual precautions apply, as enumerated
 below.".

 If the usual precautions are not enumerated below, then a reference should
 be provided to a resource(s) that enumerates such precautions.

- S5: I am curious, why should we remove this section prior to publication?
 It contains pointers to code that is invaluable to implementors.  At the
 most, I would advise excising company name (Facebook) from the section,
 but I would advocate strongly to retain this section as the draft becomes
 a RFC.

Nits/Typos:
- S2.1.1: The value of the magic number: 0xFD2FB528 --- is there any
 significance to it?  Any insight on how you arrived at this will be
 interesting.  (I am relating this magic number to the SIP magic cookie
 "z9hG4bK" which was chosen so that the probability was very small of
 older implementations to randomly pick a branch ID that started with
 these characters.)

- S2.1.1: s/the origina/the original/

- S2.1.1.3.1.1: "Value ?0" --> should it be "Value 00"?