Re: proposed NANOG charter amendments
On 9/27/07, Joe Abley [EMAIL PROTECTED] wrote: On 27-Sep-2007, at 1716, Martin Hannigan wrote: The authors of these things should be identified in case we want to vote them out of whatever they were voted into. Could you be more specific? I'm not sure what these things means, in this context. Wrong focus. Try open and transparent instead. -M
Re: proposed NANOG charter amendments
The issue that arises from it is that there ought to be a requirement that if you are going to make a proposal, claim that you have support, etc. that we have names instead of broad statements like the one above. not sure i have what you're getting at, not even sure which of the two proposed amemndments, but lemme try. the sc as a whole agreed that the requirement that all pc members review all submissions was inappropriate. according to charter, the sc then makes an amendment proposal. a non-sc volunteered to draft a proposed amendment. this was subsequent to sc discussion at our last con call. feeling that it was important to get the members involved as early as possible (and it is kinda late already), it was decided to toss that draft out here in -futures, as opposed to reviewing it just within the sc. as you have seen, even within the sc, there are different feelings about the wording, though not about the general intent. but we felt it would be better to air them here, where non-sc folk would have equal footing. randy
RE: proposed NANOG charter amendments
by whom? pc chair? sc (which appointed them)? michael dillon? I think michael dillon is a fine choice. Vijay, it is rude to make fun of people who are showing their senility. Stop picking on Randy. In any case, I would think the committee should be able to remove its own members by voting them out for cause. If the cause is in the bylaws, then the process doesn't need to be there in every detail. And if a committee did not feel it within their power to remove a member then they should certainly feel it in their power to petition the appointing body (sc) to do so. Again, this process is common sense and doesn't need to be codified to the nth degree. I say: NO TO THE BUREAUCRATIZATION OF NANOG! DOWN WITH THE RUNNING DOG LACKEYS OF PROCEDURALISM! Does anyone still hold to Common Sense as a virtue? --Michael Dillon
Re: proposed NANOG charter amendments
The original intent seems to have been to provide a mandatory participation bar, which would explain why it is coupled with the 'meet too many meetings and you're out' portion. i believe all this is because, in the past, there was a problem with deadwood on the pc. i think the attempt to relax the requirement that all pc members review everything is, at least partly, due the success of the post-revolution changes giving more accountability and transparency. i wonder if the inclination to put a bunch of words in could possibly be motivated by a lack of total faith that the deadwood problem is fixed or fear that it may re-arise. [ i really mean the word wonder. i really do not know. ] randy
RE: proposed NANOG charter amendments
On Thu, 27 Sep 2007, Michael K. Smith - Adhost wrote: Proposal 2: Shall program committee members be permitted to skip rating presentation proposals that do not fall into their areas of expertise? Wording: Change the third paragraph of Section 8.3.2 as follows: Old version: Each member of the Program Committee must review all presentations submitted for each meeting. The Chair may excuse a member from one meeting's review cycle due to extenuating circumstances, but if a member misses two meetings in a row, he or she may be removed from the committee. New version: Each member of the Program Committee must review all presentations submitted for each meeting and rate those presentations which fall into their areas of expertise. The Chair may excuse a member from one meeting's review cycle due to extenuating circumstances, but if a member misses two meetings in a row, he or she may be removed from the committee. It seems like you're talking about two totally different things here, punitive actions for missing meetings and requirements for PC Members to audit presentations. Unless it's really worth defining both separately I would scratch the whole thing. If you need to define punitive actions, why not just say a simple majority may take action to remove a Program Committee Member for cause. The first sentence, taken alone, could be listed as a portion of PC Members assigned duties (if such a thing exists). Since we're amending an existing document, this would be two separate changes. The one being proposed here is supposed to reduce the requirements for Program Committee members (although, rereading it, I see that in the old version there wasn't actually a requirement for members to rate anything, as opposed to just reviewing things, so maybe it accidentally adds more requirements instead). It does that by adding a few words to an existing paragraph. The other thing being debated is the language about the procedure for removing Program Committee members. That's in the same paragraph, because it's how we wrote it a few years ago, but it's not really related to this proposal. If it needs to change, that should probably be done via a separate amendment. I don't have strong feelings on the merits of either of the proposed amendments (and as long as I'm drafting charter changes at the request of an elected committee I'm not part of, any strong feelings I might develop should probably be kept out of this). I can talk to some degree about the initial intent of the charter, with the caveat that there were lots of people involved and we may not have all intended the same thing. My intent, which was fairly influential since I was the last one to do major editing on the document, was to to make sure the Steering Committee selection process was very clear, to give them some power, and beyond that to give them a pretty free hand. They were going to be elected, while those of us working on the charter were self-appointed, so any decisions they made were going to have a lot more legitimacy than the decisions we were making. Others had some very strong concerns about the operation of the Program Committee, so that got specified in probably more detail than I would have preferred. So, in that vein, it seems to me that that the vagueness in the Program Committee member-removal text is ok. The Steering Committee is in charge, and if there's a desire to remove a member of the Program Committee, the procedure ought to be whatever they say it is. But, that said, we also intended the charter to be changeable if people felt the need to do so. That's what the Amendments procedure is there for. -Steve
Re: Visualizing the routing table
On Thu, 27 Sep 2007, Nathan Ward said: Is the older pictures based on older allocation data, or present-day data? I assume you are refering to the labels showing to whom each block is allocated? Those come from IANA's file at http://www.iana.org/assignments/ipv4-address-space, which gives the date (just month and year) of each allocation.I dont have an archive of that file so to show the state of things in the past I just change any allocation after a given date to Unallocated. The routing table data (the colored bits) comes from Routeviews, which has a good archive. BTW, one thing that really stands out if you watch the animation is the two times (July 2005 and June 2006) where routes appeared for large areas of unallocated space. Duane W.
Re: WG Action: Conclusion of IP Version 6 (ipv6)
On Thu, 27 Sep 2007 13:59:53 -1000 Randy Bush [EMAIL PROTECTED] wrote: The REAL problems are not going anywhere for a long time, if ever. indeed, many will be with us for a long time. but there are a bunch we could knock off in a few years o dual stack backbones (and it's as much the vendors as the isps here) o dual stack consumer cpe o routers that hold 2m routes *with churn* from enterprise to backbone o test equipment to differentiate vendor hot air from actual performance o nat-pt with standardized algs for at least dns, smtp, http, sip, and rtp I once complained to Bjarne Stroustrup about some aspect of C++. He replied that it was not the best possible language, but rather the best language possible. He was dealing with programmers who were recent converts to C; indeed, many of them had only recently been weaned from lower-level assembler languages. (Doug McIlroy once told me that C was the best assembler language he'd ever used. I agree with him.) I feel much the same about IPv6. IPv6 isn't what I wanted it to be. During the IPng directorate, several of us (including me and at least one of the chairs) pushed very hard for id/locator split. We lost. That was 1994; it's over and done with. But it took 13 years from then to a (mostly) complete set of specs and universal implementation, at least in all systems shipping today. Even if there was universal agreement that the design was wrong and that we should start over, I can't see it taking less than 10 years to get back to the current level of maturity. We don't have that long. We don't even have any guarantees that we'd get everything right if we tried again; while we could avoid today's known pitfalls, I'm sure there are \aleph_0 more waiting for us. To me, then, the question is now what? We have to get off of v4. We're dying the death of a thousand NATs. What we have to do is push the responsible parties -- CPE vendors, ISPs, router vendors, and yes, the IETF -- to fill in the holes. --Steve Bellovin, http://www.cs.columbia.edu/~smb
