Representing Multi-Value Time in Mobile Ad Hoc Networks (MANETs)
RFC 5497

Note: This ballot was opened for revision 08 and is now closed.

(Ross Callon) Yes

(Jari Arkko) (was Discuss) No Objection

Comment (2008-06-26)
No email
send info
What makes it hard to read this spec is that the definitions are
almost, but not entirely, free of context. A set of addresses is
a context for some statement about them. Your specification defines
the format of the statement about time, but does not fully define
what objects (addresses) it applies to. You could also have chosen 
between including the object in question in the format or leaving the
object to the definition of whoever uses this format.

Let me compare this definition to something that we've done in the
RADIUS, Diameter, or MIB spaces. Typically, there's a definition
of a datatype (such as integer, time, utf8 string or even a filter
definition). Separate from these we have definition of attributes
or MIB objects that employ these datatypes. Those definitions
give the context and rules how to interprete the values. The datatype
definitions are simply for data items, void of any context such as
what this integer/time/string would relate to. Something to consider

Here's what idnits had to say:

The document seems to lack the recommended RFC 2119 boilerplate, even if
it appears to use RFC 2119 keywords -- however, there's a paragraph with
a matching beginning. Boilerplate error?

(Ron Bonica) (was Abstain, Discuss, Abstain) No Objection

Comment (2008-09-29)
No email
send info
After some discussion with the authors, I agree that this level of complexity is required if you are going to try to convey that amount of information in only 8 bits.

I support Lars' objection, that the TLV should be simplified at the cost of a few more bits. However, I won't stand in the way of this draft and change my position to ABSTAIN.

(Pasi Eronen) No Objection

(Russ Housley) (was Discuss) No Objection

(Chris Newman) (was Abstain) No Objection

Comment (2008-10-16)
No email
send info
I'm still dubious of the complexity of creating a new custom 8-bit
floating point number format rather than just using a simple 32-bit
integer or a 32-bit IEEE floating point number.  However, at least the
motivation for doing so is documented in the document.

(Tim Polk) (was No Record, Discuss) No Objection

(Dan Romascanu) (was Discuss) No Objection

(Mark Townsley) No Objection

Comment (2008-09-25 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
I share some of the same concerns as Jari. The document doesn't need a tutorial by any means, but a little bit of context around why such a complicated time format is needed would be helpful. I question whether this is truly necessary, and whether again the "make it general for any purpose" pendulum has swung a bit too far again here. A little bit of explanation would be helpful.

Magnus Westerlund (was Discuss, No Objection, Discuss) No Objection

(Lisa Dusseault) Abstain

Comment (2008-10-16)
No email
send info
I am voting ABSTAIN.  I too, find the document and its design choices very confusing.  I can't see why a *general-purpose* duration type would necessarily need to work this way.  I find there are some choices in the design that are bad for general interoperability.  It may be that those choices could be justified for certain use cases and in a protocol more limited than MANET, but I just can't see it for general-purpose time typing.

(Lars Eggert) Abstain

Comment (2008-01-23 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
I agree with the gen-art reviewer that the concept of "distance" is not well-explained. I'm also questioning why it makes sense to specify a relatively complex construct such as distance-dependent time in a generic TLV format - is this really common enough across MANET protocols so that it needs to be specified generically? (I've never seen it used for any other protocol.)

Finally, Chris raises a good point - it's unclear why a new fixed-point format is the right thing here, especially since it can only be understood if one knows what "C" is in use. Burning a few more bits and eliminating "C" seems to be the right tradeoff.

(Cullen Jennings) (was No Record, No Objection) Abstain

Comment (2008-10-19)
No email
send info
My position is largely the same as Ron's. 

I have not seen any arguments for why it needs to be this complex. However, I don't think it will harm the internet and thus do not think it is appropriate to hold a discuss on this case. I

(David Ward) (was Discuss, Abstain) Abstain

Comment (2008-10-12)
No email
send info
As with others, I find this design the Wrong Thing (tm).  If you can afford the overhead of a TLV in your protocol you surely do not need to bit bum values down to 8 bits.

The range of times they can represent is 1 to 64 seconds times some magic constant with some arbitrary variable degree of precision. Magic constants are always bad news unless you have a protocol to negotiate them and even then they are bad news.

They could quite reasonably take a slice out of the middle of the NTP format. If they were to use say two bytes of seconds and one byte of fractional seconds that would give them 18 hours in 4ms accuracy. If they make the structure a nice round 4 bytes you get 6 months in 4ms accuracy, and that has got to be enough for any application that I can think of without needing some global magic number.