Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

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
> 
>