NOMCOM term limits... Re: Now there seems to be lack of communicaiton here...

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Title: 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 -----
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.Eastlake@xxxxxxxxxxxx]
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@xxxxxxxxxxxx]
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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]