Stewart, thanks for your review. Vincent, thanks for your responses. I entered a No Objection ballot.
Alissa > On May 16, 2019, at 12:03 PM, Vincent Roca <vincent.r...@inria.fr> wrote: > > 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 >> <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 >> <http://simul.iro.umontreal.ca/testu01/tu01.html>> and AdaptiveCrush >> <http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/ADAPTIVE/ >> <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 > <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 > > > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org <mailto:Gen-art@ietf.org> > https://www.ietf.org/mailman/listinfo/gen-art > <https://www.ietf.org/mailman/listinfo/gen-art>
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
