Re: Some late comments on draft-ietf-quic-load-balancers

[James <[e-mail]>]

I've raised a small PR[1] which should cover this, however I think there 
is some other considerations that may belong in a separate PR:

* What happens when a service receives a token with a timestamp which 
points to a time in the future? Should this just be accepted, or treated 
as an error?

* Is there a way we can remove the requirement for having time_t as the 
timestamp value and instead use a linear incrementing value relative to 
the server and service that is independent of other timescales?

- J

1: https://github.com/quicwg/load-balancers/pull/100

On 11-03-2021 22:48, Watson Ladd wrote:
> Dear QUIC WG,
>
> First a moment of unforgivable pedantry. Universal time is
> unfortunately not the right name for UTC, which is slightly different.
> It could also mean UT1 or some other variations  It's also not clear
> what the future of computer timekeeping is and I know several places
> don't synchronize to UTC internally. I think the best way to handle
> this is to say something like "synchronized" and leave open as to
> exactly how that is done.
>
> I agree with the comments that there are too many options and should
> be fewer. Other then that I didn't see any problems but I'm probably
> too sleepy right now to spot them.
>
> Sincerely,
> Watson Ladd