Re: [tsvwg] Genart last call review of draft-ietf-tsvwg-tinymt32-01

[Vincent Roca <[e-mail]>]

Dear Stewart,

Thanks a lot for your review. We have submitted a new I-D to reflect these changes.
More precisely:

> Reviewer: Stewart Bryant
> Review result: Ready with Nits
> 
> 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-ietf-tsvwg-tinymt32-01
> Reviewer: Stewart Bryant
> Review Date: 2019-05-08
> IETF LC End Date: 2019-05-13
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary: A well written document. There are a few review comments below that
> the authors should consider.
> 
> Major issues: None
> 
> Minor issues:
> 
> According to statistical tests (BigCrush in TestU01
> <http://simul.iro.umontreal.ca/testu01/tu01.html> and AdaptiveCrush
> <http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/ADAPTIVE/>) the
> quality of the outputs of TinyMT seems pretty good,
> 
> SB> It would be useful to the reader to specify  "pretty good »

[VR] Good point. This is a claim that comes from the TinyMT32 authors 
(also co-author of this I-D):
	http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/TINYMT/index.html
A few things have been changed (mention to uniformity, addition of the above
URL to know where the claim comes from, mention of the limitations of 
Park-Miller PRNG. But as explained, we can do better with Mersenne Twister
PRNG (for instance), but it has a cost. None of them are considered cryptographically
secure, which we now mention.

NEW:
   The purpose of TinyMT is not to replace Mersenne Twister: TinyMT has
   a far shorter period (2^^127 - 1) than MT.  The merit of TinyMT is in
   its small size of the internal state of 127 bits, far smaller than
   19937 bits of MT.  According to statistical tests (BigCrush in
   TestU01 [3] and AdaptiveCrush [4]) the quality of the outputs of
   TinyMT seems pretty good in terms of randomnes (in particular the
   uniformity of generated numbers), taking the small size of the
   internal state into consideration (see [5]).  From this point of
   view, TinyMT32 represents a major improvement with respect to the
   Park-Miler Linear Congruential PRNG (e.g., as specified in [RFC5170])
   that suffers several known limitations.  However, neither TinyMT nor
   MT are meant to be used for cryptographic applications.


> =========
> 
>   The TinyMT32 PRNG initialization depends, among other things, on a
>   parameter set -- namely (mat1, mat2, tmat) --
> 
> SB> These probably need a few words  of explanation on introduction.

[VR] Agreed. We have extended this paragraph to be more clear.

NEW:
   The TinyMT32 PRNG initialization depends, among other things, on a
   parameter set -- namely (mat1, mat2, tmat) -- that needs to be well
   chosen (pre-calculated values are available in the official web
   site).  In order to facilitate the use of this PRNG and make the
   sequence of pseudo-random numbers depend only on the seed value, this
   specification requires the use of a specific parameter set (see
   Section 3.1).  This is a first difference with respect to the
   implementation version 1.1 (2015/04/24) by Mutsuo Saito and Makoto
   Matsumoto that leaves this parameter set unspecified.  A second
   difference is the removal of the tinymt32_init_by_array()
   alternative initialization function, to only keep the simple
   initialisation through a seed value (see Section 3.2).


> ========
> 
>   static void tinymt32_next_state (tinymt32_t * s);
> SB> I assume that this notation is good C, but
> SB> type space star space name does not seem common.
> SB> This may confuse some readers. One more often
> SB> sees one of the spaces omitted.

[VR] Yes, let’s do that in the usual way. I’ve removed the extra space
before the « * »  (the opposite is possible too, with a subtil difference
when several variables are defined together, which we avoid here).


> =========
> 
> Nits/editorial comments:
> 
>   This specialisation aims at having a simple-to-use and deterministic
>   PRNG, as explained below.
> 
> SB> I assume that "deterministic PRNG" is a term of the art, but the
> SB> it sounds like an oxymoron to the uninitiated. Perhaps a word
> SB> or two would clarify.
> 

[VR] Agreed. We have extended this paragraph as follows:

NEW:
   Finally, the determinism of this PRNG, for a given seed, has been
   carefully checked (see Section 3.3).  It means that the same sequence
   of pseudo-random numbers should be generated, no matter the target
   execution platform and compiler, for a given initial seed value.
   This determinism can be a key requirement as it the case with
   [RLC-ID] that normatively depends on this specification.


> =======

Cheers,

   Vincent