RE: Now there seems to be lack of communicaiton here...Its time to talk about
term limits for NOMCOM appointments. Two or maybe three terms at most are
enough. If the IETF cannot bring in fresh management blood then it has become
unnecessary and a vehicle through which only those initiatives approved by the
sitting management ever get undertaken.
Its time for some reform.
Todd Glassey
----- Original Message -----
From: Hallam-Baker, Phillip
To: Eastlake III Donald-LDE008 ; IETF-Discussion
Sent: Saturday, September 02, 2006 7:24 PM
Subject: RE: Now there seems to be lack of communication here...
Actually the scheme I propose does not depend on pre-announcement of the
list, only providing a proof of registration.
I have not worked out exactly to avoid every attack but there is certainly no
need to publish everyone's email address - although it is odd that you would
mention that as the IETF is currently publishing my telephone number I gave
when registering for a previous IETF. Certainly every selected member of NOMCON
has to be reachable by email.
All you require is a unique identifier. It could be the participant's name.
If a person is registered twice and this is detected then you use the name that
occurs first in some canonical ordering.
The registration mechanism could be a Web form that you fill in that causes a
receipt to be sent to the email address specified. That way a registrant has a
proof that they registered and can use that to challenge the list.
----------------------------------------------------------------------------
From: Eastlake III Donald-LDE008
[mailto:Donald(_dot_)Eastlake(_at_)motorola(_dot_)com]
Sent: Saturday, September 02, 2006 6:39 PM
To: IETF-Discussion
Subject: RE: Now there seems to be lack of communicaiton here...
Depends what you mean by "it". The overall process may have broke in this
case but the "it" referred to in the message you were responding to is the
"cryptographic" part of the process. The one in RFC 3797 depends on
pre-announcement of the ordered list of volunteers. The one you suggested
depends on pre-announcement of the email address of every volunteer. Neither is
any more robust than the other against a failure to make all the information
necessary for public verification available in advance, including the
specification of the source of future randomness.
Donald
----------------------------------------------------------------------------
From: Hallam-Baker, Phillip [mailto:pbaker(_at_)verisign(_dot_)com]
Sent: Saturday, September 02, 2006 10:00 AM
To: John C Klensin; Ned Freed; Eastlake III Donald-LDE008
Cc: IETF-Discussion
Subject: RE: Now there seems to be lack of communicaiton here...
If it ain't broke? How much more evidence of being broke do we need?
The bug here is that the process is insufficiently robust under operator
error.
That is broke.
The underlying problem here is the lack of auditability in the process.
There is a simple fix here, eliminate the dependency on the list ordering
and the system does not have such a critical dependence on the operator.
Again nobody is claiming anything dishonest has happened here. The concern
is that the accident could be repeated on purpose in the future to exclude
undesirable candidates. Having spent part of last month watching this attempted
in Alabama it is a real concern.
When something is broke admit the fact. Prattling on about not fixing what
aint broke only makes people angry.
Sent from my GoodLink Wireless Handheld (www.good.com)
------------------------------------------------------------------------------
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf