RE: RFC 3339 & UTC offset

[Anton Okmianski <aokmians@cisco.com>]

Rainer:

> In the light of this sum-up, I propose the following compromise:
>
> - we will continue to use the rfc 3339 timestamp in its
>   unmodified way
> - we will ignore that RFC 3339 calls for timesync (because
>   we can't ensure it)
> - there will be NO header field indicating the reliability
>   of the time flag
> - there will be an optional structured data element which
>   allows to specify the timestamp reliability in all three
>   cases. If it is absent, it is assumed that the timestamp is
>   correct. If an implementor has a good indication this may
>   not be the case, his implementation SHOULD write the
>   respective element indicating this

This could be an ok compromise.  But some clarification is still needed.


1. What is "timestamp is correct"? Left to implementation to decide? I
am fine with that, if we can wordsmith it.

2. I am concerned about the "SHOULD" in the above. I think when
implementation does have good indication that time is wrong it MUST
provide a structured element to indicate this.  It is still kinda
voluntary because the implementation may not have a "good indication" or
may have its own definition of "wrong" time.

3. What do devices which have no time put in the timestamp?  Anything? I
understand they will provide the structured element (MUST), but why not
recommend what they should put in the timestamp instead of leaving it up
to them to invent a convention?

4. Do we want to make a distinction between non-authoritative time and
unknown time? Separate structured element?

I know this has been a big thread.  But there is a lot of intricate
issues to deal with here. The biggest problem, like you indicated, is
that our protocol is designed for a an environment which is not RFC 3339
compliant.

Anton.