Document: Time TLV (draft-ietf-manet-timetlv-04)
Reviewer: Eric Gray
Review Date: January 17, 2008
IETF LC End Date: January 17, 2008

Summary:  It is hard for me to be sure this specification is ready for 
publishing as a Proposed Standard RFC.  Primarily this is because I have 
no clear idea how readable the specification is intended to be for a 
general (technical) reader.

However, if there is a reasonably large readership that is able 
to comprehend readily what this specification actually specifies, 
and that readership finds this useful, then this specification 
may be nearly ready for publishing as a  Proposed Standard RFC.

Minimally, the author(s) should expand on the Security Considerations
section by at least describing measures that any protocol using the 
TLVs defined here should define to ensure - for example - the authenticity 
of the values given.

Comments: 

One of the immediate problems I had with this specification is with the
concept  of "Distance" which initially seemed seriously under-specified.

One of the possible ways to assign a value to "Distance" is in terms of
"hop count", which - when applied in the way the specification discusses -
might be equated to a time-correction.  However, one has to read fairly far
into the specification in order to understand how this would work in
practice, if the actual time associated with traversal on a hop-by-hop 
basis is (AFAIK) non-deterministic.  

Moreover, this is listed as merely one way to determine a value for Distance 
- no other scheme is explicitly proposed, nor is there an explanation of
how additional schemes might be proposed later, nor is there any
specification of  units to be associated with any value proposed (beyond "hops").

If one dives into the specification, however, one can begin to understand how
this is expected to work - at least for the hop-count case.  The terminology
used is probably somewhat less incomprehensible to someone very familiar
with most of the references, and this does not help.  For example, a "single
value TLV" appears to have structure which makes it hard to recognize using
any of the reasonably intuitive definitions of "single" that I've seen in
common use.

If I understand the description at the bottom of page 8, and top of page 9,
correctly, distance is a unit-less value that the TLV interpreter is
supposed to know - either a priori, or as derived (e.g. - from message contents,
such  as with hop-count).  Distance is then used for comparison with
"Distance" values to determine which of the "Time" values is most correct.  
In the hop count case, a hop-count value might - for example - be used to 
derive the offset around which the value interpreter would expect to find the
correct (or most correct) time value.

For a first time reader, this is fairly opaque - even assuming I've gotten
it right.  If I've not understood it correctly, please explain.

Even if I have understood it correctly, it would be useful - if not really
absolutely necessary - to provide a bit more clarification and possibly 
one or more examples.

Also, the Security Considerations section can be a bit more useful than it
is now.  Minimally, it should make the obvious statement that any use of
the TLVs defined in this specification that relies on authenticity,
should include specification of mechansisms for authentication.  Similarly, 
if it is desirable to conceal time and distance values (to prevent inferring
of station locations, for instance) in any particular use, specification of
that use should include a description of how this would be done.

These things seem obvious, but including this sort of text gives someone
who plans to use these TLVs a gentle reminder of some things they should
consider.