RE: [802SEC] +++ SEC EMAIL BLLOT +++ MOTION: Authorize the Link Security Executive Study Group to become an 802.1 Study Group
Colleagues, I think we all need to recognize that e-mail is, at best, a "best-effort" service that is non-FIFO, and often prone to failures. I think we have to view the time submitted timestamp as the operative deadline rather than the time received, and that even a resent copy of a prior e-mail, which was not received should be counted at least within some time window (e.g. 24-hours after announcement of the results). I think we trust one another enough to not worry about attempts to forge email time-stamps, but it clearly puts a lag-time into the certification of resulting e-ballot outcomes. We've all seen votes that didn't get counted for whatever reason, and I think we need to ensure that every timely vote is in fact counted in the final tally.
In many cases the DNVs are small enough to not effect the outcome of a ballot, but each should at least be viewed as a possible vote not received until proven otherwise.
Thanx, Buzz
Dr. Everett O. (Buzz) Rigsbee
Boeing - SSG
PO Box 3707, M/S: 7M-FM
Seattle, WA 98324-2207
(425) 865-2443 Fx: (425) 865-6721
everett.o.rigsbee@boeing.com
-----Original Message-----
From: Stevenson, Carl R (Carl) [mailto:carlstevenson@agere.com]
Sent: Monday, February 24, 2003 5:09 AM
To: Bill Quackenbush; 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
> -----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