Document:   draft-ietf-msec-bootstrapping-tesla-02.txt
Reviewer: Elwyn Davies [elwynd@dial.pipex.com]
Review Date:  Wednesday 12/14/2005 6:11 PM CST
Telechat Date:  Thursday 12/15/2005

Summary:  This document is almost ready for PS.  More precise specification is 
needed of at least two and possibly four of the TESLA parameters to be 
carried in MIKEY.  There are also a number of editorial nits.

Ted Hardie has also registered two comments regarding possible 
alternatives to NTP and the need to specify which registries are 
affected by the IANA considerations.

Detail:

Generally the document is very well written and the security analysis is 
admirably clear and (apparently) comprehensive.

Issues:
s4.2: Need to be more precise about how time values are carried (items 7 
and 11).
One possibility is to refer to s6.6 of RFC3830 which gives three options 
for timestamp formats.

s4.2: I think it might be desirable to be more precise about how big 
items 8 and 9 are (2 byte or 4 byte integers maybe)

s4.2: Presumably Type 11 is optional, dependent on the sync method 
used.  Does anything need to be said about how it is decided whether 
this should be present/processed?  Is it a matter of policy to be 
determined OOB or it being present implies the use of 'type 2' 
synchronization?

s4.3, last para: The use of SHOULD as regards NTP apparently allows for 
alternatives to the two methods specified for transmitting time stamps.  
If this is correct something needs to be said about how suitable methods 
ahould be selected (identified by Ted Hardie).

s6: The registries and defining documents into which the attributes are 
to be inserted need to be specified.

Editorial:
Abstract: is maybe a bit long., acronyms MAC, MIKEY need expanding..

s1, para 2: s/paramter/parameter/

s1, para 3: s/in a way/in a way that is intended to/
s1, para 3: s/does only focus/only focuses/
s1, para 3: s/on the generation/on the generation of those parameters/

s1, para 4: s/Diffie Hellman)/Diffie-Hellman)./
s1, para 4: s/Diffie Hellman/Diffie-Hellman/
s1, para 4: s/Recently a/A/ [It won't be recently once this is a long in 
the tooth RFC]
s1, para 4: s/schemens/schemes/

s1, para 5: s/usage for SRTP is/usage for SRTP are/

s3:  Various acronyms need expanding and maybe stating that they are 
defined elsewhere (PRF, HMAC-SHA1)

s3: Would be useful to say full list of parameters is in s4.3 of 
-msec-srtp-tesla.

s3: The last para duplicates the statement just before the list about 
the location of the defaults in s6.2 of -msec-srtp-tesla.

s4.2: It might be desirable to note that policy Type 11 does NOT 
correspond to item 11 in s3 which is actually covered by s4.4.

s4.3, item 2:s/shortly repeated/summarized/

s5.1: expand MitM acronym

s5.1, countermeasures: s/protocol run it is not possible/protocol 
exchange will make it impossible/

s5.3, Threat: s/parameters exchange/the parameters exchanged/
s5.3, Threat: s/discurpt/disrupt/

s5.5, Threat: s/desireable/desirable/