RE: [802SEC] +++ SEC EMAIL BLLOT +++ MOTION: Authorize the Link Security Executive Study Group to become an 802.1 Study Group
> -----Original Message-----
> From: Bill Quackenbush [mailto:billq@attglobal.net]
> Sent: Sunday, February 23, 2003 4:47 PM
> To: Paul Nikolich
> Cc: IEEE 802 SEC
> Subject: Re: [802SEC] +++ SEC EMAIL BLLOT +++ MOTION:
> Authorize the Link
> Security Executive Study Group to become an 802.1 Study Group
>
>
>
> Paul,
>
[snip]
> I will admit that I have often noticed email from various
> IEEE 802 email
> reflectors arriving MANY hours after their initiation date
> stamps. But
> I failed to relate that to the delivery time of email votes on 802 SEC
> ballots. Shame on me. This time, it has my attention.
>
> I am not in general willing to accept my vote being rejected
> because it
> was "late" being received even though it was sent hours before the
> stated ballot closing time (when corrected for time zone). And I
> suggest that others may feel the same way.
>
> First, I believe that the ballot must state clearly what that closing
> time means. Is the the closing time for vote transmission (like to
> filing of US income tax) or the closing time for vote reception?
>
> Second, given this incident, I believe that we need some formal
> allowance for email delivery delay. Possible solutions
> include the following.
>
> 1) Have a minimum time delay between when the ballot
> "closes" and when the acceptance of votes closes. Based
> on this incident, the delay would need to be at least
> 8-12 hours.
>
> 2) Assuming that emails to a given 802 reflector are queued and
> serviced in order, send a "the ballot is closed" email at the stated
> ballot closing time and close the reception of votes only
> after the "the
> ballot is closed" email is received back from the reflector.
I believe that both of these approaches are flawed ... the first
doesn't guarantee that someone's e-mail that was SENT in a timely
fashion isn't hung up in stuck server queue somewhere in transit.
The second only guarantees that the path to Paul from the IEEE server
is "prompt" ... it says nothing about MY (or anyone else's) ability
to send and receive e-mails due to network problems ... problems that
they may have no knowledge of ...
>
> Thanks,
>
> wlq
>
> Paul Nikolich wrote:
> >
> > Bill,
> >
> > After inspecting the header, I see that you are
> correct--IEEE held it for more than 4 hours.
> >
> > At any rate, I must use the timestamp of my machine as the ultimate
> > indicator of whether or not the deadline was made.
Paul ... why must the "received" timestamp on your machine be
the standard as opposed to the "sent" timestamp from the
sender's machine? I assume that the members of the SEC all trust
each other to not cheat on voting, right?
Due to (occasional) unpredictable latencies in internet relays
(and, apparently the IEEE servers), I would propose that the
"sent" timestamp of messages should at least be considered, if
not be the standard.
Regards to all,
Carl