I further agree with Phillip (and Richard) that this is not an IAB
or even a Nomcom chair decision
I disagree. The chair of a committee should have some freedom to
decide what to do in cases not covered by the RFC. The decision he made
(rerun the algorithm with correct input data) is a
Mike,
As it happens the liaisons were both chosen some time ago,
by definition with no knowledge of the chosen volunteers.
We are not going to change the rules on the fly, are we?
Brian
Michael StJohns wrote:
One of the things missing from this years list of volunteers is their
Richard Shockey wrote:
This seems to be on the IETF NOMCOM web page but I do not see it in the
ietf@ietf.org archives.
I suggest that given the unique importance of this NOMCOM cycle that a
fuller explanation is in order.
First .. the instant there was a problem the IETF community should
Mike and Phill,
Phill's assertion is wrong - the IAB and IESG has no control over
this; such decisions are between the Nomcom Chair and the ISOC President.
I don't see anything in RFC 3777 that sends disputes back to
the community. In this case, nobody even got as far as invoking the
dispute
Michael StJohns wrote:
I agree with Phillip - there is no harm here. If someone ineligible
had happened to be selected, they would have been immediately
disqualified and the next number on the list selected. That's why you
actually ask for about 16 numbers to be output when you run the
Title: Re: Now there seems to be lack of communicaiton here...
Brian
Ok if you were not being asked in your official capacity then why not ask me? I have some expertise in security protocols.
Allowing the reset nullifies the process entirely.
Phill
Sent from my GoodLink Wireless
Title: Re: Now there seems to be lack of communicaiton here...
Furthermore the absence of a complaint makes things worse not better.
The nomcon process is meant to eliminate the ability of the establishment to control the process.
ISOC is not above suspicion either. Like every other part
I further agree with Phillip (and Richard) that this is not an IAB
or even a Nomcom chair decision
I disagree. The chair of a committee should have some freedom to
decide what to do in cases not covered by the RFC. The
decision he made (rerun the algorithm with correct input data) is
a
-Original Message-
From: Brian E Carpenter [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 31, 2006 3:29 AM
To: [EMAIL PROTECTED]
Cc: 'IETF-Discussion'
Subject: Re: Now there seems to be lack of communicaiton here...
Richard Shockey wrote:
This seems to be on the IETF
This draft should be clarified slightly.
It has the idea of a chunk but does not adequately define it in relation
to existing standard concepts. Why is chunk necessary when we already
have document and entity defined?
More specifically, the draft does not explicitly state whether the chunk
must
Hi Julian,
--On August 29, 2006 9:17:11 AM +0200 Julian Reschke
[EMAIL PROTECTED] wrote:
FYI Many of your comments were addressed in -14, several of the others
(outdated references) etc will be fixed by the RFC editor. I apologize
that we did not reply to you original message to let you know
Title: RE: Now there seems to be lack of communicaiton here...
The entire process is predicated on their being no freedom of decision.
The lack of any exception planning is due to the central conceit that no exceptions are possible.
Sent from my GoodLink Wireless Handheld (www.good.com)
Mike and Phill,
Phill's assertion is wrong - the IAB and IESG has no control over
this; such decisions are between the Nomcom Chair and the ISOC President.
Unfortunately this makes things much worse, not better. Who's to say that
Andrew didn't intentionally leave the IAB member on the list
At 9:31 PM -0400 8/30/06, Richard Shockey wrote:
Third .. the IETF community AS A WHOLE should have been consulted as to
possible remedies to this problem etc. Consultations to the IESG and IAB
are not sufficient on matters of such gravity.
I think Richard is referring to this in Andrew's
At 04:39 AM 8/31/2006, Eliot Lear wrote:
Michael StJohns wrote:
I agree with Phillip - there is no harm here. If someone ineligible
had happened to be selected, they would have been immediately
disqualified and the next number on the list selected. That's why you
actually ask for about 16
Hey Brian - what say - I am no longer the top poster eh?
Todd
- Original Message -
From: Brian E Carpenter [EMAIL PROTECTED]
To: Michael StJohns [EMAIL PROTECTED]
Cc: 'IETF-Discussion' ietf@ietf.org; [EMAIL PROTECTED]
Sent: Thursday, August 31, 2006 12:24 AM
Subject: Re: Now there seems
Brian,
The advice you gave is exactly the opposite of that in RFC 3797, the
latest version of my non-binding guidelines for publicly verifiable
random selection. Note in particular that Section 5.1 of that RFC says
(with the all caps words in the original):
5.1. Uncertainty as to the Pool
On Thursday, August 31, 2006 06:43:53 AM -0700 Hallam-Baker, Phillip
[EMAIL PROTECTED] wrote:
Furthermore the absence of a complaint makes things worse not better.
Phill, I can assure you from personal knowledge that at least one complaint
_was_ made. As Brian noted, Andrew took action
Rick Jelliffe wrote:
This draft should be clarified slightly.
It has the idea of a chunk but does not adequately define it in relation
to existing standard concepts. Why is chunk necessary when we already
have document and entity defined?
More specifically, the draft does not explicitly state
I think this has already been said in this thread, but just
to be very clear on one point:
Andrew's message does read as if the IAB IESG were somehow
consulted. They were not.
Brian I were on the cc list of one complaint; we certainly
agreed the situation needed addressing. No doubt
Ned Freed wrote:
The goal of
this process is not just to make it hard to game the system, but also
for everyone to be completely confident the system has not been
gamed. Allowing the same person that creates the list the authority
to later reject that list and start over based on an
Granted 3777 does not require the consultation of the community on disputes
involving the NOMCOM but given the highly unusual nature of the problem at
hand and the tendency of the IETF toward anal retentive behavior in matters
of process it seems reasonable to suggest that a wider set of views
-- On Wednesday, August 30, 2006 9:31 PM -0400 Richard Shockey
[EMAIL PROTECTED] wrote regarding Now there seems to be lack of
communicaiton here... --
First .. the instant there was a problem the IETF community
should have been notified in full on this list.
Perhaps, in this particular
Hi,
on 2006-08-31 17:33 Eastlake III Donald-LDE008 said the following:
Brian,
The advice you gave is exactly the opposite of that in RFC 3797, the
latest version of my non-binding guidelines for publicly verifiable
random selection. Note in particular that Section 5.1 of that RFC says
James I also agree with Donald's logic -
So then what happens when the selection process is restarted and the
ramdomizer is used again - say the second time it selects six of the same
candidates and the rest are different out of a pool of 20 or 30 probably.
How is that fair to those selected in
James Galvin wrote:
First .. the instant there was a problem the IETF community
should have been notified in full on this list.
Perhaps, in this particular case, but in general the NOMCOM operates
under the veil of confidentiality.
Specifically, the process of selecting the nomcom does
-- On Thursday, August 31, 2006 10:46 AM -0700 Dave Crocker
[EMAIL PROTECTED] wrote regarding Re: Now there seems to be lack
of communicaiton here... --
James Galvin wrote:
First .. the instant there was a problem the IETF community
should have been notified in full on this list.
James Galvin wrote:
But there is a part of the process that is not public: the
actual selection of eligible volunteers.
1) The criteria are public. 2) The result is public, with the intention
of time for review. I'm not sure how the internals of going from 1 to 2
could be made public
First I should say that being chair of Nomcom when an innocent
mistake like this happens must be a nightmare with every possible
action being subject to criticism. Andrew therefore has a completely
thankless task in resolving this, and I will support what ever he
decides to do.
I cannot see how
-- On Thursday, August 31, 2006 10:40 AM -0700 todd glassey
[EMAIL PROTECTED] wrote regarding Re: Now there seems to be
lack of communicaiton here... --
James I also agree with Donald's logic -
So then what happens when the selection process is restarted and
the ramdomizer is used again
A restart that selected other candidates would not be unbiased.
Todd Glassey
- Original Message -
From: James Galvin [EMAIL PROTECTED]
To: todd glassey [EMAIL PROTECTED]
Cc: 'IETF-Discussion' ietf@ietf.org
Sent: Thursday, August 31, 2006 11:13 AM
Subject: Re: Now there seems to be lack
Don,
I'll reiterate what I said earlier, since it seems to be missed by many
people. The presence of an IAB member on the list, while an issue, is
not my overwhelming concern. My overwhelming concern is the fact that
the volunteer list came out at the same time as the results. That could
allow
Hi -
From: Henrik Levkowetz [EMAIL PROTECTED]
To: Eastlake III Donald-LDE008 [EMAIL PROTECTED]
Cc: IETF-Discussion ietf@ietf.org
Sent: Thursday, August 31, 2006 10:20 AM
Subject: Re: Now there seems to be lack of communicaiton here...
Hi,
on 2006-08-31 17:33 Eastlake III Donald-LDE008
My two cents:
If I were to go to Las Vegas and roll the dice at a crap table, then ask
to roll again because there was a clap of thunder which made my arm
twitch just as I released the dice during the first roll, I assure you
that they would not allow me to do so. They would not be persuaded by
If the main problem is that the Secretariat can't do its vetting job in
time, for whatever reason, to allow the volunteer list to be publicly
posted for a reasonable before selection takes place, there seem to be
approximately three things you could do:
A. Leave as much as you can of the
Andrew Lange [EMAIL PROTECTED] wrote:
A few members of the community have expressed concern over two issues with
the selection process for this year's NomCom.
I'm taking the liberty of responding to the second first.
Second: A sitting member of the IAB's name appeared on the candidate
To address Eliot's comment about the volunteer list -
From Andrew's note that triggered all of this I see that he sent the
list of the volunteers to the Secretariat. If we could have someone
from the Secretariat provide a copy of that email independent of
Andrew and verify it was submitted
Yup. More specifically, A has to happen before close of trading on
the day you're getting your random numbers from.
Unless I'm mistaken, I'm reading an overwhelming consensus NOT to
reset from those posting on this list. Given that close of trading
for Andrew's reset is today we're about to
Mike,
To address Eliot's comment about the volunteer list -
From Andrew's note that triggered all of this I see that he sent the
list of the volunteers to the Secretariat. If we could have someone
from the Secretariat provide a copy of that email independent of
Andrew and verify it was
--On Thursday, 31 August, 2006 09:38 +0200 Brian E Carpenter
[EMAIL PROTECTED] wrote:
Full disclosure: My personal opinion, which I *did* give to
Lynn and
Andrew when I became aware of this glitch, is that a reset is
the only
way to be certain that the selection process is unbiased.
On Thursday, August 31, 2006 09:26:11 AM -0700 Dave Crocker
[EMAIL PROTECTED] wrote:
Ned Freed wrote:
The goal of
this process is not just to make it hard to game the system, but also
for everyone to be completely confident the system has not been
gamed. Allowing the same person that
John,
If the selection method is random, it makes no difference whatsoever how
the list of nomcom volunteers is ordered. It only matters that the
numbered list become fixed and be posted before the selection
information is available. Alphabetic or the order they volunteered or
any other order is
My concerns are pretty much the same as John's here except that I care less
about the outcome of this round than the precedent that would be set. The
statement 'this is not a precedent' does not make it any less of a precedent.
If you have a problem in a normal election process then a re-vote
On 8/31/06 at 9:38 AM +0200, Brian E Carpenter wrote:
Full disclosure: My personal opinion, which I *did* give to Lynn and
Andrew when I became aware of this glitch, is that a reset is the
only way to be certain that the selection process is unbiased.
Brian, the fact that Andrew Cc'ed you on
Elliot -
What about those that may not be in the selection pool this time around -
how fair would that be to them?
Todd Glassey
- Original Message -
From: Eliot Lear [EMAIL PROTECTED]
To: Michael StJohns [EMAIL PROTECTED]
Cc: IETF-Discussion ietf@ietf.org
Sent: Thursday, August 31, 2006
The problem is demonstrative of the real issues with the IETF's processes
and that they are designed by people who particularly don't plan for
contingency - its a true testament to the Arrogance of the Technical Mind in
screaming loudly all the way to the Gallows that it mailed the check.
The
Phillip congrats - re-votes are dependant on a fully defined election
process with oversight and proper what-if contingencies that are pre-planned
and not fixed in an ad-hoc manner.
- Original Message -
From: Hallam-Baker, Phillip [EMAIL PROTECTED]
To: John C Klensin [EMAIL PROTECTED];
At 20:38 31/08/2006, Cimbala, Matthew wrote:
In my opinion we should not rerun the process.Rerunning the
process is the exact wrong thing to do.The decision to do so was
no doubt made in good faith, and with the best of intentions, but it
is clearly incorrect.
+1
On Thu, Aug 31, 2006 at 05:55:25PM -0400, Jeffrey Hutzelman wrote:
Therefore, I propose the following:
(1) Andrew's decision stands. Under RFC 3777, the only recourse available
to anyone who disagrees with that decision would be to ask Andrew to
reconsider or to file a dispute with
The philosophers have analysed the IETF election process in many ways, the
point is to change it
If you are going to have a procedure like this it would be best to eliminate
the influence of the listing process to the greatest extent possible,
discussing this with my wife, a political
I agree that this seems to be the best course available.
Yours,
Joel M. Halpern
At 09:08 PM 8/31/2006, Theodore Tso wrote:
On Thu, Aug 31, 2006 at 05:55:25PM -0400, Jeffrey Hutzelman wrote:
Therefore, I propose the following:
(1) Andrew's decision stands. Under RFC 3777, the only recourse
(1) Andrew's decision stands. Under RFC 3777, the only recourse available
to anyone who disagrees with that decision would be to ask Andrew to
reconsider or to file a dispute with the ISOC President. The former
has already been done, and so far no reversal has been announced.
we
I agree as well. Again, having started this charming little discussion
thread, any other course of action at this late stage would cause more
problems than it would solve.
R. Shockey
-Original Message-
From: Joel M. Halpern [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 31,
Therefore, I propose the following:
(1) Andrew's decision stands. Under RFC 3777, the only recourse available
...
(2) Text is added to the next version of the selection process to addresss
No one has expressed a concern that there was an attempt, here, to game
the process, or that re-doing
PS - I do think its fully in Andrew's remit to make this decisison
and I do not think it would be good for the IETF for anyone to
appeal his decision
Scott
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
Folks,
I think that volunteering for the nomcom is something that I should do
as a duty to an organization I feel part of, and an organization I
often ask for volunteers from myself.
Having serveed on one nomcom in the past, I know something about what
a complex (that's the best word I can
As someone who was actually selected in the previous round and started this
little thread, I support this position.
I've reviewed the specification for this process, including the random
selection algorithm, several times over the past few years. I've always
believed the selection process
On Aug 31, 2006, at 3:27 PM, John Leslie wrote:
Andrew Lange [EMAIL PROTECTED] wrote:
A few members of the community have expressed concern over two
issues with
the selection process for this year's NomCom.
I'm taking the liberty of responding to the second first.
Second: A
Total of 92 messages in the last 7 days.
script run at: Fri Sep 1 00:03:02 EDT 2006
Messages | Bytes| Who
+--++--+
1.09% |1 | 23.75% | 188337 | [EMAIL PROTECTED]
7.61% |7 | 11.07% |87736 | [EMAIL
This is the revised list of NomCom Volunteers for 2006/07. Thanks
again to all the people who volunteered!
Andrew
--
1 Brian Haberman
2 Brian Rosen
3 Carl Williams
4 Cengiz Alaettinoglu
5 Dan Li
6 Dan Wing
7 Dave Crocker
8 Derek Atkins
9 Dimitri Papadimitriou
10 Donald Eastlake
11
A few members of the community have expressed concern over two issues with
the selection process for this year's NomCom.
First: The list of volunteers was published later than recommended by RFC
3777. This happened because, after the nominations period closed, there
was some dispute on the
A new Request for Comments is now available in online RFC libraries.
RFC 4616
Title: The PLAIN Simple Authentication and
Security Layer (SASL) Mechanism
Author: K. Zeilenga, Ed.
Status: Standards Track
Date:
A new Request for Comments is now available in online RFC libraries.
RFC 4630
Title: Update to DirectoryString Processing in
the Internet X.509 Public Key Infrastructure
Certificate and Certificate Revocation List (CRL)
A new Request for Comments is now available in online RFC libraries.
RFC 4653
Title: Improving the Robustness of TCP
to Non-Congestion Events
Author: S. Bhandarkar, A. L. N. Reddy,
M. Allman, E. Blanton
The IESG has received a request from the Layer 3 Virtual Private Networks
WG to consider the following documents:
- 'Network based IP VPN Architecture Using Virtual Routers '
draft-ietf-l3vpn-vpn-vr-03.txt as an Informational RFC
- 'Using BGP as an Auto-Discovery Mechanism for VR-based Layer-3
The IESG has received a request from the DNS Extensions WG to consider
the following document:
- 'DNSSEC Opt-In '
draft-ietf-dnsext-dnssec-opt-in-09.txt as an Experimental RFC
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send
The IESG has received a request from the Host Identity Protocol WG to
consider the following document:
- 'Host Identity Protocol '
draft-ietf-hip-base-06.txt as an Experimental RFC
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please
The IESG has received a request from the DNS Extensions WG to consider
the following document:
- 'DNSSEC Experiments '
draft-ietf-dnsext-dnssec-experiments-03.txt as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.
A new Request for Comments is now available in online RFC libraries.
RFC 4575
Title: A Session Initiation Protocol (SIP)
Event Package for Conference State
Author: J. Rosenberg, H. Schulzrinne,
O. Levin, Ed.
A new Request for Comments is now available in online RFC libraries.
RFC 4484
Title: Trait-Based Authorization Requirements for the
Session Initiation Protocol (SIP)
Author: J. Peterson, J. Polk,
D. Sicker, H.
A new Request for Comments is now available in online RFC libraries.
BCP0122
RFC 4632
Title: Classless Inter-domain Routing (CIDR): The
Internet Address Assignment and Aggregation Plan
Author: V. Fuller, T. Li
A new Request for Comments is now available in online RFC libraries.
RFC 4474
Title: Enhancements for Authenticated Identity Management
in the Session Initiation Protocol (SIP)
Author: J. Peterson, C. Jennings
Status:
A new Request for Comments is now available in online RFC libraries.
BCP0121
RFC 4611
Title: Multicast Source Discovery Protocol (MSDP)
Deployment Scenarios
Author: M. McBride, J. Meylor,
D. Meyer
A new Request for Comments is now available in online RFC libraries.
RFC 4607
Title: Source-Specific Multicast for IP
Author: H. Holbrook, B. Cain
Status: Standards Track
Date: August 2006
Mailbox:[EMAIL
A new Request for Comments is now available in online RFC libraries.
RFC 4605
Title: Internet Group Management Protocol (IGMP)
/ Multicast Listener Discovery (MLD)-Based Multicast
Forwarding (IGMP/MLD Proxying)
A new Request for Comments is now available in online RFC libraries.
BCP0120
RFC 4608
Title: Source-Specific Protocol Independent Multicast in
232/8
Author: D. Meyer, R. Rockell,
G. Shepherd
A new Request for Comments is now available in online RFC libraries.
RFC 4610
Title: Anycast-RP Using Protocol Independent Multicast
(PIM)
Author: D. Farinacci, Y. Cai
Status: Standards Track
Date: August
A new Request for Comments is now available in online RFC libraries.
RFC 4604
Title: Using Internet Group Management Protocol
Version 3 (IGMPv3) and Multicast Listener
Discovery Protocol Version 2 (MLDv2) for
78 matches
Mail list logo
