RE: [802SEC] +++ SEC EMAIL BLLOT +++ MOTION: Authorize the Link Security Executive Study Group to become an 802.1 Study Group
I guess that, given that the delay between sending and receiving is
essentially unbounded, making the time stamp on Paul's machine the deciding
factor at least bounds the problem and allows the ballot to close in a
finite time (albeit at the expense of creating the potential for the kind
of problem we have seen here).
Maybe a viable alternative would be a web-based voting system?
Regards,
Tony
At 08:08 24/02/2003 -0500, Stevenson, Carl R (Carl) wrote:
> > -----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