Re: Of governments and representation (was: Montevideo Statement)
From: Brian E Carpenter brian.e.carpen...@gmail.com Reality is different - the outside world expects to hear from us. I would guess that nobody (almost nobody?)in the IETF objects to I* leadership representing our views at such things; in fact, I suspect most of us would find it positively very desirable for the I* to be represented there. (I certainly do.) The thing is that I (and I suspect much of the IETF) feel that such I* leadership attendees need to make it _very_ clear at such events that they are there to present (as best they can) the views of the IETF as a whole, but they cannot _commit_ the IETF to anything: only the IETF acting as a whole can do that. So, for instance, in signing a statement, they need to say John Smith, current Ixx chair, signing as an individual, or something like that - to make it clear to readers that their signature does not bind the organization as a whole. Noel
Re: leader statements
From: Randy Bush ra...@psg.com we are in a big problem, and this is one major part. two decades of lack of coherent architectural oversight is another symptom of this. I have two issues with your observation. First, while I agree we've been deficient in architecture, from personal experience I can tell you that the I* community is remarkably resistant to architectural guidance (which necessarily involves a rather long time-frame, the kind of time-frame to which many engineers are inherently resistant, focused as they are on the practical, here-and-now). I don't know much about the other levels of the stack, but I can assure you that at the internetworking level, the community has been remarkably resistant to architectural guidance over the last 20 years - and I have the arrows in my back to prove it (the lack of separation of location and identity in IPv6 being only one of the largest). Would attempting to push the I* down a particular path, different to the one that the one it wants to take, have any different result than Kobe? I am not sure. Second, it's not at all clear to me that the people who are best suited to provide architectural guidance are the same people who are best suited to be facilitating leaders. They are very different skills, and to find both in one person, at the kind of high level needed in the I* now that it is responsible for a major part of the world's communication infrastructure, would seem to me to be rather unlikely. Noel
Re: leader statements (was: Montevideo statement)
From: Phillip Hallam-Baker hal...@gmail.com I have argued for junking the DARPA constitution for years. It was designed to keep power in the hands of the few while the rest of the organization didn't worry their pretty heads about it. Factually incorrect in a number of ways. The NomComm system was set up to keep personal politics out of the selection process (or at least keep it to a minimum). And it wasn't the 'DARPA' system - it resulted from discussion among a number of people in the IETF. We should junk the noncon completely and the constituency currently qualified to stand for noncon should elect the chair. The last thing the IETF needs is elections. Noel
Re: leader statements
From: Arturo Servin arturo.ser...@gmail.com Then we have a big problem as organization, we are then leaderless. I'm not sure this is true. The IETF worked quite well (and produced a lot of good stuff) back in, e.g. the Phill Gross era, when I am pretty sure Phill's model of his job was indeed as a 'facilitator', not a 'leader' in the sense you seem to be thinking of. So why do we now need a 'leader'? Noel
Re: leader statements
From: Melinda Shore melinda.sh...@gmail.com The IETF worked quite well (and produced a lot of good stuff) back in, e.g. the Phill Gross era, when I am pretty sure Phill's model of his job was indeed as a 'facilitator', not a 'leader' in the sense you seem to be thinking of. Because we've got more than 120 working groups, thousands of participants ... I don't like hierarchy but I don't know how to scale up the organization without it. I don't believe this necessarily invalidates my point. Yes, a larger organization will need to make organizational changes (scaling factors apply not just in protocols), but it is not at all clear that this includes changing the role of the leaders from 'facilitators' to 'they chose the direction, the rest of us follow' (which is what the original post seemed to imply was needed). Noel
Re: Montevideo statement
From: Andrew Sullivan a...@anvilwalrusden.com I merely request that we, all of us, attend to the difference between the IAB Chair says and the IAB says. We may attend to it, but we are unable to make sure that the rest of the world pays attention to that nuance. From: SM s...@resistor.net In my humble opinion it would be good if there was a comment period. Yes; if there is no time-pressure, why not take a week or so and find out what the community thinks? Then it is not just one person (remember, we have no kings...) Noel
Re: [Fwd: I-D Action: draft-carpenter-prismatic-reflections-00.txt]
From: Dave Crocker d...@dcrocker.net Except that essentially all services other than email have gained popularity in centralized form, including IM. So there appear to be some important and difficult operational and usability barriers, standing in the way of more truly distributed applications. Yes. $$$. Nobody makes much/any money off email because it is so de-centralized. People who build wonderful new applications build them in a centralized way so that they can control them. And they want to control them so that they can monetize them. Noel
Re: Transparency in Specifications and PRISM-class attacks
From: Steve Crocker st...@shinkuro.com Are we conflating back doors in implementations with back doors in protocol specifications? Good point, but I was thinking specifically of protocol specs, since that's what the IETF turns out. It's certainly a conceptual possibility for there to be a back door in a protocol specification, but I don't recall ever hearing about one. Well, here's one I was just reading about this morning: Last week, the New York Times reported that Snowden's cache of documents from his time working for an NSA contractor showed that the [NSA] used its public participation in the process for setting voluntary cryptography standards, run by the government's National Institute of Standards and Technology, to push for a formula that it knew it could break. NIST, which accepted the NSA proposal in 2006 as one of four systems acceptable for government use http://www.reuters.com/article/2013/09/20/us-usa-security-snowden-rsa-idUSBRE98J02Z20130920 (The irony here is that NSA, which is supposed to ensure the security of government communications, deliberately pushed a weakened system as one of four systems acceptable for government use - probably because they worked out that what's they'd lose by its use in a few cases non-critical cases [no doubt they wouldn't OK its use in really crucial systems] was outweighed by what they might gain from outside use.) Noel
Re: Transparency in Specifications and PRISM-class attacks
From: Hannes Tschofenig hannes.tschofe...@gmx.net * Prefer performance over privacy in protocol designs You forgot: * Prefer privacy over performance in protocol designs and its cousin: * Prefer privacy over usability in protocol designs both of which, as we have seen extensively over the last couple of decades, can lead to people tossing privacy, and running in non-private mode... And of course both of these (and probably others in your list) can happen through simple human error, not necessarily ill intent. (Never attribute to malice that which, etc.) The Truth Path to good, effective privacy is a narrow one, I fear. Noel
Re: Transparency in Specifications and PRISM-class attacks
From: Martin Sustrik sust...@250bpm.com Isn't it the other way round? That exactly because IETF process is open it's relatively easy for anyone to secretly introduce a backdoor into a protocol? ... With IETF standard there can very well be several unknown backdoors introduced by different parties, so it's never safe. Iff enough people are _carefully_ reviewing specs, that ought to find all the backdoors. An open process does have potential issues, but it's also the one with the best chance of producing a 'good' product. That being said, wouldn't it make more sense to admit that IETF is not a good platform for devising, say, crypto protocols and act accordingly (use 3rd party protocols ...)? You mean, trust another entity, which might have been suborned? How are they less likely to have produced something without backdoors than the IETF? Noel
Re: ORCID - unique identifiers for contributors
From: Hector Santos hsan...@isdg.net I would even suggest that all I-D authors, at the very least, should need to register with the IETF to submit documents. Oddly enough, back in the Dark Ages (i.e. the ARPANET), the DDN maintained such a registry, and so if you Google 'NC3 ARPANET' you will see that that was the ID assigned to me back then. We could easily do something similar. Noel
Re: decentralization of Internet (was Re: Bruce Schneier's Proposal to dedicate November meeting to saving the Internet from the NSA
From: =?ISO-8859-1?Q?Roger_J=F8rgensen?= rog...@gmail.com Isn't the payload the important part to protect? Ecrypting only the headers was a suggestion for the case where the routers don't have enough spare crunch to encrypt the entire payload of every packet. Whether that would do anything useful, or whether analysis of the payload could bypass that, making that limited step useless, I don't know. Noel
Re: Equably when it comes to privacy
Probably best if we keep the politics off the IETF list. Noel
Re: decentralization of Internet (was Re: Bruce Schneier's Proposal to dedicate November meeting to saving the Internet from the NSA
From: =?ISO-8859-1?Q?Roger_J=F8rgensen?= rog...@gmail.com The userbase and deployment are relative small atm so it's doable to get fast deployment to. Alas, now that I think about the practicalities I don't think the average router has enough spare computing power to completely encrypt all the traffic. Whether or not encrypting just the source+dest addresses, and the sort+dest port (conviently next to each other in one block) is enough to do much good, and if the average router has enough spare crunch to do even that, is a good question. Noel
Re: Bruce Schneier's Proposal to dedicate November meeting to saving the Internet from the NSA
From: Martin Millnert mar...@millnert.se Bruce was ... suggesting that encrypting everything on the wire makes both metadata and payload collection from wires less valuable. Here comes the key point: Encrypting everything on the wire raises the cost for untargeted mass surveillance significantly. And that is what it is all about. I have no problems with encrypting everything, as long as we realize that in doing so, we're only solving one corner of the problem, and the watchers will just move their efforts elsewhere; all intelligent attackers always look for the weak point, no? (Although I have to wonder at the computing load needed to do so. I gather e.g. Google's datacenters use enormous amounts of energy - I wonder if mass encryption of all traffic on the Internet would be literally a 'boiling the ocean' solution... I'm amused by the memory of people who used to react with shock and horror to variable length addresses, because of the extra computational load required to handle _them_) And best is of course if this can be end to end That's going to take quite a while to accomplish; it requires updating all the hosts. (I know, we don't have to get to 99.9%, but it's still non-trivial to get to, say, 70%.) Noel
Re: Bruce Schneier's Proposal to dedicate November meeting to saving the Internet from the NSA
From: Scott Brim scott.b...@gmail.com I wouldn't focus on government surveillance per se. The IETF should consider that breaking privacy is much easier than it used to be ... right now the Internet's weakness in privacy is far from better. The mandatory security considerations section should become security and privacy considerations. The privacy RFC should be expanded and worded more strongly than just nice suggestions. Excellent point. There are a lot more threats to privacy than just the NSA (and similar agencies in other large, powerful countries, which probably do their own snooping, although not on the scale of the NSA's). I am minded of the 'recent' revelations that Google, etc trawl through email they handle, looking for URLs, which they then crawl. (I say 'recent' because I discovered this some years ago. A 'private' page of mine - i.e. one with no links to it - wound up in Google's search results, because I'd sent someone on gmail a message with the URL in it...) Etc, etc. Added up across all the large companies, I reckon the amount of 'private' surveillance is probably close to what the NSA does. From: Theodore Ts'o ty...@mit.edu For too long, I think, we've let the perfect be the enemy of the good. At least this way they will be forced to go the NSL route ... or spend $$$ on huge racks of servers in public data centers, which maybe means less money to subvert standards setting activities. ... Although perfect security is ideal, increasing the cost of casual style dragnet surveillance is still a Good Thing. Good point. But let's not make a similar diversion ourselves. I suspect that for most people, the results of having their machine infected with a virus, or identity theft from compromised information, is probably a lot more painful than being the subject of dragnet surveillance by a government (irritating though that may be). So if we throw resources at attacking the dragnet surveillance, and take those resources from efforts to tackle other security problems, that might not be in the best overall interests of the networks' users. Noel PS: I'm having fun trying to imagine the reaction of the people at the NSA, GCHQ, etc who are reading this thread. (Hi, all!)
Re: Bruce Schneier's Proposal to dedicate November meeting to saving the Internet from the NSA
From: Spencer Dawkins spencerdawkins.i...@gmail.com I have to wonder whether weakening crypto systems to allow pervasive passive monitoring by national agencies would weaken them enough for technologically savvy corporations to monitor their competitors, for instance. More importantly, if crypto systems are weaked so that the intelligence agencies of the 'good guys' can monitor them, they're probably weak enough that the intelligence agencies of the 'bad guys' can monitor them too. The smarts level on the other side should not be under-estimated, although I fear this often happens. From: Ted Lemon ted.le...@nominum.com What we should probably be thinking about here is: - Mitigating single points of failure (IOW, we _cannot_ rely on just the root key) - Hybrid solutions (more trust sources means more work to compromise) ... - Multiple trust anchors (for stuff that really matters, we can't rely on the root or on a third party CA) I'm not sure if this is entirely responsive to your points here, but it is possible to have multiple 'root trust anchors' with the DNS. I have worked this out in some detail, which I won't give here. But basically the concept is that multiple entities (e.g. IEEE, EFF, add-your-favourite here) can all sign the root zone (independently, but in parallel), and also any subsidiary zones they care about (e.g. .EDU). (Signing everything all the way down is clearly impractical, but if you can n-way secure the root of the tree, that will help.) I seem to recall that DNSSEC as it stands could deal with this; the real issue would be gaining agreement from the zone owner to include multiple signatures. Of course, it's possible to distributed those signatures in other ways, but that would require new mechanism. Noel
Re: decentralization of Internet (was Re: Bruce Schneier's Proposal to dedicate November meeting to saving the Internet from the NSA
From: Scott Brim scott.b...@gmail.com LISP does nothing for decentralization. Traffic still flows hierarchically Umm, no. In fact, one of LISP's architectural scaling issues is that it's non-hierarchical, so xTRs have neighbour fanouts that are much larger than typical packet switches. In basic unicast mode, any xTR is always a direct neighbour to any other xTR; no xTR (in basic unicast mode, at least) ever goes _through_ another xTR to get to a third xTR. All LISP basic unicast paths always include exactly two xTRs. The actual detailed paths do mimic the underlying network, of course: if the network is hierarchical, the paths will be hierarchical, but if the network were flat, the paths would be flat. (Or is that what you meant?) you add the mapping system which is naturally hierarchical and another vulnerability. No more so than DNS; they are exactly parallel in their functional design. Noel
Re: decentralization of Internet (was Re: Bruce Schneier's Proposal to dedicate November meeting to saving the Internet from the NSA
From: Scott Brim scott.b...@gmail.com The encapsulation is not much of an obstacle to packet examination. There was actually a proposal a couple of weeks back in the WG to encrypt all traffic on the inter-xTR stage. The win in doing it in the xTRs, of course, is that you don't have to go change all the hosts, application by application: _all_ traffic, of any kind, from that site to any/all other sites which are encryption-enabled, will get a certain degree of confidentiality. Does this count as something the IETF can do reasonably quickly that will help somewhat? :-) Noel
Re: Bruce Schneier's Proposal to dedicate November meeting to saving the Internet from the NSA
From: Dean Willis dean.wil...@softarmor.com The [IETF] .. needs dedicate its next meeting to this task. This is an emergency, and demands an emergency response. The thing is that I'm not sure how much of this is the NSA 'breaking' protocols/algorithms, and how much is finding ways past/around that security. E.g. some of it (from accounts in the news) is definitely back doors, inserted into hardware or software, and clearly we can't fix those. Most importantly, in one news story I read, Snowden was quoted as saying Unfortunately, endpoint security is so terrifically weak that NSA can frequently find ways around it. If this is accurate, we can fix protocols till the cows come home, and people who wish to gain access to the data will just break into the hosts, and grab the data before/after it crosses the network. So it's not at all clear than the IETF can really fix (much of) the problem. Noel
Re: Bruce Schneier's Proposal to dedicate November meeting to saving the Internet from the NSA
From: Phillip Hallam-Baker hal...@gmail.com S/MIME is almost what we need to secure email. If by secure email you mean 'render email impervious to being looked at while on the wire', perhaps. If, however, you mean 'render it secure from ever being looked at by anyone else', no way. Even if it's stored on the destination host in encrypted form, if that host is compromised, the contents of that email are now at risk. Even if the key is not stored on that machine, the next time it's entered into that machine (or, more broadly, the encrypted email and the key are brought near each other), it can be lifted, _if that computer has been compromised_. This whole 'surveillance of online activity' is a lot bigger problem than the IETF's work domain. For us to think we can 'solve' it is massively hubristic. Noel
Re: Berlin was awesome, let's come again
From: Ted Lemon ted.le...@nominum.com I would personally love it if IETF did another Munich meeting, because I haven't been there since I was seven, and I've always wanted to go back Many fine lunches and dinners. Some things never change... Noel
Re: [Trustees] The Trust Agreement
From: Brian E Carpenter brian.e.carpen...@gmail.com Thanks for the careful explanations. I'll second that; it does seem that some tweaking may be in order. Clearly the Trust shouldn't have blanket permission to abandon or dispose of assets When the time comes to draft actual wording, I would suggest that there be a requirement for a notification to the IETF-Announce list at least one month (or so?) prior to any actual disposal or abandonment, or completion of any agreement to dispose. (Maybe only for IP, and not real property too, such as old servers, etc?) I can't imagine the Trust would be disposing of stuff very often, so I think this would be a reasonable requirement. Noel
Re: Bringing back Internet transparency
From: Simon Leinen simon.lei...@switch.ch In the eyes of your ISP, you were misbehaving, because you were violating their assumption that you would use ONE (1) computer with that connection. If you had been what they consider an honest citizen, you would have gotten a commercial connection to connect more than one. I suspect it had a lot more to do with their customer service setup; they were not, after all, hiring computer scientists. They worked off scripts, and the script needed a known quantity connected to the port (I would guess the only handled Windows boxes and Apple machines). With 7 different kinds of Brand-X NAT boxes (some of which had limited maintainence capabilities), their scripts would not have worked. Besides, they had other ways to sort out the commercial from residential customers; for one, they filtered out incoming SMTP connections (although this might have been as much to prevent clueless home users from being spam vectors by running open relays, etc as anything else). I would assume they filtered out incoming HTTP connections too. Don't forget, in some ways a NAT box probably works _against_ an ISP's interests, because they'd probably _like_ to be able to charge for each machine connected up. (Many cable TV suppliers try to charge for multiple TVs, don't forget). But I suspect the difficulty of connecting multiple machines _without_ a NAT box (you've got to have a real router, and configure it, etc), and its attendant increase in customer service costs (not to mention the increased demand for address space), led them to throw up their hands. Anway, this is all just speculation on our part. IMO, further discussion without some real data on how the ISPs saw this is just a waste of time. I guess this is just a long-winded, engineering take on 'the customer is always right'. were our (we being the IETF) customers the ISPs, the users .., the vendors of then-current equipment, the vendors of potential circumvention solutions (NATs)? These groups of customers probably didn't agree on what they wanted. Were all of them right? Excellent point. Have to go away and ponder that one for a while. Noel
Re: Bringing back Internet transparency
From: Phillip Hallam-Baker hal...@gmail.com The ISPs had a clear interest in killing of NAT which threatened the ISP business model. So this is rather amusing: you're trying to tell me that ISPs wanted to kill NAT, and I have other people telling me NAT was an intergral part of ISPs' master plan to take over the universe. Clearly you all both can't be right. Noel
Re: stability of iana.org URLs
From: Barry Leiba barryle...@computer.org They have: they are keyed off the suffix-less URIs. That's why they want us to use those. That doesn't change the point that breaking URLs in _previously-published, static_ documents is a Bad Thing. Noel
Re: Bringing back Internet transparency
From: Roland Bless roland.bl...@kit.edu we probably need to do something on reducing the number of _broken_ middleboxes (or their implementations respectively) - I'm not focusing on NAT boxes here. ... I think it's clear that we will not get rid of them, but if I hear about boxes that try to do clever optimization or security by re-writing TCP sequence numbers ... bundling segments and so on, I'm wondering who actually engineered those boxes; aren't the vendors/engineers participating in the IETF? Who buys and deploys such boxes ... What could be IETF efforts to get a better situation for the deployment of future innovations or do we simply accept that (a few) broken middleboxes dictate the future level of innovation in the Internet? I hear you, but... this is not a simple problem. I think we need to start by understanding what drives the creation and deployment of these devices. I think the answer to that has to be that some people have needs that aren't being met by the IETF, and so there's an opportunity for private entities to create and sell 'solutions'. The IETF doesn't have a police force, or any enforcement mechanism. If we're going to head off these boxes, the only tool we have to do that is to build better mousetraps - i.e. design stuff that does what people want, is more cost-effective, and is better than these local 'point deployment' boxes. Sadly, the IETF has a long history of being hard-headed about 'my way or the highway', and not carefully listening to what the 'customers' are telling us about these various aspects of a successful design. (The most noteable example of this being NAT - which was going to be ugly anyway, but as a result of the IETF refusing to create an architected NAT solution - apparently on the theory that if we stuck our fingers in our ears and went la-la-la-la loud enough, it would Just Go Away - we now have NAT that is both ugly _and_ brittle [because it's not part of an architected _system_], difficult to work with because it [mostly] lacks any external control interface, etc.) So, sorry, I don't have a simple solution to what I concede is a real problem. But it's a complicated problem - no simple solution. Noel
Re: making our meetings more worth the time/expense (was: Re: setting a goal for an inclusive IETF)
From: Keith Moore mo...@network-heretics.com Great message. One idea: WG meeting sessions aren't scheduled to encourage discussion, but to discourage it. At meeting after meeting, in several different areas, I see the lion's share of the time devoted to presentations rather than discussion. Easy fix: 'slide' (well, nobody uses real slides anymore :-) rationing. E.g. if a presenter has a 10 minute slot, maximum of 3 'slides' (approximately; maybe less). That will force the slides to be 'discussion frameworks', rather than 'detailed overview of the design'. Noel
Re: Bringing back Internet transparency
From: Joe Touch to...@isi.edu what people want (ISP operators, or at least some of them), was an artificial way to differentiate home customers from commercial providers. I.e., they wanted to create a differentiation that wasn't part of the Internet architecture, so they put one in. NATs did other things ... but IMO mostly as a by-product of this primary motivation. I'm not so sure about that. For the first couple of years that I had an ISP connection (which soon had an early NAT box on it), whenever I called up the ISP (then, and still, one of the largest in the US) with a service call, the first thing I had to do was unplug the NAT box and plug in a host directly! It was only after everyone's house had multiple PC's (which was really only after wireless became common - I don't think too many people were willing to wire their houses for Ethernet :-) that they kind of expected there to be a NAT box there. But in any event, it's doesn't void my point: if people want something, we have two choices: i) blow people off, and they'll adopt some point solution that interacts poorly with everything else, or ii) give people the _capabilities_ they need/want (and thereby have some chance at minimizing the brain damage - since generally people don't care _how_ it works, as long as it _does_ what they want). I guess this is just a long-winded, engineering take on 'the customer is always right'. Noel
Re: Remote participants, newcomers, and tutorials (was: IETF87 Audio Streaming Info)
From: Abdussalam Baryun abdussalambar...@gmail.com no one in IETF have been participating for longer than 30 years The IETF was a renaming of things that existed before the formal first IETF (in January, 1986). It's a direct descendant of the first 'TCP Working Group' meeting, held in Washington DC on March 12, 1977. And yes, one person who was at that meeting is _still_ participating (he sent a message to the IETF list on 21 May, 2013; and had an RFC published this month - RFC 6975). (And if you consider the Internet work to be connected to the ARPANET - which in some ways it is, because the RFC series shades slowly from NCP documents to TCP documents - he goes back a lot further than that: to RFC 1! Thereby setting a 'first RFC to last RFC' record that's going to be very hard to beat! But I digress...) Noel
Re: IAB Statement on Dotless Domains
From: Livingood, Jason jason_living...@cable.comcast.com FWIW, I think for most larger companies with multi-billion dollar revenues streams it is less about the up-front fees to apply operationalize a gTLD than the long term business potential. I guess I'm missing something. How exactly is having a gTLD going to bring in the Big Bucks? Do people actually type addresses into the address bars on their browsers any more, or do they just type what they're looking for into the search bar? Noel
Re: IAB Statement on Dotless Domains
From: Phillip Hallam-Baker hal...@gmail.com for many years it was IETF ideology that NATs were a terrible thing that had to be killed. A position I suspect was largely driven by some aggressive lobbying by rent-seeking ISPs looking to collect fees on a per device basis rather than per connection. That is so confused. First, many (the majority?) of people in the IETF who didn't like NATs had sound technical reasons for so doing (it breaks end-end, makes third party referrals in peer-peer applications harder, etc). Those of us who diagree with them don't (in general) disagree about those costs, just think the benefits of NAT outweigh them. (See below.) Second, while the ability to have a per-device fee might have seemed like a nice fantasy to some ISPs, the reality is that their costs are driven by i) the total amount of bandwidth used at the site, and ii) the costs of providing the connection (hardware, configuration, etc). Anyone who tried to monetize per-device would have had competition from people who only charged based on their actual costs. And given that NATs are so easy for consumers to set up, I think most ISPs realize they save them a bundle in customer support costs (given that each customer call costs them some amazing amount of money); the inevitable support costs from per-device would diminish the amount of money allegedly to be made. From: Keith Moore mo...@network-heretics.com NATs still are a terrible thing that need to be killed. They break applications and prevent many useful applications from being used on the Internet. That much is more widely understood now than it was 10-15 years ago. You're still ignoring what _empirical evidence_ has shown to be true: yes, there are costs to NAT, but it also has benefits, in that it attacks some of the fundamental flaws in the IPvN architectures in general (lack of local allocation of identifiers, ability to relocate [aka renumber] without local reconfiguration, etc) and in IPv4 in particular (not enough address bits), and when people look at the overall cost/benefit ratio, they prefer it to the alternatives. Noel
Re: Regarding call Chinese names
From: Simon Perreault simon.perrea...@viagenie.ca I think I've seen Chinese names written in both orders. That is, sometimes Hui Deng will be written Deng Hui. Am I right? Does this happen often? I'm not certain about Chinese, but I know that with Japanese names, which have the same issue (family name first in native language), both orders happen a fair amount. (This also happens with Hungarian names, which also use family-first - rare in the West, but it does happen.) Is there a way to guess what order a name is written in? Sometimes it's not easy for non-Sinophones to know which part is the given name and which part is the family name. Unless you know a certain amount about the language, my guess would be 'no'. Hence the common practise in some academic circles of giving the family name in all capitals, to show which it is. So whether you see Junichiro KOIZUMI or KOIZUMI Junichiro, you know what you're seeing. Maybe the IETF should adopt that practise in, e.g., attendee lists? I'm not sure what to do about e.g. RFC's - there's a pretty strict X. Yyyy form for names, where X is the given initial, the Yyyy the family name. Do we want to change that, or just say 'sorry, family-first people, you'll have to mangle your name to fit the RFC format'? (That happens already in other cases, BTW. I'm called by my _middle_ name - which caused all sorts of issues for the I-D software when J. Noel Chiappa tried to submit a draft listing N. Chiappa. It Did Not Like.) Do we want to encourage people to do the capitalization in their email addresses (the full-name part, not the mailbox name part), so that people know? That's obviously not under our control, but we might _suggest_ it. Noel
Re: Regarding call Chinese names
From: Melinda Shore melinda.sh...@gmail.com I agree that this is probably not appropriate for publication as an RFC but it would certainly be useful to find someplace for it in the wiki. Actually, it would be good to have a series of these (or maybe one page with a number of sections): we could also use one for Hispanic names (patronymic _and_ matronymic 'family name'), for cultures which only use _one_ name (no family names), etc, etc. And as Patrik points out, there are also the Icelanders.. :-) Noel
Re: IETF 87 Registration Suspended
From: John Levine jo...@taugh.com what's different in Berlin from Paris and Prague and Maastricht. The Germans have more 'zealous' tax collectors? :-) Noel
Re: Comments For I-D: draft-moonesamy-nomcom-eligibility-00 (was Re: The Nominating Committee Process: Eligibility)
From: Scott Brim scott.b...@gmail.com Please someone find and share the UUCP message where the body said I don't understand the concern about too many message headers. I don't know about there being a UUCP one, but here: http://www.chiappa.net/~jnc/humour/net.header is the ARPANET one. Noel
RE: Comments For I-D: draft-moonesamy-nomcom-eligibility-00 (was Re: The Nominating Committee Process: Eligibility)
From: Adrian Farrel adr...@olddog.co.uk told not to post is, AFAIK only achievable through a posting ban, which you don't seem to have received. Yet. Noel
RE: Comments For I-D: draft-moonesamy-nomcom-eligibility-00 (was Re: The Nominating Committee Process: Eligibility)
From: j...@mercury.lcs.mit.edu (Noel Chiappa) Yet. PS: I probably should have added a :-) to that. Sorry, it's early, the brain's not firing on all cylinders yet, and I was so entranced by the chance to set the record for the shortest ever IETF list e-mail... :-) Noel
Re: The Nominating Committee Process: Eligibility
From: John Curran jcur...@istaff.org the proposed language also increases the possibility of capture (i.e. the ability of an single organization to inappropriately skew the outcome of the process) Why not just say directly that 'to prevent capture, no more than X% of the NomCom may work for a single organization' (where X is 15% or so, so that even if a couple collude, they still can't get control). Noel
Re: IETF Diversity
From: Randy Bush ra...@psg.com there appears to be a problem with your mail system. mail which is clearly from the 1950s is appearing on the ietf list. You're right about it having fallen through a time warp - but you got the sign wrong. It's from the future, not the past. Noel
Re: IETF Diversity
From: Doug Barton do...@dougbarton.us their work has been ignored and/or shouted down since it doesn't fit the narrative. The usual fate of those who care more about the data than the herd-meme of the moment. For a good example of this in action, those who are unfamiliar with the work of Barbara McClintock should try looking her up. (She actually stopped publishing because the reception given to her work was so negative.) (In honour of the thread, I have carefully picked a female example. Is that being sensitive, or patronizing? Left as an exercise for the reader...) Noel
Re: IETF Diversity
From: Melinda Shore melinda.sh...@gmail.com it's likely that for a few cycles nomcoms will try to be sensitive to the question of the underrepresentation of women and then it will be back to business as usual ... It's unusual for people to voluntarily surrender their privilege. Yes, the men of the IETF are just irretrievably opposed to handing over any power to women. It's going to have to be pried from their cold, dead hands... Noel
Re: Weekly posting summary for ietf@ietf.org
From: David Morris d...@xpasc.com I've wondered for some time whether the reported bytes is the whole message I send included context quotes, or if there is an attempt by the summary logic to factor out quoted content. I think it's a _feature_ to count the included content, so that people who (often recursively) top-post on long prior messages, instead of editing down to just the bit(s) they are replying to, have some negative feedback for that (irritating) habit. Noel
Re: Not Listening to the Ops Customer
From: cb.list6 cb.li...@gmail.com the emergent complex dynamical system we call the internet ... which is almost completely zero compliant to the e2e principle. Not that e2e is the wrong principle, but ipv4 could not support it as of 10+ years ago. Hence, nearly every internet node is behind a stateful device ... Yet, corners of the ietf call this real world internet of middleboxes as broken. As some of it is broken, so you have things ... to bust through it. Mutation happens. That said, the teaching moment here is look back and realize the internet was not engineered, if was emerged. Given that the internet is not engineered ... how do we make it go fast, bigger, better given the few levers we have. Exactly. The Internet is evolving, and can we push it in a better direction, and if so, how? In all of this, the bottom line, to me, is that we have to be aware of the limits of our power. Mandating forklift replaces is just a non-starter. By and large, new stuff has to interoperate to the maximum extent possible with unmodified 'stuff'; an approach that don't require _any_ host modifications is almost a sine qua non. And it was long (and remains) a truism of system design that security can't be added at the last stages - it has to be 'baked in' all the way through the design process. The same is true, now, of deployment and interoperability. I persist in thinking that those 32-bit names are continuing their evolution into local-scope names, with translation at naming region boundaries. How can we improve that - reduce the brittleness of the middleboxes you refer to, by making their data more visible (and thus replicable, etc)? And we still need global namespaces. DNS names are slowly becoming more key (the Web now makes them a key namespace at the protocol level, not just the content), but what else? At one point the IETF considered trying to craft a new endpoint namespace (through the NSRG, if I have remembered the name correctly), but I think in retrospect that's a non-starter - changing TCP (which is what that would require) is not really an option (see point 1). Within that 'deployable' envelope, I am now back to where I was almost 30 years ago, which is that _probably_ the thing to deploy is a new location namespace, for use by the path-selection (since only _some_ routers have to know about that). That's not a namespace the Internet has now, and so we'd be less constrained in doing so, and it's one the Internet really needs. Noel
Re: Comments for Humorous RFCs or uncategorised RFCs or dated April the first
From: Andrew Sullivan a...@anvilwalrusden.com It's always April 1st somewhere on the Net? Especially if you (or your packets, to be precise) can travel backwards in time Noel
Re: Less Corporate Diversity
From: Melinda Shore melinda.sh...@gmail.com If everybody serving that gatekeeper function comes from a similar background (western white guy working for a large manufacturer) To toy with Godwin's law for a moment - this sounds rather like western white guy physics... Noel
Re: Martians
Subject: Re: Martians Martian is nice expression. Weren't 'unusual' packets called 'Martians' at some early stage of Internet work? It certainly has history in the IETF as a term of art, I think that's it. Noel
Re: IPR view (Re: Internet Draft Final Submission Cut-Off Today )
From: Eric Burger eburge...@standardstrack.com With my legal services hat on, with the US joining the rest of the world with first-to-file, those few weeks of publication could mean the difference between a free and open standard and a NPE swooping in and attempting to tax the industry. If that's the concern, there's an easy fix for that one: upload the document to one of those open file-sharing sites (Scribd, DropBox) and send a pointer URL to the WG mailing list. That out to count as 'open publication' for legal purposes. Noel
Re: congestion control? - (was Re: Appointment of a Transport AreaDirector)
From: t.p. daedu...@btconnect.com is this something that the IETF should be involved with or is it better handled by those who are developping LTE etc? I would _like_ to think it's better done by the IETF, since congestion control/response more or less has to be done on an end-end basis, so trying to do it in any particular link technology is not necessarily useful (unless the entire connection path is across that technology). But... From: Cameron Byrne cb.li...@gmail.com There is a huge cross layer optimization issue between 3gpp and the ietf. It is worse than you can imagine, highly akin to how the industry moved passed the ietf with Nat. Well, I sort of see the analogy with NAT. But rather than rathole on a non-productive discussion of similarities and causes, I think it's more useful/fruitful to examine your point that people are doing all sorts of localized hacks in an attempt to gain competitive advantage. Sometimes this is not a problem, and they are (rightly) responding to places where the IETF isn't meeting needs (one good example is traffic directors in front of large multi-machine web servers). But how much good going it alone will do in this particular case (since congestion control is necessarily end-end) is unclear, although I guess the 'terminate (effectively) the end-end connection near the border of the provider's system, and do a new one to the terminal at the user's device' model works. But there definitely is a risk of layers clashing, both trying to do one thing... Noel
Re: 30th Anniversary of Transition to TCP/IP
From: IETF Chair ch...@ietf.org The ARPANET transitioned to TCP/IP on 1 January 1983. That was 30 years ago, It's very hard indeed to fully grasp that it's only been 30 years. My kids (now roughly 20) live in what is in some ways an entirely different world to the one I grew up in. Many technologies have had profound impacts in a short time (my parents were born shortly after the dawn of flight, and in their late middle age saw people landing on the Moon); and train, telegraph and telephone all each had tremendous impact, but I'm not sure any have had quite as much as this internetting stuff. It's been quite a ride. Noel
Re: [lisp] Last Call: draft-ietf-lisp-eid-block-03.txt (LISP EID Block) to Informational RFC
From: Geoff Huston g...@apnic.net I don't have any comment, one way or another, on what seems to be the basic point of your note (about what role, if any, the IETF should play in allocation). However, there was one aspect I wanted to comment on (it's not clear, reading your note, if this was clear in your minds): It is noted that the LISP experiment already makes use of a /32 prefix ... If the LISP experiment fills this /32 prefix to such a level of utilisation ... What are the plans to migrate out of the experimental address allocation? Would this renumbering out of an experimental address allocation even be feasible to contemplate if the experiment achieves a level of deployment that is commensurate with the allocation of /16? The concept, as I understand it, is that there will be no migration out of [that] allocation, for the simple reason that the entire rationale of this range of namespace is that it will be processed differently, i.e. require special casing in the code in various places; something like: if ((dest EIDSPACEMASK) == EIDSPACEALLOCATION) process_one_way(); else process_another_way(); That being the case, the last thing one would want is either i) changing the block that is handled specially, or ii) having a number of smaller blocks, allocated over time, as either one would require much more complex code to handle: you'd have to have some sort of config file, which could hold multiple blocks, code to read it, the code to process packets (above) would have to be able to handle multiple blocks, yadda-yadda. (Changing the block is the same as having multiple blocks, because past a certain point you're too big for a flag day, which would be the only way to avoid having multiple blocks in use at the same time.) It's that that's driving the suggested reservation, and the smaller actual allocation: the code would handle any address inside the _reservation_ with the special processing, but the bulk of the space would be left _unallocated_, for future allocation in some yet-to-be-determined process (one which would presumably be set up by the existing namespace allocation entities), while a small chunk would be allocated to the experiment, for now. I suspect (I haven't communicated with them directly) that the people who are involved with this scheme don't really care _who_ allocates the space, and how - all they care about is that it's all in one chunk - for the reason laid out above. Noel
RE: [lisp] Last Call: draft-ietf-lisp-eid-block-03.txt (LISP EID Block) to Informational RFC
From: George, Wes wesley.geo...@twcable.com I don't think that expecting code to handle two blocks (the experimental one and the permanent one) is asking too much We disagree. For me, it's extra code/complexity, and it buys you absolutely nothing at all. If a single permanent allocation that never changes is truly necessary Allocation != reservation. Nobody is asking for the entire chunk to be _allocated_ (i.e. given out), just that it be _reserved_ for this use. Noel
RE: [lisp] Last Call: draft-ietf-lisp-eid-block-03.txt (LISP EID Block) to Informational RFC
From: George, Wes wesley.geo...@twcable.com Allocation != reservation. You're hairsplitting on semantics in a way that is mostly unhelpful to the discussion at hand. I _thought_ that the point of the messages from Geoff and others (who were questioning about how there were no details in the document of how the allocation would work) was about _how_ the space was to be handed out - to which the allocation/reservation distinction _is_ important. Noel
Re: [lisp] Last Call: draft-ietf-lisp-eid-block-03.txt (LISP EID Block) to Informational RFC
From: Cameron Byrne cb.li...@gmail.com If LISP succeeds, this results in significant reduction in core table sizes for everyone. Not everyone. Only people who carry core tables. 'this results in significant reduction in core table sizes for everyone who has core tables' sounds a bit tautological, no? That is LISP twist, it transfers cost from a few cores to many edges. If you define 'many' is 'people who are actually trying to communicate with a given site', yes. So it has transferred costs for communicating with site X from 'everyone with a core table, everywhere in the entire network' to 'just the people who are actually trying to communicate with site X'. This is bad... how? (When I first quickly read your message, I thought you were making a point about the routing overhead of EIDs being carried in the global routing tables for use by legacy sites, which is an interesting point, but not the one that you make here.) Noel
Re: [lisp] Last Call: draft-ietf-lisp-eid-block-03.txt (LISP EID Block) to Informational RFC
From: Cameron Byrne cb.li...@gmail.com So it has transferred costs for communicating with site X from 'everyone with a core table, everywhere in the entire network' to 'just the people who are actually trying to communicate with site X'. This is bad... how? I didn't see an answer to this question (which is not at all LISP-specific - rather, it's a general observation about the allocation of overhead costs in a network). Why should site B, which _never_ talks to X, have to pay, so that site A can talk to X? edge sites have to buy more routers with newer functions. Each vendor will have its own answer to this question, but the LISP software suites I know of are new loads for existing router hardware. Do you know of a LISP package which only comes with new hardware? Noel
Re: [lisp] Last Call: draft-ietf-lisp-eid-block-03.txt (LISP EID Block) to Informational RFC
From: rog...@gmail.com the routing integration between none-LISP and LISP internet, how are that going to work? The current document isn't clear enough on that as I see it. The way the routing will work would take a couple of PhD theses to fully cover (I know of one that's already underway). So it's not really a topic that can be covered in this ID. Adding to the complexity is that if LISP becomes widely deployed, how the routing works will likely change over time; in the early stages, when there are small islands of LISP, it'll be one thing; later on, when there are islands of legacy stuff, it'll be totally different. Etc, etc. Address these thing somehow in the document, even just mention that it's subject for other document and I'm happy... :-) The IETF used to have this concept of 'rough consensus and _running code_'; i.e. we tried stuff out to see if it works. When did we change into an organization that had to have every 'i' dotted, and every 't' crossed, before we could move an inch? (Saying 'just refer to the document where it is covered' doesn't help, if the other document isn't written yet.) All this ID is trying to do is allocate a rather modest chunk (~ one quarter of one tenth of one percent - .025% - if I've done the math right) of address space for an experiment; exactly how it will be best used, and what the best allocation process is, is to some degree part of that experiment. Noel
Re: I* Member Removal Process
From: Russ Housley hous...@vigilsec.com And, the community does not have rough consensus for simply declaring his seat vacant under the current set of BCPs. Why not, I cannot fathom, because as SM has pointed out (hat tip), RFC 4333, IAOC Member Selection Guidelines and Process, has text which is exactly on point: if the appointed member is unable to serve the full two-year term, the selecting body may, at its discretion, immediately select a replacement to serve the remainder of the term using the interim process defined in Section 3.5.1. The document doesn't define in detail what constitutes unable to serve, but it clearly means via some form of incapacitation (death, severe illness, etc). Obviously, the intent of leaving un-stated exactly what constituted unable to serve the full two-year term was that it would be determined by common sense, applying the unable to serve test to the facts at hand. He's clearly unable to serve. I find it hard to see how someone who will not respond to _any_ form of communication, over a period of months, is '[]able to serve'. If the _only_ way to determine that someone is unable to serve the full two-year term is via the recall process, why didn't the document say that? There is just the bald statement that 'if someone is unable to serve, a replacment can be selected using the same process that selected them'. And he's definitely unable to serve. But I guess the IETF would rather deploy the most onerous, heavy-weight bureacratic process it can find (one intended for entirely different circumstances), as opposed to using the capability _already in its process documents exactly for cases like this_. Noel
Re: don't overthink, was Just so I'm clear
From: David Morris d...@xpasc.com someone unsatisfied with a business decision by the adjusted IAOC membership could sue based on documented process not being followed to appoint the membership. Nothing can stop someone from filing a suit, no matter what you do (even if you do follow procedure). But try looking at it this way. We're all agreed that the IETF in plenary mode (i.e. all of us) can change any/all policy/procedures, right? So, view the original call from the IAOC as a request to the IETF, in formal plenary mode, to make the following policy/procedure changes/etc: - To declare that, due to an oversight on our part at the time of drafting, our existing policy/procedure does not handle certain cases, so we are _temporarily_ (see below) setting up an ad hoc procedure to handle those cases; - That said temporary ad hoc procedure is to have the IETF in plenary mode decide/declare that positions are vacant due to the withdrawal of the holder. The call also make the following procedural request: - That, following that temporary ad hoc procedure, in the particular case in the original call, the holder be declared to have vacated, due to his long lack of communication, despite _extensive_ attempts to contact him. So if people all hum to OK all that, it has _just as much legitimacy_ as _any other policy/procedure set into place by the IETF in plenary mode_. And of course we all recognize that we need to write down non-ad hoc policy/procedure to handle such cases, an effort which has already started. From: John Levine jo...@taugh.com Having reread RFC 4071, I don't see a rule that says that the death of a member will result in the position being declared vacant, either. Nor are there any rules that say what documentation would be required to establish that someone had died. At some point we have to allow a sliver of common sense to intervene so people can do reasonable things to solve problems. Exactly. I'm really boggled at the amount of time and energy which has been wasted arguing about this point. Don't we have better things to spend our time on? It's pretty clear he's checked out, and needs to be replaced. We ought to focus on the most economical way to achieve that purely bureacratic action. Noel
Re: don't overthink, was Just so I'm clear
From: Barry Leiba barryle...@computer.org We're all agreed that the IETF in plenary mode (i.e. all of us) can change any/all policy/procedures, right? Alas, that's not how we do things. Wrong. That's exactly how we do things. Any piece of electronic paper you point to to argue otherwise was adopted in exactly that manner. Noel
Re: don't overthink, was Just so I'm clear
From: Doug Barton do...@dougbarton.us When Marshall was appointed the rules we have now were in place. To change the rules now, and then apply them to this situation is by definition retroactive. By that logic, _any_ change to any rule involving, say, the IESG (repeat for all other I* bodies) - e.g. changing its powers, etc - can't come into play until between 1 and 2 years have passed, so that all existing seated members will have been replaced/reseated. Otherwise you'll be changing the powers/etc that they had when they were seated - i.e. retroactive changes to their powers/etc. Noel
Re: don't overthink, was Just so I'm clear
From: Doug Barton do...@dougbarton.us Removal from office _is_ considered a punitive action Sorry all, but my bogometer just blew out. He isn't being turfed out of his post (in a high-level sense); he quit. He simply wasn't polite or thoughtful enough to do so formally, instead of by just going catatonic on us. It's very rude to do that. If he's going to bail, he ought to have the decency to summon the strength needed to say 'I quit'. That's not a long or involved communication, and unless he's completely catatonic, to the point of being institutionalized, he should be able to manage that, at least. I know whereof I speak, having been through some bad meltdowns myself, so much as I have great _personal_ sympathy for him (knowing what he must be going through to act like this), _institutionally_, I don't. Anyway, in view of that failure on his part, I would recommend that he never, ever, be considered for _any_ post in the I*, ever again. People who can do that sort of thing shouldn't be trusted with any responsibility ever again. And now, yes, I _am_ being punitive. Because I'm ticked off at the amount of time/energy being wasted in this incredible stupidity, and the ridiculous, petty-fogging amateur legalisms which are being thrown around like the chicken-feed they are. This probably means that he's paying the price for other people's actions, but since when did life come with a 'fair' guarantee tag? Noel
Re: IAOC Request for community feedback
From: Michael StJohns mstjo...@comcast.net The IAOC is requesting feedback from the community concerning a vacancy that the IAOC feels is not adequately covered by existing IETF rules. I'm not sure why the IAOC thinks that the recall procedure shouldn't be followed. Because it's a fairly lengthy, complex, and effort-consuming, process to use in this kind of case - rather like using a pile-driver to crack a nut? I hear you, and understand the concern about ignoring established procedures, but at the same time, calling for a hum from the IETF community is sufficient to get the _entire procedure_ changed, a far more consequential act, so asking for a hum to temporarily bypass them seems to me to be acting in the general spirit. And of course we do need to update our procedures so that if this ever happens again, we don't face the choice of rolling out the pile-driver, or proceeding in an ad hoc way, but that's a separate point. Noel
Re: IETF HOF vs. ISOC HOF
{Apologies for the bunched reply - I was offline for a bit, now trying to
catch up without inundating the list.}
From: Theodore Ts'o ty...@mit.edu
Do we need to wait until someone who has made significant contribution
to have passed away before we recognize their contributions?
...
I wonder if we are conflating the concept of a memorial and a Hall of
Fame
This is an excellent point. I guess I just fell into assuming that the IETF
HoF would be for people who have passed away because that was how the whole
discussion started, and I didn't question that initial assumption. But you're
quite right that it would be nice to recognize people while they are still
around to appreciate it.
(I've always been bummed that Van Gogh only sold like 3 paintings while he
was still alive, and so probably never appreciated how good his work was, and
how much it would mean to other people.)
From: Dave Crocker d...@dcrocker.net
Since ISOC recently initiated its own Hall of Fame effort, how would
the IETF version be different and why?
Umm, hard to put into words, but basically the IETF one would be i) for
people who had done things for the IETF (e.g. Steve Coya), or people whom we
felt were important, but whose contributions (and affect on the world as a
whole) didn't rise to the level of the ISOC one (e.g. Abha).
From: Lixia Zhang li...@cs.ucla.edu
life moves forward fast, history fading away quickly, if we dont make
an effort to put it in record.
Exactly.
From: Randy Bush ra...@psg.com
a friend suggested privately an article in the ietf journal when
someone has died. ... and it is archived.
i will not indulge in the swamp of attempting to codify who writes it
and how. if the ietf journal editor(s) can not be trusted, replace
them.
Agree with both of these (although _very_ significant figures, e.g. Jon,
might merit a full-blown RFC, as Jon did - RFC-2468).
One tweak I would request, though; if someone could set up a web page which is
linked to all the various memorical articles, and put a link to that somewhere
close to the top of the IETF web site, so it would be easy to find/notice,
that would be really useful - short of that, one would have to grub around to
find them all.
From: Jari Arkko jari.ar...@piuha.net
I also think that whoever we at the IETF think is important probably
wrote enough important RFCs.
Not necessarily. Not everyone important in the IETF writes RFCs...
Noel
Re: IAOC Request for community feedback
From: Michael StJohns mstjo...@comcast.net When would you consider the office vacant? The complete data on what attempts had been made to communicate with him were given to us all, so we can all form our own individual opinion as to whether sufficient conditions had been met. I'm currently in jury duty - and sequestered for a major murder trial? ... Trapped in a hospital for 6 weeks for traction? In all of these cases one presumably wouldn't vanish without a word of explanation. It's that, as much as the non-performance, that's an issue. You know as well as I do that in a normal company, if an employee stopped showing up for work with no notice, no communication about the situation, and that went on for months, the person would find themselves terminated. From: Doug Barton do...@dougbarton.us It is neither safe, nor appropriate, to assume that the subset of people humming about this issue overlaps sufficiently with the subset that hummed about establishing the procedure to justify this decision. What, we can't change a procedure unless the set of people who previously OK'd it now agree to change it? I don't think so. A hum is a hum is a hum. Noel
Re: IAOC Request for community feedback
From: Doug Barton do...@dougbarton.us You've also snipped out the entire portion of my message where I talked about actually changing the procedure I happened to see one point I wanted to say something about (the 'hum group' thingy), that's all. And now that I've thought about this whole thing a bit more, I think Mike may have put his finger on the key point: just what is enough to consider the office vacant? His list of scenarios points out (implicitly) that we're probably going to have a very hard time codifying that, without wasting endless hours discussing and word-smithing. That being the case, probably the much easier, simpler and better formal procedure to set up, for use in these rare cases, is to put the facts of the particular case before the community, and let them decide if the actions in the particular case count as 'leaving the office vacant'. Which is, by an odd coincidence, just what's been done here. you have now received a non-trivial number of responses saying that arbitrarily declaring the position vacant is not an appropriate action. And considerably more saying it is. Look, using the full-blown recall process here is really disproportionate. That complex, lengthy process is appropriate for places where one is unhappy with what an office-holder is doing. It's a wholly different situation when someone's has effectively resigned by going incommunicado for months. I would like to point out that the United States Government is also happy to use very different mechanisms for the two cases: for removal of an officeholder over what they have done, the lengthy, complex, impeachment and trial process is specified. For someone who's just plain incapacitated, a much simpler process (a simple majority of the Cabinet) can act. From: Tobias Gondrom tobias.gond...@gondrom.org And maybe we can get a 3 minute time piece from him (or someone authorised to speak on his behalf). If he would resign due to the fact that he has no time at the moment and for the foreseeable future, everything would be settled without trouble. Now, that's by some distance the best suggestion I've heard yet. Can Ray (or whomever) contact that person they are in touch with, and pass in a message asking him if he wouldn't mind just formally quitting, so we don't have to waste inordinate amounts of time and energy either i) doing the recall thing, or ii) debating whether we need to do the full-blown recall or not? Noel
Re: Just so I'm clear
From: Doug Barton do...@dougbarton.us recalling someone from one of these positions _should_ be hard to do, and should not be undertaken lightly. No disagreement there - but we're not trying to recall him because of actions he took, things he said, etc, etc. Like I said, I think the US's federal constitution is a useful model here: it has a very onerous process (impeachment and trial) with a high final bar (2/3) for actions taken in response to what someone did/said, but a wholly different, simpler and easier process (majority of Cabinet) for sidelining someone because of incapacity. And I doubt anyone here is seriously going to argue that Marshall is not fulfulling his role... From: Melinda Shore melinda.sh...@gmail.com I am curious to know whether or not there are people who feel that Marshall shouldn't be considered to have quit IAOC. If there's nobody who feels that way I'm personally great with going ahead without a recall. Exactly. Noel
Re: In Memoriam IETF web page
From: Randy Bush ra...@psg.com i am not sure abha or jon would want to be on such a list. remember them and honor and carry on their work, don't memorialize them. I hear you, but I am also mindful of human nature - and people often (usually?) tend to be startlingly non-conversant with history they didn't live through. In other words, if we don't do something to inform people of people like Jon and Abha, people coming in now _won't_ remember them. I myself am a perfect example of this. When I started, I had for a year (or more, I don't recall exactly) an office two doors down from J.C.R. Licklider. Alas, I never got to know him - because I had no idea who he was. (This, to me, is akin to a young physicist having an office next door to Einstein, but not knowing who he was. Startling, but it really happened.) The thing is that nobody ever told me who he was, or what he had done, so as a result I had no idea I might want to take time out of my focus on doing stuff in order to pay attention to this person. So I think some memorialization of significant people who are no longer with us is warranted. Maybe an 'IETF Hall of Fame', to which each year we can add significant contributors whom we've lost, or something like that? And the Tao could point to it. Noel
Re: In Memoriam IETF web page
From: Scott Brim s...@internet2.edu If this memorial wiki page could be open to anyone who ever contributed to any I* and for whom there was at least one person who wanted to contribute the information, then fine. Then it turns into (effectively) a phone book - and I don't know too many people who read phone books. Not that I object to the creation of such a construct - far from it, I expect that historians in decades to come would probably find it valuable and interesting. I'm not sure too many others, would, though (at least, in its entirety - for individual people they already know, they might find it good). So it's not a replacement for a Hall of Fame, which people might read, or scan through, in its entirety. (Steve Coya, for instance, I would like to see memorialized in an IETF HoF. He did a great deal for us, but people who joined recently will have no idea who he was.) If not, then it would be yet another situation where there will be a line between the in-crowd and the out-crowd. Every award ever devised is, implicitly, a line between the 'betters' and the 'lessers'. So you're saying we should get rid of them all - the Nobels, the EU's Sakharov Prize (for which I have a soft spot because the first one went to one of my great heroes, Anatoly Marchenko), etc, etc? (And no, I'm not ignoring the difficulties in picking honorees, in any system. Maybe that difficulty makes it too much trouble to have an IETF HoF. But that's a different point entirely from the ethical wholesomeness of having honorees at all.) Noel
Re: In Memoriam IETF web page
Not that I object to the creation of such a construct - far from it .. So it's not a replacement for a Hall of Fame, which people might read, or scan through, in its entirety. From: Scott Brim s...@internet2.edu you're assuming that being remembered on an IETF wiki should be an exclusive award. From: Theodore Ts'o ty...@mit.edu Would you consider a war memorial a phone book? ... Just make it a list, with the most recently passed at the top of the list. You both seem to have completely missed the point of my message, so let me re-state it more explicitly. When I said Not that I object to the creation of such a construct (i.e. Scott's suggested memorial wiki), I assumed that that made it perfectly clear that I _wasn't_ against the concept of some sort of encompassing listing/memorial. So when I went on to say it's not a replacement for a Hall of Fame, I assumed that people would understand (given the above point) that I was positing that i) such a HoF would _necessarily_ be a separate construct from a memorial, and ii) that I saw the use/need for such a separate HoF. I.e. (to be even more redundantly explicit) one could in theory have either the memorial, the HoF, or both, or neither. I make (and made) no statement about the memorial - as I said, 'I don't object to such a construct'. More explicitly, if people want to do that, that's fine with me. If they don't, that's fine with me too. But I still feel a mild level of need for a IETF HoF to recognize, and keep prominent (for new members) the memory of past IETFers whose contributions are worthy of recognition, but who probably don't rise to the level needed for more major honours (e.g. the ISOC Internet Hall of Fame). Several have been named in this discussion. Noel
Re: Last Call: draft-gont-intarea-obsolete-eid-option-01.txt (Obsoleting the Endpoint Identifier (EID) Option) to Proposed Standard
From: Eggert, Lars l...@netapp.com The IESG has received a request from an individual submitter to consider the following document: - 'Obsoleting the Endpoint Identifier (EID) Option' draft-gont-intarea-obsolete-eid-option-01.txt as Proposed Standard Have the original authors [sic - JNC] been contacted? Alas, the author of the ID which defines this option, Charlie Lynn, is no longer with us: http://www.postel.org/pipermail/end2end-interest/2004-June/004195.html I can probably give as good a judgement on it as anyone, though. Looking at the ID defining the option: http://ana-3.lcs.mit.edu/~jnc/nimrod/eidoption.txt (dunno why the obsoletion ID doesn't give a URL for it), the obsoletion ID is slightly inaccurate: it wasn't just meant to be used with the Nimrod routing architecture, but rather the endpoint name format supported by that option is totally general, allowing any endpoint name format to be used. (In fact, one large faction of the Namespace Research Group wanted to use a format for endpoint names which would have made use of the 'variable length' capability of this option, but I digress..) I don't see any particular reason to not obsolete this option, though; no recent proposal uses a separate header option for endpoint identification in IPv6. Recent work on adding endpoint names has either i) used part of the IPv6 address as an EID (e.g. ILNP), or interpreted the existing IPvN address as an EID (e.g. LISP). And, in any event, if we decide we need it, we can always bring it back (according to the obsoletion ID, it's merely to be marked obsolete, not re-assigned). Noel
Re: Last Call: RFC 5011 (Automated Updates of DNS Security (DNSSEC) Trust Anchors) to Internet Standard
The IESG has received a request from the author to consider the following document: 'Automated Updates of DNS Security (DNSSEC) Trust Anchors,' RFC 5011 as an Internet Standard. ... The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. I strongly support this requested action. This specification is both i) well designed (not to mention very clever :-), and ii) fulfils a real, major need. Noel
Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site
From: Dave Crocker d...@dcrocker.net Apparently you consider the IRTF, IAB and RFC Editor all to be outside the IETF. You apparently seem (from this) to think they're not? Wow. Noel
Re: Last Call: draft-gp-intarea-obsolete-ipv4-options-iana-02.txt (Formally Deprecating some IPv4 Options) to Internet Standard
The IESG has received a request from an individual submitter to consider the following document: - 'Formally Deprecating some IPv4 Options' ... The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. This seems like a Good Thing to me. With one possible exception (below), all of these are clearly not useful. I personally might have left the 'Traceroute' one off the list, since it seems well-designed/defined, but i) nobody uses it, and ii) it's easy enough to resurrect it if we ever do decide we need it, so I don't object to its inclusion in this list. Noel
Re: IETF...the unconference of SDOs
From: Randy Bush ra...@psg.com i say scott should teach emacs :) Epsilon, dude! Who the heck wants to write their editor extensions in freaking LISP? :-) Noel
Re: Leading Global Standards Organizations Endorse 'OpenStand' Principles that Drive Innovation and Borderless Commerce
From: Stephane Bortzmeyer bortzme...@nic.fr I strongly regret that Commerce has a specific mention, among all the other uses of the Internet. The network is not only open for business! I hear you, but unless the Internet were a money-making system it would not have grown as quickly, or as large. So I think it's OK to make that one 'primus inter pares'. Noel
Re: Last Call: Modern Global Standards Paradigm
From: John C Klensin john-i...@jck.com It is worth remembering that in the most critical part of that period, the IETF wasn't developing/pushing TCP/IP in the marketplace but had its face firmly immersed in the KoolAid trough Ahem. There were quite a few of us in the IETF sphere who were not at all fans of the OSI stack - and we worked very hard on TCP/IP, and the deployment thereof, precisely to kill the OSI stack. No disagreement with your other comments, just that one point. Noel
Re: Last Call: Modern Global Standards Paradigm
From: Yoav Nir y...@checkpoint.com These operators are (hypothetically) Libyan citizens, right? Residents of Libya who could go to jail for routing around the problem. Most likely on a charge of espionage. That worked pretty well for Qaddhafi. Oh, wait... Yes, it cost some whom he did catch, but in the end it didn't (couldn't) save him. He was unable to cut off the data flow (in and out). Noel
Re: ITU-T Dubai Meeting and IPv15
From: Andrew G. Malis agma...@gmail.com 260-bit address should be sufficient to [s]address[/s] _name_ every atom in the universe YPIF. Noel h
Re: ITU-T Dubai Meeting
From: m...@sap.com (Martin Rex) To me, IPv6 PA prefixes look like a pretty useless feature (from the customer perspective). Far be it from me to defend IPv6, but... I don't see the case here. Our house is pretty typical of the _average_ consumer - we have a provider suppplied PA address (IPv4, but the principles are the same), which they seem to change on a fairly regular basis as they renumber/reorganize their network. However, as we don't run any servers/services, we don't care. Thanks to the magic of DHCP, etc, everything 'just works'. So for the _average_ customer (who are 99.9...% of their customers), PA is just fine. you want some level of privacy protection and therefore a fully dynamic temporary DHCP-assigned IPv6 address This turns out to be a chimera. Such addresses don't really provide any real privacy - it turns out to be easy to track people through their access patterns, etc. Noel
Re: ITU-T Dubai Meeting
From: Yoav Nir y...@checkpoint.com For organizations renumbering is more painful, but as long as there's plenty of time to prepare - it should be manageable. If it's too painful, there are provider independent addresses, but how many really need them? Or we could separate location and identity. Just a thought. Oh, wait... (Just channeling my inner Randy... :-) Noel
Re: ITU-T Dubai Meeting
From: Yoav Nir y...@checkpoint.com I live in the same house. My computer is connected to the same socket in the wall. That's your physical location. Irrelevant (basically) ato the network. All I changed was the ISP. Why do we call the = thing that's changed location? 'Location' in the network-centric sense (i.e. 'where in the overall network's connectivity map you are'). Is there a better term? (Not that we're likely to be able to switch to it now, 'location' is too engrained, going back to RFC-1498, if not before.) Noel
Re: NomCom 2012-2013: Third Call for Volunteers
From: Yoshihiro Ohba yoshihiro.o...@toshiba.co.jp Probably nothing can be perfect when defining affiliation, but I think some definition can help reducing hidden conflict of interests. I suspect that unless it is done very carefully, any more extensive definition is simply going to open additional potential loopholes, in the additional text. Just say something very non-specific affiliation (interpreted as broadly as possible), and leave it at that. Noel
Re: ITU-T Dubai Meeting
From: Phillip Hallam-Baker hal...@gmail.com to stop such things as 'Information terrorism' which is their term for freedom of speech. :-) The current governance structure of the Internet does more than merely prevent other governments from gaining control of the Internet, it grants the US an extraordinary degree of control. Or at least they give the appearance of doing so on paper if the checks and balances on that control are not sufficiently understood. Correct; and so it might be worth changing the structure to lessen that _appearance_ of USG control. But if such changes increase the Internet's vulnerabiilty to hostile, authoritarian governments, maybe that would not (in the end) be such a good idea. as with the crypto-wars the grand bargain will almost certainly mean absolutely nothing. Not necessarily - see below. If the WCIT process results in an over-reach, governments can and will leave the ITU. The latter is unlikely, IMO. we should instead focus on the ways that the technical architecture of the Internet creates control points that are vulnerable to capture and consider ways in which those control points can be made capture-proof. Agreed. The Internet has three separate potential control points: The IP Address registry, the DNS name registry and the various registries for protocol features. And it is these that in my perception are really what is at risk in Dubai, which is why I disagreed (above) that the output of Dubai will necessarily be a NOOP. We need to protect the openness of the Internet. We do not need to perpetuate the existence of ICANN, IANA or the RIRs as institutions. Maintaining the institutions may be a means of protecting the open internet but we should be prepared to walk away from them if necessary I concur that they may be expendable, but others may differ. In particular, will not whatever replaces them be equally targets? Yes, a shell game may produce temporary relief, but in the end won't the replacements be equally targeted for takeover/control? If the ITU-T wants to also be in the business of handing out IPv6 address names then give then a /21 or a /16 and tell them to go party. No really, choose your battles. I basically agree. It could have negative impacts on the routing, by impacting route aggregatability, but it can hardly be worse that those bletcherous PI addresses, so if it makes them happy to be in charge of a large /N, why not? What I am certain of is that we do not need to rely on the counsels of those who tell us that the situation is so complex that we need not worry our little heads about it. Indeed. Noel
Re: RFC and I-D Citation Tool
From: Ole Jacobsen o...@cisco.com using the American quotation outside punctuation rule. Ugh. There may be uglier typographic conventions, but off the top of my head, I can't come up with one. Noel
Re: Proposed IETF 95 Date Change
From: James Polk jmp...@cisco.com outstanding - now we can't meet that whole year... ;-) Particularly since in _my_ religion, our religious days consist of the set of days which _aren't_ religious holidays in any other religion... :-) Noel
Patents and standards bodies
FYI; this seems relevant to us: Tech Rivals Push Copycats Battle To The Hill http://www.politico.com/news/stories/0712/78219.html Excerpts: Apple and Microsoft are telling regulators and lawmakers that not all patents are created equal. They say patents that have been developed by companies with the help of international standards bodies - such as those Motorola Mobility holds for Wi-Fi and online video - should be available for licensing on a fair and nondiscriminatory basis. ... 'Actions aimed at preventing the sale of products that rely on industry standards threaten to raise the cost and reduce the availability of popular electronics products such as mobile phones, Blu-ray players, wireless routers, video game consoles, Internet-connected televisions, and computers, among others - all of which are built upon standards that ensure interoperability' Noel
Re: Proposed Update to Note Well
From: Peter Saint-Andre stpe...@stpeter.im traditionally the IPR rules have applied to real people Well, like you, I don't want to get into a rathole on this. Yes, nothing we do can absolutely stop patents going unknown about (e.g. patents from entities which don't participate), but I would prefer to be as expansive as possible, and try and drag parent organizations in too, to the degree we can (we have already, IIRC, had cases where an organization knew of a patent, but a particular individual did not). IANAL, of course, but I assume since the original attorney-generated text did include this concept, there was some valid legal foundation for doing so. And somehow we also lost the point about you know or you believe along the way. That was deliberate. To me, believe is a loophole big enough to drive a truck through. Things either are, or are not, covered by a patent. (Yes, yes, I know: legally speaking, that's not so until a finder of fact makes that determination.) But leaving out the 'believe' means you can't say 'well, _I_ didn't think it applied' - leaving it out implies a duty to take in a wider circle of assessment of whether it applies than simply one's personal guess. Plus it also makes the text shorter.. :-) Noel
Re: Proposed Update to Note Well
From: Stephan Wenger st...@stewe.org Hi Noel, Affiliate is overly broad, and undefined and therefore not supported by BCP79. ??? My suggested text did not include affiliate? Maybe you're looking at someone else's text? Noel
Re: Proposed Update to Note Well
From: Peter Saint-Andre stpe...@stpeter.im With all due respect, that sentence could be improved. Agree with others; splitting it up into two simpler sentences is an improvement. A tweak, though (you lost something in the second sentence): Anything that you write, say, or discuss in the IETF, formally or informally, either at an IETF meeting, or in another IETF venue, such as a mailing list, is an IETF contribution. If any contribution of yours is covered by a patent or patent application made by you or your employer, you or they must disclose that. The original allowed the employer to make the disclosure (since, after all, the employee may not know of all patent filings), and also had a positive requirement to make such a disclosure; this revised one brings all that back. Noel
Re: New Non-WG Mailing List: IETF-822
From: Yoav Nir y...@checkpoint.com I've started working on draft-nir-ipv6-were-finally-deploying-it but I'm not sure what format would be an appropriate submission format in the 23rd century. The Emperor finds your lack of faith... disturbing. Noel
Re: Colloquial language [Re: Last Call: draft-hoffman-tao4677bis-15.txt (The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force) to Informational RFC]
From: Simon Perreault simon.perrea...@viagenie.ca I think colloquialisms may often be as hard to understand as excellent but seldom-used vocabulary. Indeed - and now that we have this really cool Internet thingy (it's odd to think that young people have no memory of what the world was like before a large fraction of its information was instantly at one's fingertips - and in 80 years or so, _nobody_ will remember that age personally), one can very easily look up either a recondite word, or an obscure colloquialism, in moments... Noel
Re: Colloquial language
From: Peter Saint-Andre stpe...@stpeter.im It's bad enough that many IETFers speak in a highly colloquial fashion at our meetings. ... Showing up at your first IETF meeting is quite enough of taking the plunge [1] for most people. If it's meeting attendees one is worried about, I'd have thought that having common colloquialisms in the document would be a feature, not a bug - people would meet them while facing a computer upon which they could look them up at their leisure, not in a live (and likely fast-moving) conversation. Having said that, I think both sides have decent points, and personally don't have any strong preference. Noel
Re: Issues relating to managing a mailing list...
From: Russ Housley hous...@vigilsec.com There is no option in Mailman to specify attachment-stripping by user, only by list. So? Have 'ietf@ietf.org' send a copy to to a new list, 'ietf-strippedietf.org' (the latter being set in Mailman to strip), and those who prefer their IETF email without inclusions can subscribe to the latter, instead of the former. (This whole discussion is so typical of the IETF: what should be a 30-second exercise for one person to deal with in a simple, obvious way turns into a multi-day discussion in which some try to redesign entire email systems.) Noel
Re: [lisp] WG Review: Recharter of Locator/ID Separation Protocol (lisp)
From: John Scudder j...@juniper.net On Mar 13, 2012, at 3:04 PM, Joel M. Halpern wrote: It may take engineering and evaluating some cache management schemes Isn't it relevant to the architecture document, that it be possible for a reader to judge whether the architecture is a good one or not? Yes and no. At the _architectural_ level, the details of the algorithms are not generally visible - and, more importantly, as explained below, in a 'good' architecture, it's _designed_ so that algorithms can be changed. (As Corbato so neatly put it in his Multics design paper, without the ability to change course, one has a boat without a rudder.) So in one sense, no, it's not an 'architectural' issue. However, an architecture might be a failure if there is _no possible_ algorithm which can perform a certain required function. But that condition is awfully hard to ascertain (it's hard to prove a negative). For some insight into this, look at TCP: _could_ you say, looking at the TCP specs circa 1977, that it was [architecturally] a good [design] or not? Even more importantly, was it right to go off and build the Internet, with the retransmission/etc algorithms we had in TCP in the late 1970s? (Especially given that the retransmission algorithms later turned out to be colossally wrong, leading to congestive collapse of the network about 5 years later.) Sometimes you just gotta go build it and see what happens, and see if smart people can figure out ways around whatever issues crop up. Not being able to absolutely, cast-iron prove, a priori up front, that it's feasible, is not a reasonable requirement: had we had that in place in the late 1970s, we'd never have built the Internet. _At an architectural level_, TCP did have one thing going for it with regard to its algorithms: the retransmission, window management, etc, algorithms could be replaced piece-meal (i.e. we did not have to have a co-ordinated flag day). That really saved our bacon when it turned out they had issues (and not just with retranmission - I actually remember Silly Window Syndrome). The same thing is true of the cache management algorithm(s) in the xTRs. There's no requirement that everyone run the same one, and if the current cache management algorithms turns out to have issues, it will be no more hassle to change them than it was to change TCP's retransmission algorithm. So, at the _architectural level_, LISP's cache management does have that desirable property: we can experiment with new ones, and deploy better ones, whenever we want. Also, some sites might have load patterns that are different from othersm, so that we might want to run different cache management algorithms in different places. Again, _at an architectural level_, this turns out to be trivial to do. Noel
RE: Issues relating to managing a mailing list...
Since there's no way to pick one choice which will make most people happy (whichever one is picked, the proponents of the other will be unhappy), maybe we should try and avoid making a choice? We could have two different back-end distributions versions of the list: one which strips attachments, and one which doesn't (both fed from the same input name). Then, people can sign up for whichever one they prefer. (All problems in computer science can be solved by another level of indirection, etc, etc.) Noel
Re: [lisp] WG Review: Recharter of Locator/ID Separation Protocol (lisp)
From: John Scudder j...@juniper.net Re cache management schemes, I think that depends on whether you mean system level behavior of a small-scale system, or one operating at large scale or under some kind of stress. The earlier discussion notwithstanding, for practical purposes caching is central to LISP; as such, it's a little weird to say it's architecturally unimportant. I didn't hear him say that. I think he said 'the details of particular cache management algorithm(s) aren't important to an _architectural_ understanding of LISP'. Now, what you mean by 'architectural understanding' and what I (and probably Joel) mean by 'architectural understanding' may be two different things, which may be the source of the problem. What I mean by that term is 'how is the entire system broken up into subsystems' (i.e. what are the functional units), and 'how do they interact'. I.e. a very high-level view of how the system as a whole operates - an overview in which more detailed views of individual subsystems can be slotted. That is something totally different from 'a complete model/understanding of how the system operates in various operational environments', which is somewhere in the direction of what you seem to want? Now, clearly the latter is something useful to have, but I'd like to point out that in its maximum generality it may be a 'boil the ocean' kind of goal. E.g. to have a complete and total understanding of how, say, the Internet path selection system as whole operates, you'd have to model every last piece of it (every router, etc, etc), because there's no analytical proof that it operates in any particular way. However, of necessity, any such a model is probably infeasible - we can build smaller models, and see how they operate, but they can only offer limited insight (how limited, we cannot say for sure) into just how the full-scale system is going to work. To do that, we just built it (why do multi-dimensional mice come to mind here?), and we can instrument it and watch it (as numerous studies have done, e.g. the very fine work by Craig Leibowitz and Abha Ahuja some years ago). But any sub-full-scale model is necessarily going to be 'an incomplete description of reality', to use the fine phrase from EPR. Which is not to say that better understanding of how the caching in LISP works in various operating environments (e.g. under various kinds of attack/stress), and how different potential cache management algorithms would work across a range of operational scenarios, is not useful and/or desirable. Of course it would be. (Do we have any volunteers? A considerable amount of work on caching simulation has already been done, but of course there's an infinite space of possible things to explore, both on the algorithm side and the operational scenario side.) However, i) such work is not a 'description of the architecture' as I understand it, nor ii) is it _absolutely_ necessary before trying a system in large scale, because to do it 'perfectly' is an impossible 'chicken and egg' situation: there is no perfect model _other than the system itself_. The only way to _really_ see how it works is to build it. Or am I too misunderstanding something? Noel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF Last Calls and Godwin-like rules
From: Pete Resnick presn...@qualcomm.com We do need to make sure that the folks evaluating consensus know that voting doesn't count and that their decisions are made by consensus on the technical issues, not the number of people speaking. Yes, but how do you tell where the consensus is if 97% of the people in the 'room' haven't expressed an opinion? The 'me too' posts do serve a purpose in giving a larger sample size (provided, of course, that they are from long-time IETF partipants). Noel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Variable length internet addresses in TCP/IP: history
From: Bob Hinden bob.hin...@gmail.com the other reason why we went with 128-bit address with a 64/64 split as the common case and defining IIDs that indicate if they have global uniqueness. This creates a framework that an ID/locator split could be implemented. ... we have a framework that would allow it without having to roll out another version of IP. Alas, the inclusion of _both halves_ of the IPv6 address in the TCP checksum means the framework you speak of is basically useless for an identity/location split. Noel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF Last Calls and Godwin-like rules
From: John C Klensin john-i...@jck.com When those notes come from people who do not routinely participate on IETF lists Well, that's the $64 million question, right? I mean, I don't personally subscribe to every IETF-related list, so I have no idea if the people who are posting are active in some subset of the IETF, just not (previously) this list. And does someone have to have spoken up on a list, to have just as much right to an opinion as a frequent poster? Some people are just naturally quiet. I'd say that if anyone has been subscribed to any IETF list _prior_ to the call to 'join in', their opinion ought to have just as much weight as those of us who have historically been more wordy on the main list. Noel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF Last Calls and Godwin-like rules
From: John C Klensin john-i...@jck.com people who haven't participated and haven't studied the drafts This isn't exactly about a complicated protocol: it's about whether to assign an address block or not. Noel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
