Bootstrapping Timed Efficient Stream Loss-Tolerant Authentication (TESLA)
draft-ietf-msec-bootstrapping-tesla-03

IANA Comments:
Upon approval of this document we understand the IANA needs to assign 4 values.
It is not clear as to in which registries these values need to go in.  The IANA Considerations section needs some clarification.

[Ballot discuss]
(Based on Gen-ART review by Elwyn Davies)

Some policy parameters appear to be under-specified, so interoperability is uncertain:

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?

IANA Considerations unclear

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

[Ballot comment]
The document notes that NTP may be used as an out-of-band mechanism for synchronization, and it assigns this a SHOULD when piggybacking timestamp information is not appropriate (as when the
media receiver is not the MIKEY initiator).  Is there any general set of characteristics for out-of-band mechanisms which would allow someone to know whether a mechanism might substitute for NTP in a specific environment?