Re: [802SEC] +++ SEC EMAIL BLLOT +++ MOTION: Authorize the Link Security Executive Study Group to become an 802.1 Study Group
Carl,
Comment inserted below.
Thanks,
wlq
"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]
> >
> > 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 ...
Yes, both methods are flawed. Given the unbounded and non deterministic
nature of the delivery problem, I doubt that there are any relatively
easy solutions that are not flawed (deterministically correct). I was
trying to suggest some relative simple ways of reducing the chance of a
vote being discarded due to delivery delays.
>
> >
> > 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
>
>