Re: Ok .. I want my IETF app for my iPad ..
Tim Bray wrote: On Sun, Apr 4, 2010 at 11:38 AM, Mark Nottingham m...@mnot.net wrote: Step-by-step instructions (with illustrations) for Americans to use their credit cards overseas. Anyhow, it has to be an iPad app, rather than iPhone/iPod-touch, because the smaller devices can't display 80-char-66-line ASCII properly. -T Just thinking what would happen if someone were to propose a Windows 7 app for the IETF. Maybe Wordpad to write those pesky ASCII I-Ds, maybe a meeting planner, scheduler and calendar, maybe a program to help organize and read all of those pesky e-mail lists. I know someone has to have done something like that... Oh wait - I'll leave you back to your regularly scheduled vendor specific lock-in now. Bill (darn it - 3 days late - but I had to skip April Fools this year) ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Westin Bayshore throwing us out
Yeah - but who wants to go to Minneapolis one more time /duckcover Bill Dave Crocker wrote: Fred Baker wrote: well, it's gotta be the IAOC's fault then. Tell you what, you can cut my IAOC salary in half as a penalty. Nah. You deserve every penny you get. In fact, let's double your salary, for taking all this crap from the peanut gallery. The IAOC is looking at the coming budget, and about to discuss it with the ISOC Board. ... That is in part what Ray has been doing in getting hotel contracts two years out, and in making a deal with the Hilton company about repeat business at Hiltons. But maybe we're willing to pay extra for no construction. Getting reduced rates has always been a goal and the benefits of signing early were discussed perhaps 15 years ago. So we certainly don't want to reverse any of that fine, recent improvement. Your last sentence is interesting, however, in the idea that we would have to pay extra in order to ensure that the hotel does not make it impossible for us to do our work. While that wasn't your wording, I think it is a realistic implication. I keep thinking that folks who rent space are renting the right to use it, and that a landlord who makes the space unusable is at fault. One does not need to pay extra for the right; the rent already is the payment. And I think the IETF meeting situation is comparable to renting space, albeit with a more interesting payment model. We still seem to be constantly wandering into hotels for the first time, and somehow it's hard to believe that that doesn't cost the IETF a premium, if only in staff time learning the new place, especially for the net ops folk. I even wonder whether repeating among a small set of venues would not also lead to some relationship building between the different staffs, thereby making everything go a lot more smoothly? d/ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF/US General Election
Be careful offering legal advise. I believe what you are proposing is a state issue. For example in Oregon we ONLY have mail in ballots. Other states will have varying degrees of absentee balloting - each with their own fun interpretations. Bill Moskovitz, Ram Austryjak wrote: You can choose permanent absentee status and vote using paper indefinitely. -Original Message- From: Michael C. StJohns [mailto:[EMAIL PROTECTED] Sent: Monday, October 09, 2006 2:43 PM To: ietf@ietf.org Subject: IETF/US General Election Just a reminder - (and apologies to our non-US participants) For the first time ever (at least I can't remember another occurrence) the US bi-annual general elections will occur during an IETF week. If you're a US citizen and planning on voting this cycle (and not from San Diego!), don't forget to submit a request for an absentee ballot before your state's deadline. Mike ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations' to Proposed Standard
Robert Elz wrote: I cannot see why there's a debate going on here. If someone, anyone, can read a spec, and, in good faith, point out a possible ambiguity in the text, before the doc is finalised, and if fixing it to avoid the problem is easy, what possible justification can there be for not adding a few words to clarify things, and make sure that confusion does not happen? Whenever someone points out a problem like this, the response should be something like OK, if we write it like ... does that make it clear? or perhaps What would you suggest as clearer wording? but never It is clear enough as it is as the latter is already demonstrated to be false. My mother can't read internet drafts either. Should we change our language so that my mother can read and comprehend them. It is assumed that there is a baseline knowledge when we write drafts... If you don't know how MIBs work in general - there are a LOT of problems that you have to sort out before you can provide technical feedback to the community. Someone who is practiced in the art of reading/writting/implementing MIBs isn't going to have a problem with strictly monotonically increasing Indexes - knowing what that means, and how to implement it and test the implementation for correctness. Somone who has been watching a rant on the list recently invovling the work monotonically increasing, MIGHT see the word and get confused. I am not to worried about that - the document really isn't for their eyes anyway (I'm not about to comment on various security drafts either - should they be simplified so I can understand them, I hope I am expected to put in the work so that I understand them instead) Certainly it is possible to explain the wording on the list, and convince the objector that very careful understanding of the context makes the intent clear - but that does nothing for the next person who comes along and makes the same interpretation mistake (perhaps without even realising the possibility for ambiguity, but simply interpreting the text a different way). Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'TLS User Mapping Extension' to Proposed Standard
I saw all of the huff, and while I agree with it, I am more concerned about Appendix A. IPR Disclosure TBD What does that mean, and more specifically is a document with a TBD section really ready for last call at all ? Bill Russ Housley wrote: I misunderstood the original question. I'll get it fixed or withdraw the Last Call. Russ At 12:38 AM 2/19/2006, Bill Fenner wrote: Can we have a Proposed Standard without the IETF having change control? No. RFC3978 says, in section 5.2 where it describes the derivative works limitation that's present in draft-santesson-tls-ume, These notices may not be used with any standards-track document. Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA Considerations
John C Klensin wrote: --On Wednesday, 06 July, 2005 15:23 -0700 Bob Braden [EMAIL PROTECTED] wrote: * harmful, and that the best way to insure coverage of IANA issues is to have an * explicit check for such things as part of our review process. Ned, As I expect you know, the IANA checks all documents at Last Call time, and the RFC Editor checks them before publication, for missing missed IANA actions. However, redundancy does not seem to me to be a bad idea. Bob, as I expect you know, the IANA no longer has the staff skills to perform an in-depth analysis of a document to determine whether there are issues IANA needs to deal with. Yes, I think they try, but the whole purpose of this section was to move toward providing them better instructions and hints than go do your own detective work. I'm grateful that the RFC Editor continues to make those checks, but it is in everyone's interest that the IANA actions be understood much earlier in the process, leaving the RFC Editor review as the safety net of last resort. That said, I think we should be paying careful attention to Bruce's implied suggestion about how template boilerplate-generators should be constructed. In terms of the checking process Ned asks for (and which I still believe is the right solution) there is a world of difference between a template that generates: IANA Considerations Nothing for IANA to do and one that generates IANA Considerations If you see this text, the author hasn't gotten around to thinking about this issue. john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf I actually would prefer IANA Considerations This section left intentionally blank Reminds me of some wonderful manuals back in the day (and frankly currently as well) Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Need for an Agenda Cutoff date?
Brian E Carpenter wrote: Joe, There is an agenda cutoff that WG chairs are supposed to respect. This time it was: The agenda for the Working Group is due by Monday, February 28 at 12:00 ET (17:00 GMT). But there were many late agendas and there was a glitch in the process of posting them. Guilty (IPoIB WG Chair here) - now solution space For BOFs, the formal BOF proposal must include an agenda, and that was due this time on February 21. We need to try and follow our own rules next time. Time to get Hard about this - if WG agendas aren't published by the cutoff date - the WG doesn't meet. Anyone I've ever talked to says good meeting practice includes publishing an agenda - if there isn't enough interest in publishing an agenda, there isn't enough interest in attending a meeting. If a WG is scheduled to meet on the cutoff date and there isn't an agenda published on the cutoff - a message goes to the WG chair (and maybe to the WG as well) with a warning and if they don't get an agenda to the IETF in 24 hours... CANCEL THE MEETING Brian - is this going to be your first contribution to the IETF as the incoming chair ? Bill (who would have had his meeting cancelled today with these rules - but this is the right thing to do) Brian Joe Touch wrote: Hi, all, With agendas appearing ever later - including last night, the issue of cutoff dates should be revisited. If reading the drafts to be discussed is NOT an issue, then the I-D cutoff dates should be dropped. If reading the drafts IS an issue, then, by correlary, there should be a corresponding cutoff date for agendas - e.g., 1 week after the last cutoff I-D date. Jjust as I-Ds that pass the cutoffs are not published for this IETF, WGs that fail to meet that deadline should be CANCELLED. Consider this a proposal, or at least a request. Joe ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Excellent choice for summer meeting location!
I don't know how airline pricing works in .au - but here in the .us it seems that adding a short flight into a more regional airport can more than double the cost of an airplane ticket. Also note that a town of 100,000 will seldom have conference space that can host a conference that attracts 1500 people - I know of no such facility in Hillsboro (where I live) that is outside of Portland (more a suburb, than a regional center). I would be interested in knowing what somewhere like Spokaine, Boise, or other smaller site might have. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dassa Sent: Monday, January 03, 2005 12:55 PM To: 'John C Klensin'; 'IETF Discussion' Subject: RE: Excellent choice for summer meeting location! | -Original Message- | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] | On Behalf Of John C Klensin | Sent: Tuesday, January 04, 2005 12:19 AM | To: [EMAIL PROTECTED]; 'IETF Discussion' | Subject: RE: Excellent choice for summer meeting location! | Dassa, | | For better or worse, we've had a preference for locations | close to major airports with significant international connections. | We haven't been consistent about it (note, e.g., San Diego), | but, unlike that other organization whose name starts with I | (not IEEE, Glen), we have considered it a really bad thing | if most of the attendees have to spend two days getting to | and/or from a meeting: turning a five-day meeting into an | eight- or nine-day one is really hard on those who have | other things to do | besides going to meetings.I have no idea how the boondocks | of NSW would fall on that criterion, but it is what has kept | us near or in fairly major cities. | Hello John I was being a little tongue in cheek but the suggestion of regional centers being used is one I pursue for a lot of groups. Living in the country in a smallish city, a lot of meetings occur in the capitals that I and others just don't get a chance to attend. I'm sure it would be the same in a lot of areas. I can understand the issues but the benefits all round may overcome them. For instance where I live is only an hour flight from Sydney, you ask, why don't you fly there for meetings and I have to explain, being in a regional area, the finances available for travel are limited. We tend to get paid less than equilivant workers in the capitals and companies out here are less likely to approve spending on non-essential travel. It is also a fact that connections out in regional areas are often less than optimal for most people so this has an impact for online participation. It is only recently I was able to get ADSL at home for instance and operated for years with a dialup that meant long hours for participation online and I missed a lot of broadcasts due to downloading constraints. My suggestion is the IETF considers moving some meetings out to regional centres within reasonable travel of the major ingress airports in an effort to promote awareness and participation. Within the States and other countries, I'm sure there would be some benefits in holding meetings at cities with populations of 30,000 - 100,000 or so rather than the capitals and other major cities with populations into the millions. There are issues with such locations and they may be insurmountable but I would like to see the idea considered. Given more people making lifestyle changes that involve moving away from major cities, it may become more important in the future. Darryl (Dassa) Lynch ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Adding [ietf] considered harmful
Hmmm, I am wondering if running this e-mail thread is adding a couple years worth of 6byte additions to the subject. Seems silly to me - I prefer lists to do this - makes many peoples life easier - doesn't make anyones life harder (and frankly if 6 bytes is going to blow your bandwidth budget - you have worse troubles than this proposal) Please consider this as someone who thinks it is a good idea because some people want it - regardless if they can jump through 10 more hoops and get the same functionality with filters (on what ? - I hate it when people bcc: mailing lists and you loose the from/cc field containing the mailing list you are filtering on) - procmail (oppps what about the people that don't use that, etc. Bill On Thu, Dec 18, 2003 at 10:39:21AM +1200, Franck Martin wrote: Because we, people on the road, use various mail systems and even web based mail, where the filters are not applied yet... Why such a war for just 6 characters, while all mailing lists do it? Have you been out there? Let's give it a try and see... Cheers On Thu, 2003-12-18 at 04:26, Keith Moore wrote: would it be asking too much to add [ietf] to the subject line of each message? yes. it's completely redundant information, and it interferes with readability, particularly on small displays. why don't you get a better mail reader that lets you classify mail as it arrives? that is a much better way to distinguish one list's traffic from another. Franck Martin [EMAIL PROTECTED] SOPAC, Fiji GPG Key fingerprint = 44A4 8AE4 392A 3B92 FDF9 D9C6 BE79 9E60 81D9 1320 Toute connaissance est une reponse a une question G.Bachelard
Re: Proposal to define a simple architecture to differentiate legitimate bulk email from Spam (UBE)
Why is this even difficult. I have yet to see a firm proposal (ie. an Internet Draft), and once there is one, it is a simple matter of asking an AD to sponsor a BOF to see if there is interest in forming a working group to solve the problem. I remember sitting through several YATP (Yet another Tunnelling Protocol) BOFs years ago, I don't see what the problem is with creating some YASPP BOFs (Yet Another Spam Prevention Protocol). This is the IETF, that is the IETF process... Why are we arguing here about killing it without having a firm proposal, and a BOF chartered to form a WG to go solve the problem. Any more breath we waste now doesn't help anybody. My challenge - Go forth - publish your protocol in ID form, contact the correct APP (probably) area AD and get a BOF in Minneapolis - Convince the IETF in general there that a WG should be chartered to solve the problem. Go and solve the problem Bill On Tue, Sep 09, 2003 at 01:41:33PM -0400, Dean Anderson wrote: My apologies for this message. This discussion is winding down. Iljitsch makes some interesting points, to which I have tried to respond thoughtfully. --Dean On Tue, 9 Sep 2003, Iljitsch van Beijnum wrote: On maandag, sep 8, 2003, at 17:30 Europe/Amsterdam, Dean Anderson wrote: Nobody cares. Making a roof 100.00% impervious to water molecules may be impossible, but that doesn't mean we have to resign to getting wet every time it rains. People care because when someone comes around saying you can have a 100% impervious roof if only you jump through these inconvenient hoops, we know that they are wrong, and don't need to waste time considering how inconvenient the hoops are. Your analogy doesn't fly. Our email protocols have holes big enough to drive a truck through. Is it unreasonable when people ask the IETF leadership for a place to work on this? I don't think our email protocols have any holes at all. They can be abused. But mere abuse is not a hole. We, meaning the IETF, care, because this is very useful aid to deciding what to work on. We know that we need to focus on leak stoppage, not trying to invent leak-proof protocols. There is no point researching something that is impossible. Let's first define our goal before declaring it impossible to reach. Well, I think the goal has been stated: Create an abuse-free email protocol. That goal is impossible. Thus, we have abusable protocols. Perhaps you have a different goal in mind, but it doesn't sound like you accept the premise that it impossible to create an abuse-free protocol. After I first posted this on IETF a while back, someone suggested that covert channels require cooperation, and that spam therefore isn't a covert channel. Where does this covert channel stuff come from anyway? What do you mean? The jump from spam to covert channel isn't immediately obvious. And if any proof of why spam is a covert channel has been offered, I've managed to miss it. The NCSC's definition refers to ANY communication not authorized by the security model. Note that the term Covert Channel is frequently associated with Multilevel Secure Operating Systems. The liturature uses other terms to describe the same concept: information leakage, sneaky signalling, hidden data flows, side channels. So you must not get too caught up in the peculiarities of operating systems. The concept is quite general. It is immediately obvious that covert channels have 3 characteristics: It is a CHANNEL, it is COVERT, and it VIOLATES SECURITY POLICY. (Caps for emphasis of definition, not loudness.) CHANNEL: Spam is a type of Email. Email is a channel transfering signals from A to B. Email is really a subchannel of the internet, which is a subchannel of the PSTN, public and private fiber networks, etc. COVERT: Spam is hidden in so far as possible from the system operators. It is an unintended communication in that the system operators intended that only non-broadcast, solicited commercial communication flow. This not an exclusive list of what is permitted, but illustrates that spam isn't permitted. VIOLATES SECURITY POLICY: System Operators specified an acceptable use policy that outlines what is permitted and what is not permitted. UCE is not permitted. Various methods have been implemented to enforce this policy. the spammer's achilles heel is that they need to send out incredible amounts of email in order to fulfill their objectives, whichever those are. Detecting bulk mail is doable, and it shouldn't be too hard to come up with something to differentiate legitimate bulk emailing from spam. For instance, we can reverse the burden of proof here and only allow know bulk emailers. Detecting abuse is quite different from making a protocol that can't be abused. If you can detect abuse on input rather than on output, detecting
Re: Proposal to define a simple architecture to differentiate legitimate bulk email from Spam (UBE)
Very nice. I say to post an Internet Draft - you post a link to a simple archived e-mail. The IETF process starts with an Internet Draft - without it we are all just wasting time. An internet draft is a concrete proposal that can be discussed, archived, debated successfully, etc. I challenge you to take your e-mail posting and turn it into an Internet Draft with a legitimate security section (since you are solving a security problem) then post a single message to this list showing the internet draft, and a mailing list that people can join if they are interested in discussing it further. From there it is easy to determine if there is enough interest in forming a BOF in Minnesota ( or S. Korea in March ) to forward the work in a Working Group. The problem you have run into is you haven't taken the first step, which is to simply submit an Internet Draft to the Internet Drafts editor... very simple process with no politics in the way. From there you can pursue forming a Working Group (where you will get your first taste of politics). Being that you haven't taken the first step (publishing an Internet Draft) I am not sure you really meet the charter (Ok, yes you do, but putting out a draft is SO important - it should be the first step) and you have allowed the topic to grow WAY beyond initial discussions (I am actually waiting for Harold to post one of his famous Top n Talker lists soon). The next step is to get a mailing list somewhere and move the discussion off of this list onto that list Bill On Wed, Sep 10, 2003 at 05:10:06AM +0800, Shelby Moore wrote: Why is this even difficult. I have yet to see a firm proposal (ie. an Internet Draft),... My challenge - Go forth - publish your protocol in ID form... 1. I remind you to read my initial post that started this thread: http://www1.ietf.org/mail-archive/ietf/Current/msg22035.html Request for opinions on whether to creating a working group or publish the following idea as an internet draft? I think that qualifes under initial discussion of the charter of this list (see #2 below). 2. And to read the charter for this mailing list: http://www.ietf.org/maillist.html This list is meant for initial discussion only. Discussions that fall within the area of any working group or well established list should be moved to such more specific forum... 3. Just a fews posts back in this thread, it was suggested that IRTF would be a better forum for anti-spam proposals and discussions, and I agreed (to consider it if possible and applicable). However there is a another line of discussion in this thread pertaining to general information theory and modeling of channels which is still winding down (initial discussion) and seems quite general to internet engineering. 4. The basic difficulty has been those violating the charter of the list: http://www.ietf.org/maillist.html Unprofessional commentary, regardless of the general subject. such as the Kook thread offshoot that someone started. Shelby Moore http://AntiViotic.com
Re: A modest proposal - allow the ID repository to hold xml
I'll give you one good reason. And that is updating the drafts once the initial RFC is published. If the origional XML/.doc/input language of the day is available, then I don't have to spend my time converting the text into a usable form to get the formating done easily. For this reason only, having origional input would be useful. (Yes I know, I can always go ask the origional editor for the input source, but that may take time locating that person and getting access to the input doc) Bill On Tue, Sep 02, 2003 at 11:19:29AM -0700, Paul Hoffman / IMC wrote: At 10:47 AM -0700 9/2/03, Eliot Lear wrote: I don't know about about you, Paul, but I'm writing my drafts using EMACS and Marshall's tool. That allows for generation of HTML, NROFF, and text. The HTML allows for hyperlinks, which is REALLY nice. Great! Why does that mean that the XML input should be published in the Internet Drafts directory along with the text output? --Paul Hoffman, Director --Internet Mail Consortium
Re: Securing SNMPv3 via SSH tunnels
The problem that you have with TCP (and made worse by SSH tunneling on top of it) is that the number of round trips needed to successfully get a data packet through is unreasonably high in a situation where you are attempting to diagnose a network fault. The other choice is to leave a LOT of state open (ie. TCP connections) requiring a lot of extra memory, etc. on the device. That said there is no reason why you can not create a tunnel to a secure environment and run your SNMP traffic from there. Bill On Wed, Aug 06, 2003 at 08:42:49AM -0700, Fleischman, Eric wrote: I am seeking to secure SNMPv3 communications (e.g., RFC 3414), trying to protect against its well-known vulnerabilities such as spoofing. Had SNMPv3 run over TCP, instead of UDP as it does, then I perhaps may attempt to protect it via SSH port forwarding (i.e., SSH tunneling). Coincidentally, I've just read a description in Bob Toxen's book Real World Linux Security (page 141) about an approach he has apparently used of wrapping UDP in TCP and SSH in order to accomplish SSH port forwarding for UDP-based protocols as well. This makes me wonder whether SNMPv3 may be a viable candidate for SSH tunneling after all. I am wondering whether anybody in the list has any insights as to the viability and weaknesses of this suggested approach. I am especially interested in learning how people on this list secure SNMPv3. Thank you.
Re: re the plenary discussion on partial checksums
Ok, I have to ask a silly question (not like that would be a first on this list) Why, oh WHY would I want to receive a known corrupted packet ? Are we talking about someone thinks they can eeke out 1% more performance because their phy/mac can cut over immediately rather than wait for the packet and verify the checksum ??? (or compute it on the sending side) I guess I don't see the benefit, I guess rather than a hardware L2 check, you rely on something in your hardware later up to fail a check (including a L7 protocol) and drop the frame there ??? I wish I had been there to see the discussion Bill On Wed, Jul 16, 2003 at 04:21:47PM -0400, John Stracke wrote: Keith Moore wrote: so it seems like what we need is a bit in the IP header to indicate that L2 integrity checks are optional, and to specify for various kinds of IP-over-FOO how to implement that bit in FOO. How would an app know to set this bit? The problem is that different L2s will have different likelihoods of corruption; you may decide that it's safe to set the bit on Ethernet, but not on 802.11*. And, in general, the app doesn't know all of the L2s that may be involved when it sends a packet. -- /==\ |John Stracke |[EMAIL PROTECTED] | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own.| |==| |Linux: the Unix defragmentation tool. | \==/
Re: Financial state of the IETF - to be presented Wednesday
I tend to disagree with you Ross, First it is not excessive by definition because we are not covering our costs. Second I don't think it is excessive because I know of MANY weeklong conferences that want in the order of 1000-1700 registration fees... I can see how this is VERY different between someone whos company pays (who cares it isn't my money) and someone on a grant, sending themselves (every penny counts, cause money I don't spend going to an IETF meeting goes into my pocket that lets me spend it on my little girl... or pick your favorite way of spending money) The other thing that will be interesting is how do the IETF meeting expenses scale with participation... Do we spend 300,000K regardless of how many show up, or as the number of attendies goes up we spend more money and if so how much more Bill On Mon, Mar 17, 2003 at 11:17:31AM -0800, Ross Finlayson wrote: At 10:22 AM 3/17/03, you wrote: I'm having quite a hard time seeing what the problem is here, but maybe I'm missing something... Based on Harald's analysis the projected annual shortfall is in the region of $350,000 per annum. Assuming ~5,000 attendees per annum, that equates to ~$70 per year per attendee. The trouble with this analysis is that the 5000 attendees each year are not all different people. Many, if not most, people attend more than one IETF meeting per year. A more accurate analysis would be: A shortfall of $350,000 per annum means ~$120,000 per IETF meeting. So, if 1200 people attend each IETF meeting, then that means $120 extra per person. (Or, if 2400 people attend each IETF meeting, then that means $60 extra per person.) (Personally, I think that even the current $425 fee feels excessive, especially in the current economic climate.) Ross.
RE: Dan Bernstein's issues about namedroppers list operation
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of D. J. Bernstein Sent: Wednesday, January 15, 2003 4:59 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Dan Bernstein's issues about namedroppers list operation Thomas Narten writes: One can debate whether including the specific information cited above was the right thing to do That's the paragraph Bush added to other people's messages. Bush added a different paragraph to my messages. (The ones he didn't throw away, that is.) In that paragraph, he specifically included my private subscription address, which hadn't appeared anywhere in the messages I actually sent. Unintentional, eh? ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago
RE: DNSEXT WGLC Summary: AXFR clarify
Please god NO... I hope EVERYONE deeply involved in a WG documentation process has deep DEEP conflict of interest problems. I mean if we are not working on the things we are documenting, how will we know if they work or not. Saying that WG chairs can not work for companies that need the efforts of the WG seems like setting up a big failure, there are checks and balances, you don't like what the chairs of a WG are doing, talk to the ADs, don't like what the ADs say go to the IAB... This is a documented process. I do not know about the DNS WG, but most working groups that I am aware of also have two co-chairs, usually from different companies/areas - and I know that my co-chair and I have to be in agreement on char descisions, reducing the effect of one of us having a massive conflict of interest. Please do not require conflict of interest rules to enter the IETF, this isn't the government, we NEED this to work Bill Strahm -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of [EMAIL PROTECTED] Sent: Wednesday, December 18, 2002 1:34 PM To: Stephane Bortzmeyer Cc: D. J. Bernstein; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: DNSEXT WGLC Summary: AXFR clarify On Tue, 17 Dec 2002 10:53:28 +0100, Stephane Bortzmeyer said: On Tue, Dec 17, 2002 at 08:58:22AM -, D. J. Bernstein [EMAIL PROTECTED] wrote a message of 26 lines which said: DNSEXT chair Olafur Gudmundsson, who has been paid for BIND work, writes: For me, this is too much. Now, on the *one* hand, I'd be surprised indeed if the chair of DNSEXT had NOT been paid by somebody to do BIND consulting somewhere along the line. On the other hand, if Olafur is in fact making a living doing BIND9 development and coding for ISC or one of their clients, that might be called a conflict of interest when the issue at hand is that a specific document is too BIND9 specific. Personally, I'm OK with Olafur making money doing BIND. I'm even OK on him possibly making more if the draft becomes an RFC in its current state. I admit I've looked through RFC2026 and found nothing about disclosure of conflict of interest(*). I hate making more work for the AD and IESG, but I think at least a We've talked to Olafur and do/dont think there's a problem is called for. (*) I'll let wiser people than I decide if there should be such a section in a son-of-2026 -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech
RE: Reminder: Deadline for input on sub-ip discussion
I have an interesting set of questions for you Harold, 1) How effective would the IESG be with 2 more members, more effective, or less 2) What would happen to any new IESG members in the SUB-IP area, if the area is shut down ? In otherwords, does the IESG think that a two new members would help overall effectiveness, or make it lower If the consensus of the IESG is that adding more members would make them less effective go with the victim/temporary route. If the consensus of the IESG is that adding two members would make the IESG more effective, lets look at making it permanent, or have a place to put the extra members when the temporary area shuts down. In other words what makes that IESG more effective Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Harald Tveit Alvestrand Sent: Monday, December 09, 2002 1:22 PM To: [EMAIL PROTECTED] Subject: Reminder: Deadline for input on sub-ip discussion All, On Wed Dec 4th, we asked for input to help us decide on the future of the SUB-IP Area. See our posting at http://www.ietf.org/mail-archive/ietf/Current/msg18370.html We had a large majority of people at the SUBIP Area meeting in Atlanta expressing that they want the area to be long(er) lived. This will be part of our input. But we need/want to hear from the IETF community. So please express your opionion (and the reasoning behind it) asap on [EMAIL PROTECTED], but certainly before Thursday Dec 12th 10am US Eastern time. As expressed in the above posting (with data points and discussion included), the 3 choices for the SUB-IP Area seem to be: 1/ move WGs (back) to permanent areas: migrate the SUB-IP working groups to other IETF areas sometime soon, likely before next summer and close the SUB-IP area. Also, reconstitute the SUB-IP (and/or other) directorates to ensure the continued coordination between the remaining WGs. 2/ establish a long-term area: decide that the SUB-IP area will be a long-term one, clearly define its charter, and ask the nomcom to select one or two people to be Area Directors 3/ status quo: continue the SUB-IP Area as a temporary, ad-hoc effort, much as it has been, with the IESG selecting two sitting ADs to continue the effort that Bert Scott have been doing. But maybe give more responsibility to the working group's technical advisors, normally the AD from the area where the working group might otherwise live. The opinions expressed so far seem to show clearly that the community is divided on the issue, with perhaps some preference for the status quo (alternative 3). If you have a strong preference for one (or two) of these, and have not yet said so, please indicate your opinion (and your reasons) by mail to [EMAIL PROTECTED] before Thursday. Thank you! Harald Alvestrand, for the IESG (please repost this message where appropriate)
RE: namedroppers mismanagement, continued
I don't know about others, but I use the IETF mailing list service to manage the list. If you want to send a message all it takes is a subscribe, but please don't send me any e-mails... Very easy to do with a Webpage... This only guarantees that I won't see your mail and possibly make a mistake, hopefully I don't make too many mistakes, but I am human Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Tuesday, November 26, 2002 2:33 PM To: [EMAIL PROTECTED] Cc: 'Keith Moore'; [EMAIL PROTECTED] Subject: Re: namedroppers mismanagement, continued No I don't want random people sending stuff to a low volume list ( a couple messages a week is normal ) so I think asking people to subscribe is a low overhead task... I understand where you are coming from, but too many IETF working groups' output has suffered from lack of outside input. Certainly it's reasonable to expect frequent contributors to at least get on an allowed posters list, but it's not reasonable to exclude occasional input from others. Keith
RE: namedroppers, continued
Silly question, But you DO know what it will take to get your message to be immediately seen by the list, you just aren't willing to do it... I believe the problem is in your court, easily solved and it is not time to move on to something that might be slightly productive Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of D. J. Bernstein Sent: Friday, November 29, 2002 3:22 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: namedroppers, continued Keith claims that allowing ``contributions from outsiders'' requires delay and manual review. That claim is absurd. Immediately bounce the message to the ``outsider,'' with instructions explaining how to have the message sent to subscribers; end of problem. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago
RE: namedroppers mismanagement, continued
Ok... I have to know... Randy, Can you please put [EMAIL PROTECTED] on the approved posters list for namedroppers ? Isn't it as simple as that ? Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Keith Moore Sent: Thursday, November 28, 2002 10:18 AM To: Erik Nordmark Cc: [EMAIL PROTECTED] Subject: Re: namedroppers mismanagement, continued If folks need to post all the time from a different address than their subscription address *they* should take the step to get that posting address added to the approved posters list. that might be fine, except - in the current situation, even postings from occasional posters are being blocked. and when postings are blocked, the message is terse and cryptic (even insulting) and contains no clue about how to workaround the problem - getting on the approved posters list is not well documented or understood. for some list software this is a manual operation requiring the list admin to edit a file; on others it is under control of the subscriber but he/she has to subscribe the alternate address using some obscure option like /NOMAIL. I've run several IETF lists myself and I know how much of a pain it is to filter out spam. Yes, the process is error prone. Yes it's a pain to keep approving posts from the same person (though it's easy to fix that problem, and no I don't think adding that person to an approved posters lists is assuming too much). And yet I still don't think that namedroppers is being managed appropriately. Can we please fix this problem which has gone on for several years and stop pretending that this behavior is acceptable? Keith
RE: namedroppers mismanagement, continued
Keith, I almost agree with you... Except here is the problem... The [EMAIL PROTECTED] mailing list has 17 request(s) waiting for your consideration at: https://www1.ietf.org/mailman/admindb/ipoverib I'll go ahead and remove the 17 messages trying to sell sex, toner cartridges, stuff in char sets I don't even know what they are... No I don't want random people sending stuff to a low volume list ( a couple messages a week is normal ) so I think asking people to subscribe is a low overhead task... You don't even have to receive the mail traffic. It is also not in the communities interest to slog through 100's of spams to find a usefull nugget of truth either. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Keith Moore Sent: Tuesday, November 26, 2002 6:41 AM To: Eliot Lear Cc: D. J. Bernstein; [EMAIL PROTECTED] Subject: Re: namedroppers mismanagement, continued Join the list already. How hard is that for a so-called mail guru? there are valid reasons to post to a list when you're not subscribed, or from a different address from the one you use for your subscription. and it's not in the community's interest to ignore useful input.
RE: Palladium (TCP/MS)
Well the first thing you have to realize is that there is no such thing as TCP/MS, and there for any answer you get would be highly speculative at best. This is a huge red herring, based on speculation that for some unknown reason, Microsoft will Embrace/Extend/Extinguish the IP protocol and successfully be able to put their own protocol (MS) onto the internet in such a way that you will be required to use a MS product to use the internet... I don't know about you but I find the whole scenario dubious at best, and this whole thread is becoming a massive troll Bill (Who is getting ready to take his lunch and eat it rather than feeding trolls) -Original Message- From: [EMAIL PROTECTED] [mailto:owner-ietf;IETF.ORG] On Behalf Of Sean Jones Sent: Wednesday, October 23, 2002 1:38 AM To: [EMAIL PROTECTED] Subject: RE: Palladium (TCP/MS) Good Morning Valdis Thank you for your prompt reply. Perhaps I did not phrase my question properly. I know what PTR records are, I know how TCP/IP works etc (I've done a routed IP network or two, and worked at an ISP for a while) so please let me re-phrase my question. Why is a PTR (or DNS) record with MS TCP different from the standard TCP/IP record? (Perhaps it is me in my ignorance, or lack of understanding :o) ) Regards Sean -Original Message- From: [EMAIL PROTECTED] [mailto:Valdis.Kletnieks;vt.edu] Sent: 22 October 2002 18:39 To: Sean Jones Cc: [EMAIL PROTECTED] Subject: Re: Palladium (TCP/MS) On Tue, 22 Oct 2002 16:42:03 BST, Sean Jones said: Forgive my ignorance, but what the heck do you mean? % dig -x 207.46.230.218 ;; ANSWER SECTION: 218.230.46.207.in-addr.arpa. 2665 INPTR microsoft.com. 218.230.46.207.in-addr.arpa. 2665 INPTR microsoft.net. 218.230.46.207.in-addr.arpa. 2665 INPTR www.domestic.microsoft.com. 218.230.46.207.in-addr.arpa. 2665 INPTR www.us.microsoft.com. Of course, it isn't that simple - those 4 PTR entries each point back at a multihomed host. I was about ready to throw a yellow flag and a 5-yard procedural penalty until I double-checked RFC2181, section 10.2 - that's legal. Gonna need a lot longer ACL on that Cisco to actually make it work (don't forget all their msft.net servers. Bringing it back to IETF territory now: Is there a need for an RFC for best practices in securing the download of software updates (DNSSEC, PGP signatures, etc)? The two scariest things about online updates (at least while wearing my security hat) are the MITM attack (as demonstrated against Apple) and the hacked download attack (as has hit windowsupdate, openssh, sendmail, and others). If it's WG fodder, I'd specifically declare the question of whether the patch *works* as off-topic - the task is merely verifying that the bits are the correct bits, and from the correct vendor. -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech
RE: TCP/IP Terms
Cynicism I always figured it was based on the number of managers that you have on the project, one manager for each layer... At least that is how it was done at a previous company I worked for... /Cynicism Models are very nice to help you get people to think about something the same way. Of course the best engineers that I know, understand the model, but think way outside it... Letting unique solutions that break the model, but deliver better results... Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Dave Crocker Sent: Tuesday, October 08, 2002 12:25 PM To: Robert Elz Cc: [EMAIL PROTECTED] Subject: Re: TCP/IP Terms At 11:38 PM 10/7/2002 +0700, Robert Elz wrote: Attempting to give these things absolute numbers, other than for ease of reference in some particular context is lunacy. Not that I disagree with your primary point, it is worth noting that there is some basis for hovering about 7, for an *overall* model. It's that memory limit thing (7, plus or minus 2.) The plus or minus is statistical, so if you want to make sure that people really have no trouble grokking the total set, 5 is a better choice. d/ Dave Crocker mailto:[EMAIL PROTECTED] TribalWise, Inc. http://www.tribalwise.com tel +1.408.246.8253; fax +1.408.850.1850
RE: Report on Peering and Transit Economics (etc)
All I have to say is WOW A three page executive summary. I am afraid to read the rest... Guess I will have to see what is going on especially when they start talking about ICANN (At the VERY bottom) I'd love to know how that fits into Peering and Transit economics Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Gordon Cook Sent: Sunday, September 29, 2002 9:46 AM To: [EMAIL PROTECTED] Subject: Report on Peering and Transit Economics (etc) I have published an extremely detailed report on the economics, technology, and politics of peering and transit. At http://cookreport.com/11.08-09.shtml you will find the complete introductory article, contents and list of 25 contributors to the effort. The report centers on interviews with Bill Woodcock, an essay / critique by Farooq Hussain and an edited version of the 6 weeks of discussion by the 25 contributors. I include here the executive summary from the report. This summary is not on my web site and I am not posting it elsewhere. Executive Summary Whither the Policy, Technology, and Economics of the Interconnection of the Internet? The collapse of the industry and of the price of bandwidth is bringing significant changes into the ways in which ISPs and the remnants of the Old Guard of Tier 1 backbones interconnect. Some people who are affected have made some significant steps in using NetFlow data in developing tools that are being refined into what can function as bandwidth cost management systems. We identify several explorations being taken in this direction and explore what looks to be the most refined developed by Bill Woodcock with the assistance of Alex Tudor at Agilent Labs. Bill has developed a philosophy of interconnection that appears to have a sound business model behind it. Bill's approach was developed from the point of view of a small ISP that needs to understand with as much precision as possible what it does cost to get its bandwidth delivered. His model says that ISPs that are multi-homed and have their own leased line customers need to peer as much and as cheaply as possible. They also need to have two reliable transit providers in case one fails. As long as their peering can cut over to transit if it fails, he points out that economics would seem to demand delivery of as much bandwidth by cheap peering as possible to cut down on the requirement for expensive transit bandwidth. ISPs need to avoid local loop charges from their LECs and acquire their own back haul to an exchange for inexpensive peering and if possible a different exchange or exchanges for more reliable transit. In order to figure how to most cost effectively architect their networks they need to take and manipulate NetFlow samples of their traffic in order to identify potential new peers via a study of the traffic being delivered by their transit providers. If they have automated tools to take samples from appropriate points, they can over time get clear pictures of how their traffic is evolving through actual NetFlow path analysis. But Woodcock's colleagues seem to agree that he has done something unique. He explains it in writing for the first time in this issue of the COOK Report. Namely he does what he calls synthetic path analysis by tacking his actual path data and doing a series of what if transformations on that data. With the help of Alex Tudor from Agilent labs he explains using actual data from January 31 2002 how this synthetic analysis can be applied so that for the first time an ISP, by plugging circuit cost data into its modeling software, can know how much it really does cost to deliver its bits. These ideas are new. While our experts agreed that perhaps 100 ISPs may be doing some form of actual NetFlow data analysis, virtually no one except Woodcock had done the synthetic path analysis. Avi Freedman in his position as Chief Network Scientist at Akamai has had ample occasion to use network routing and DNS to figure out data flows. After studying Bill Woodcock's explanation found that he had evidence from his own related experience that indicated Bill's approach seemed valid. He points out that since 1999 he has been doing a what if analysis on Akamai flows similar to Woodcock's synthetic path analysis on router flows. Our 50,000 word eight week long discussion involving 25 different people contains a quite interesting dialog between the Avi and Bill as they compare their approaches to the problem and conclude that the ideas appear to be valid. However, we must also point out that Bill's synthetic path analysis is not meant to be the sole criterion on which to base peering and transit decisions. Once they have identified potentially good peers, ISPs will find that factors of geography and costs of interconnection at various exchanges may become decisive factors in making their final decisions. Although the largest carriers
RE: ECN and ISOC: request for help...
I don't see why this is embarrasing. I have no problems with people setting up filtering rules that say DENY-ALL accept packets that I EXPLICITLY know what every bit does, and I want to allow it... That said, ECN is a relatively recent addition to the suite and I wouldn't expect all firewalling rules to be setup to use it (I believe that some of the bits involved have been used by other experimental protocols for other things). For this reason I don't think this behavior is as bad or embarrassing as you think it is. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Franck Martin Sent: Tuesday, July 23, 2002 10:17 PM To: 'Gary E. Miller'; Christian Huitema Cc: ietf Subject: RE: ECN and ISOC: request for help... I'm not in a campaign to promote ECN, or anything... I'm saying that ISOC web site is not reachable if you enable ECN, which RFC793(standard) or RFC3168(proposed Standard) talk about. I don't want to talk about what is a standard or what is not... What is compliant or not... Will there be anybody to volunteer and fix the routers leading to ISOC web site, mailing lists, e-mail addresses and so on? This is what my message is all about. Please IETF members in Washington DC, Area, please give a call to ISOC and offer some help... This is embarrassing, that's all Cheers. Franck Martin Network and Database Development Officer SOPAC South Pacific Applied Geoscience Commission Fiji E-mail: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Web site: http://www.sopac.org/ http://www.sopac.org/ Support FMaps: http://fmaps.sourceforge.net/ http://fmaps.sourceforge.net/ Certificate: https://www.sopac.org/ssl/ This e-mail is intended for its addresses only. Do not forward this e-mail without approval. The views expressed in this e-mail may not be necessarily the views of SOPAC. -Original Message- From: Gary E. Miller [mailto:[EMAIL PROTECTED]] Sent: Wednesday, 24 July 2002 3:02 To: Christian Huitema Cc: ietf Subject: RE: ECN and ISOC: request for help... Yo Christian! Actually, RFC 3168 has nothing to do with it. The issue is RFC 793. RFC 793 is a Standard, not a Proposed Standard RFC 793 lists the bits later used by ECN as Reserved. Computer programs are supposed to ignore Reserved bits unless they really know what they are doing. If a router treats bits in the header as required by the STANDARD RFC 793 then RFC 3168 will cause no harm.I do not have a copy of Baker handy, but I bet it agrees. RGDS GARY --- Gary E. Miller Rellim 20340 Empire Blvd, Suite E-3, Bend, OR 97701 [EMAIL PROTECTED] Tel:+1(541)382-8588 Fax: +1(541)382-8676 On Tue, 23 Jul 2002, Christian Huitema wrote: So, if you are on a campaign to promote ECN, then maybe you should first try to promote this specification to the next standard level... You may also want to take a stab at revising the Requirements for IP Version 4 Routers; the last edition, RFC 1812 by Fred Baker, dates from June 1995.
RE: postings to ietf mailing lists
Can't say about other maillist software, but the software that runs the @ietf.org lists allows this, you can subscribe from as many addresses as you want, and only get mail sent to a single address... This works well for people that can't control what their company does as far as @foo.company.com where foo seems to change quite a bit... Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of [EMAIL PROTECTED] Sent: Wednesday, June 12, 2002 5:31 AM To: [EMAIL PROTECTED] Subject: postings to ietf mailing lists i have noticed that some ietf working groups don't anymore allow postings except from addresses that have subscribed to the list. this not good unless there is a way to register another email address from which postings are allowed. the reason is that many people don't want to get any mailing list traffic to their personal mail boxes and therefore have subscribed an alias rather than their own personal email address. could it be made a policy of ietf mailing lists to include support for a posting address that is not the same as subscription address? some mailing lists already do this, but not all. -- juha
Re: IPR at IETF 54
On Thu, 30 May 2002, RJ Atkinson wrote: On Thursday, May 30, 2002, at 09:48 , Melinda Shore wrote: Here's one for starters: there's no guidance on how or whether to treat differences in licensing terms for competing proposals. It would be nice to be able to say that all other things being more-or- less equal we should prefer technology which will be available royalty-free, Agree. My druthers would be to have an IETF policy explicitly saying that the first choice is to use unencumbered technology if it can be made to work, second choice is encumbered but royalty-free technology, and last choice is fair and reasonable licence terms (or whatever the equivalent correct legal wording might be for that last). And it would be good to have a conventional template for the royalty-free licence -- one that the IETF's legal counsel has reviewed and believes is acceptable for IETF purposes. I disagree with this, I don't think the IETF can afford to keep a staff of lawyers working on determining the licencing statements of all of the standards being churned out. That said, I don't think it would do any good anyway, lets say the IETF lawyer gives his Okey Dokie, then my company implements the standard and a problem with the licencing terms comes up... Who do I go sue, the IETF ??? I hope not, but that could be creating a legal liability for the IETF if its lawyers make statements on the licencing terms of protocols... Bill
