RE: what is the problem bis
Keith Moore [mailto://mo...@network-heretics.com] writes: On Oct 29, 2010, at 12:36 PM, Michael Richardson wrote: In-person meeting time is used regularly for powerpoints rather than discussion. +1. The single biggest thing that IETF could do to raise productivity in meetings is to remove video projectors from meeting rooms, replace them with white boards and pens, and ban use of PowerPoint and similar tools. I couldn't agree more. It's easy, too, just requiring a little bit of backbone... The second biggest thing that IETF could do to raise productivity in meetings is to ban Internet use in meetings except for the purpose of remote participation. Harder to do not clearly an improvement: it clear out meeting rooms a bit, but on the other hand people who (for example) just read email in meetings aren't really harming productivity too much. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: No single problem... (was Re: what is the problem bis)
Ted, I agree with almost everything you say, but want to focus on one issue (inline below). --On Friday, October 29, 2010 16:15 -0700 Ted Hardie ted.i...@gmail.com wrote: ... As we stare down this rathole one more time, let's at least be certain that there is more than one rat down there, and be realistic about the energy we have on how many we can tackle. Russ's draft tries to do two things: Restore the 2026 rules for Proposed as the functionally in-use bar for the first rung. ... Listening to the discussion, I think we have focused a great deal on point two, but have either not really noticed point one or didn't believe it.I think this addresses a marketing problem (long an issue, though now commonly explained away) and it focuses on the first two resulting issues in the quasi-chart above, and thus may have some cascade effects on the other two. It doesn't tackle any of the contributing issues, but this is not really a defect in my eyes, as those can't really be addressed by document issues. Are there other ways to tackle this? Sure. But if the community accepts that this restores the 2026 bar for the first rung *and holds the IESG to it*, then I think this is one useful place to tug on the tangle of issues. Noticed. I probably fall into the don't believe category, but for a reason I've tried to identify before. I recognize (and have commented on) the issue of how the IESG gets sufficient community support for changing Proposed Standard criteria back to what 2026 says and how a transition would occur. Some relabeling might be useful in that regard but perhaps not useful enough to be worth the trouble. The current document does not propose to change the name of Proposed Standard, so that is a non-issue at present. However, a change to the handling of documents that are candidates for Proposed Standard is ultimately in the hands of the IESG. In principle, they could announce tomorrow that any document submitted for processing after IETF 79 would be evaluated against the criteria in 2026 and no others other than reasonable document clarity. If the IESG has the will --and whatever community backing is needed-- to do that, then the two-step document is not needed. If the IESG does not have that will and backing, then community of the two-step document would merely leave us --as far as this issue/problem is concerned-- with one more set of rules we aren't following. So, if we are serious about changing (or reverting) those criteria, then let the IESG issue a statement about the new rules, schedule, and any transition plan. Let's see if such a statement is successfully appealed by someone (I'd hope, given the concerns on this list about the problem, that wouldn't happen). And then let's see if we can actually do it. There is lots of time to change the written procedures if such an effort works, even experimentally. After all, we've been out of synch with 2026 for 14 years now and it hasn't shut us down. best, john p.s. I also believe that, if part of the intent of the two-step document is to restore that bar, it is _very_ hard to deduce that from the document itself. I'd feel better about the document if that were more clear. But the document is really not the issue, the strategy is. At least IMO. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Alternate entry document model (was: Re: IETF processes (was Re: draft-housley-two-maturity-levels))
A few quick observations... --On Friday, October 29, 2010 13:20 -0700 SM s...@resistor.net wrote: ... While my instinct is that RFC publication would be desirable, if that didn't seem workable we could move the idea a bit closer to the Snapshot idea by posting the document in the I-D series and giving it a gold star. It would be difficult to get buy-in if the document is not published as a RFC. If that is true --and it may be-- it would indicate that not even we can keep track of the difference between RFC and Standard. If that were to be the case, discussion of maturity levels is basically a waste of time. Instead of eliminating Proposed Standard, how about allowing the working group output document to be published as Proposed Standard? The approval could be done within the working group only but that might results in documents of questionable quality. If we take your idea of ... (v) Document goes into do or die track I think there are other issues with your outline, but the key one is that it would really, really, depend on do or die working. If it didn't, the IETF would rapidly acquire a reputation for producing garbage as Standards, and that would be, IMO, really bad. But the odds are against do or die. We've had that provision (automatic moves to Historic for Proposed (or Draft) Standards that are not advanced within a set period) for a very long time. Unlike the Proposed Standard criteria, which have gradually evolved to become more and more burdensome in practice, we have _never_ followed that rule as written and only once (the de-cruft spinoff from the NEWTRK WG) make a serious attempt to clean out documents no one cared about any more. I also suggest that the odds are against us, if only because the IESG will always have higher priorities than reviewing the status of documents no one cares about any more (either because they didn't get traction or because they got so much traction that they represent established practice that no one has motivation to update them). In addition, I'm cynical enough to believe that IESG members would hesitate to kill off documents that have a few supporters who might put a lot of effort into complaining to the Nomcom... at least without strong documented evidence of community support. Note that we have also made killing things hard: the idea that it takes putting together and publishing an RFC with details, justification, and all of the usual sections and boilerplate to move another RFC to Historic is a post-2026 innovation. I think it was caused by the above issues with the IESG deprecating things because it was obviously the Right Thing to Do. But, regardless of the causes, it means a lot of motivation is needed to kill (or deprecate) something rather than letting it languish. IMO, if we wanted do or die, we'd have to change that culture too. ... best, john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Alternate entry document model
On 10/30/2010 10:39 AM, John C Klensin wrote: If that were to be the case, discussion of maturity levels is basically a waste of time. I think it is. The general public perceives RFCs as RFCs, not equally weighty, but NOT ACCORDING TO ANY FORMAL CRITERIA. We might as well get used to that. Therefore, I'd like to have maturity levels as follows. 1. draft-foo-0: No requirements, not even that it passes idnits. 1b. draft-foo-nonzero: Number of nits should decrease. 2. Final draft: No nits, IPR done, Last Call, archival document, foo-area review, etc. 3. RFC, whether good and weightly, flimsy and ignored, or April joke. Arnt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: what is the problem bis
On Oct 30, 2010, at 4:01 AM, Glen Zorn wrote: The second biggest thing that IETF could do to raise productivity in meetings is to ban Internet use in meetings except for the purpose of remote participation. Harder to do not clearly an improvement: it clear out meeting rooms a bit, but on the other hand people who (for example) just read email in meetings aren't really harming productivity too much. I'm not sure about that. If you're in a room with ten people who are participating in a discussion, it's easy to know whether those ten have achieved consensus among themselves. Also, chances are good that each of those ten people has had a chance to ask questions, voice objections, or otherwise make contributions to the discussion. But if you're in a room with a hundred people (mostly staring at laptops) and only ten active participants, it's much harder to know whether there is consensus in the room. And because there are so many people not obviously doing anything, those who have something to say are more likely to feel inhibited. After all, most people are saying nothing (and not paying much attention), and we humans (okay, most of us) tend to take cues for what is socially acceptable by watching the behavior of those around us. In the early-to-mid 1990s, IETF WG meetings used to be good places to actually discuss concerns about a document, and hash out potential solutions. I remember several occasions when a WG would schedule two meeting sessions in a week, one on Monday and another on late Wednesday or Thursday. The Monday session would discuss the document(s) on the table, identify problems, suggest solutions. Then a couple of WG participants and the authors would sit up late one night and revise the document in time for review at the second meeting (or at least, to be able to report to the second meeting what changes they had made, and get feedback on those). I think it led to much faster convergence than what we usually see now. And often the face-to-face review/revise/review sessions resulted in getting the document in a state where there were only a few nits remaining. I don't think this would work the way we have meetings now, because there's nowhere nearly enough time for discussion. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: what is the problem bis
This discussion has a periodicy about 6 months. The premise is asinine, we can't go back to the early to mid 90s. Joel's widget number 2 On Oct 30, 2010, at 7:34, Keith Moore mo...@network-heretics.com wrote: On Oct 30, 2010, at 4:01 AM, Glen Zorn wrote: The second biggest thing that IETF could do to raise productivity in meetings is to ban Internet use in meetings except for the purpose of remote participation. Harder to do not clearly an improvement: it clear out meeting rooms a bit, but on the other hand people who (for example) just read email in meetings aren't really harming productivity too much. I'm not sure about that. If you're in a room with ten people who are participating in a discussion, it's easy to know whether those ten have achieved consensus among themselves. Also, chances are good that each of those ten people has had a chance to ask questions, voice objections, or otherwise make contributions to the discussion. But if you're in a room with a hundred people (mostly staring at laptops) and only ten active participants, it's much harder to know whether there is consensus in the room. And because there are so many people not obviously doing anything, those who have something to say are more likely to feel inhibited. After all, most people are saying nothing (and not paying much attention), and we humans (okay, most of us) tend to take cues for what is socially acceptable by watching the behavior of those around us. In the early-to-mid 1990s, IETF WG meetings used to be good places to actually discuss concerns about a document, and hash out potential solutions. I remember several occasions.when a WG would schedule two meeting sessions in a week, one on Monday and another on late Wednesday or Thursday. The Monday session would discuss the document(s) on the table, identify problems, suggest solutions. Then a couple of WG participants and the authors would sit up late one night and revise the document in time for review at the second meeting (or at least, to be able to report to the second meeting what changes they had made, and get feedback on those). I think it led to much faster convergence than what we usually see now. And often the face-to-face review/revise/review sessions resulted in getting the document in a state where there were only a few nits remaining. I don't think this would work the way we have meetings now, because there's nowhere nearly enough time for discussion . Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: No single problem... (was Re: what is the problem bis)
I don't think it's resistance to changing a process that we are not following - I think it's which part of the process we think isn't working, or which part is IMPORTANT that isn't working. Going from three steps of which only one step is used, to two steps of which only one step will be used, isn't helpful. It's like the old metaphor of rearranging the deck chairs on the Titanic. It's not the critical problem. And it wastes time/energy from either fixing the leak or getting in lifeboats. -hadriel On Oct 29, 2010, at 9:24 PM, Phillip Hallam-Baker wrote: Well I for one would prefer to call the IESG's bluff than spend five minutes proposing taking HTTP to STANDARD. We are clearly not following the process and have not been doing for ten years. I don't think there is anyone who is even claiming the the process is viable. So why is there so much resistance to changing a process that we are not following? Fear of unspecified bad happenings is not a justification. There are plenty of standards organizations that can manage to do this. If the doomsday people are so worried about the possibility of something bad then we should adopt a process from W3C or ITU or OASIS that is proven to work. So in my view there are two options 1) Adopt Russ's proposal to change the process documentation to reflect reality 2) Admit that we don't understand process and choose a process from some other group. My preference would be for the first option. But if people are really serious in their belief that there could be something really bad from tinkering with this that would argue for #2. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: No single problem... (was Re: what is the problem bis)
Hi Ted, I was with your statements all the way to this: Russ's draft tries to do two things: Restore the 2026 rules for Proposed as the functionally in-use bar for the first rung. ... What makes you say that? I read the draft and I don't see it doing that, really. I know it says: The requirements for Proposed Standard are unchanged; they remain exactly as specified in RFC 2026 [1]. and that in theory 2026's bar for PS was not as high as it appears to be today. So is your expectation that if Russ's draft gets published, the bar for PS will suddenly drop? If so, why do we need Russ's draft to begin with? We already have rfc2026. Why would a new RFC which says follow this other RFC be needed?? Later you say: if the community accepts that this restores the 2026 bar for the first rung *and holds the IESG to it* How do we do that? Why aren't we doing it now, since rfc2026 already exists? In what way does Russ's draft make it any easier (or possible) to hold them to it? -hadriel On Oct 29, 2010, at 7:15 PM, Ted Hardie wrote: As is moderately obvious from the stream of commentary on this thread and there companions, there is no *one* problem at the root of all this. One way to draw this is: Issue: Documents are too slow in achieving the first rung of the standards process Contributing issues: -WG formation is slow, as there are now often 2 BoFs before work begins -Working group activity is slow, as it pulses to physical meetings -Late surprises arrive from late cross-area review (often from teams) or the IESG ---Because there is little early cross-area review after a BoF Resulting issues: ---Little energy remains in working groups to advance documents once they do complete The IESG sees that few documents get early re-review as part of advancement, and raises the document quality requirement for the first rung to prevent impact on the rest of the ecosystem Results of the results: ---Things get slower ---More work is done outside the IETF and brought in only to be blessed ---More of the internet-runs on Internet Drafts. Results of the results of the results: -It's harder to tell which documents are actually the ones you need, both because some actual Standards documents are obsoleted by drafts and because some sets of drafts have functional consensus and some don't. Results of the results of the results: --ADs and others want more tutorial data added to the RFCs, which makes producing them slower. Try to find one place to tug on this and the actual results of your tugging won't really be seen until a full document cycle, and there will be odd states in between. That causes debate and discussion, and worry with all the nice people we've tasked to worry about these things (and many others besides). That burns energy that could be going into working groups and, well, you get the picture (things get slower). Should we do nothing? No. But we need to accept that no single thing we do is going to solve all of the problems. Changing the document labeling will not increase early cross-area review. But if the top-line issue is Documents achieving the first rung of the standards track do so too slowly we may have to tackle it, the WG creation problem, and the WG pulsed activity problem at once to make real progress. If the problem we want to tackle is The first rung is set too high, then there are other possibilities (including simply recognizing that the first rung is really WG draft, marked or unmarked as it may be). I personally don't think that's quite enough, as the value of the IETF (as opposed to its working groups) is that it can and does cross-WG and area review. But I see the attraction--if the first rung goes lower, the documents may be produced faster, which can mean that there is enough energy to go up the track plus the cross-area review is functionally earlier. My worry (yes, I worry) is that if we re-use a label for the first rung after lowering its bar, we create a confusion that we can't easily solve *especially if the energy does not magically appear*. As we stare down this rathole one more time, let's at least be certain that there is more than one rat down there, and be realistic about the energy we have on how many we can tackle. Russ's draft tries to do two things: Restore the 2026 rules for Proposed as the functionally in-use bar for the first rung. Reduce the bar for Standard to the old bar for Draft. Listening to the discussion, I think we have focused a great deal on point two, but have either not really noticed point one or didn't believe it.I think this addresses a marketing problem (long an issue, though now commonly explained away) and it focuses on the first two resulting issues in the quasi-chart
Re: secdir review of draft-ietf-simple-msrp-sessmatch
On Oct 14, 2010, at 4:27 PM, Cullen Jennings wrote: 3) The backwards comparability issue seems huge. Some people have said an endpoint using this draft will not talk with one that only does 4975. Yet if this draft if published as an RFC would basically depreciate the 4975 and replace it with a the result of applying this diff to 4795. So if one person implements the pre update version, and another person the post - it's not clear to me how we migrate from old to new on the existing deployments. A flag day is obviously not going to work. The more I look at this, the more I think this draft needs to be recast as a backwards compatible extension to 4975 and not a draft that update 4975. When I look at how this changes 4975 it seems to mostly relax the existing security but not disallow things that used to work so I think it should be possible to do this. On a side note, I phoned a few people who I know that have MSRP implementation and none of them had any plans to implement this and were surprised to hear there was a draft th at would update in 4975 with a change like this. To me this combined with the no backwards compatibility issue argues strongly for figuring out how to make this an extension instead of a change to MSRP. Who were those people? Everyone I've talked to not only knows about it, but has implementations. (though in most cases implementations of the original acm proposal... they're waiting on an RFC before changing again) Though I will concede my list of vendors to ask this of is by nature going to be prone to doing this, since I talk to folks to interop with and my systems implement acm as well. As for the flag-day issue, in theory yes, I think it would require a flag-day if there were a large population of legacy 4975 trying to talk to a population of this extension. In practice, that hasn't been necessary afaict. The domains that use full app server MSRP relays, a la 4975, have the ability to interwork to an acm-style model in that app server; the domains that don't have such app servers don't have a problem to begin with, since they had to use an acm approach to not need to have app servers. 4) When I search the email lists, I find more more people who see significant problems with this than I find people that seem to think it is OK. I don't think it has consensus -I think it just has people who stopped care. The changes that needed to happen in IETF LC to fix this draft so it had any chance of working at all more or less convinced me the WG did not read this draft. The ietf@ietf.org list is not an ideal location for discussion that rewrites pretty much all of the normative text of this draft (which is what is happening here). I personally stopped caring when implementations of draft-acm showed up and the problem was solved. In some ways this fits in quite nicely with the recent discussion on i...@ietf about taking too long with RFCs and making their bar very high, and people deploying drafts instead. -hadriel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Alternate entry document model (was: Re: IETF processes (was Re: draft-housley-two-maturity-levels))
On Oct 29, 2010, at 10:39 PM, Andrew Sullivan wrote: If all of those things are right and we're actually trying to solve them all, then it seems to me that the answer is indeed to move to _n_ maturity levels of RFC, where _n_ 3 (I propose 1), but that we introduce some new document series (call them TRFC, for Tentative Request For Comment, or whatever) that is the first step. Then we get past the thing that people are optimizing for (everything stays as Proposed Standard once it gets published) by simply eliminating that issue permanently. Ah, you say, but now things will stick at TRFC. Maybe. But we could on purpose make it easier to get TRFC than it is now to get PS (say, by adopting John's limited DISCUSS community for TRFC, or one of the other things discussed in this thread). Also, the argument about everyone thinking that RFCs are standard, and the resulting pressure to make them perfect and permanent, would be explicitly relieved (at least for a while), because nobody thinks that TRFCs are standards. I know how you can get it to approve first: Don't take it to the IESG. Require approval only from the ADs for that area. And don't give them a name that makes them look like some slightly different kind of RFC. Call it blessed draft or something like that. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: what is the problem bis
On Oct 30, 2010, at 10:01 AM, Glen Zorn wrote: The second biggest thing that IETF could do to raise productivity in meetings is to ban Internet use in meetings except for the purpose of remote participation. Harder to do not clearly an improvement: it clear out meeting rooms a bit, but on the other hand people who (for example) just read email in meetings aren't really harming productivity too much. They do by skewing statistics. ADs gauge WG position by the feel of the room. 100 people in the room make it look like there's a lot of interest, when it fact only the document authors and one of the WG chairs have read the drafts. Same for hums. Who knows what drives someone staring at a laptop to hum one way or another? As an example, the IPsecME meeting in Maastricht had over 100 people in the room. Most never looked up from their laptop screens. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Alternate entry document model
I think that there are some issues that are not being mentioned, but which are important. In general, there is the issue of impact. This takes many forms. But the underlying effect is taht protocols which get widely deployed can have distinctly negative impact on the net. Thus, for many years, the requirement for routing protocols which could effect changes to core behavior was that they had to have demonstrated interoperable implementations for PS. This was acknowledged by all involved to be a higher standard than 2026 called for. It was an area rule (going back to about 1992.) On the other hande, there are plenty of things, even in routing, which do not have those kinds of effects and do not need those safety measures. But you can not tell without looking. Similarly, it is important to make sure we check out the congestion behavior of our protocols before we tell folks to go implement them widely. Sometimes this is trivial, sometimes it isn't. But ignoring the question when we are saying this is ready for deployment is not a good thing. One of the positive effects of our current system is taht because WG knows tha tthye have to clear all the ADs, not just their own, they actually think about all these issues. And usually manage to cope with them To give yet another example, I know of one WG that seriously considered publishing an Experimental RFC that flat violated existing standards. The issue was found, and is being addressed. But without cross-area review (the issue was a transport issue for an Internet WG) it is all too easy to miss things. Yes, it would be very good to spot all of these things sooner. I have not yet seen a proposal that actually works for doing so. But letting WGs or WGs + ADs approve documents for general advancement is a step likely to lead to problems. If all our WGs handed their ADs high quality documents that they had checked for all these issues, then maybe we could look at this differently. But LOTs of examples demonstrate taht WGs do not always do this. (Sometimes WGs give their ADs great documents. Sometimes not.) Yours, Joel M. Hslpern On 10/30/2010 12:23 PM, Yoav Nir wrote: On Oct 29, 2010, at 10:39 PM, Andrew Sullivan wrote: If all of those things are right and we're actually trying to solve them all, then it seems to me that the answer is indeed to move to _n_ maturity levels of RFC, where _n_ 3 (I propose 1), but that we introduce some new document series (call them TRFC, for Tentative Request For Comment, or whatever) that is the first step. Then we get past the thing that people are optimizing for (everything stays as Proposed Standard once it gets published) by simply eliminating that issue permanently. Ah, you say, but now things will stick at TRFC. Maybe. But we could on purpose make it easier to get TRFC than it is now to get PS (say, by adopting John's limited DISCUSS community for TRFC, or one of the other things discussed in this thread). Also, the argument about everyone thinking that RFCs are standard, and the resulting pressure to make them perfect and permanent, would be explicitly relieved (at least for a while), because nobody thinks that TRFCs are standards. I know how you can get it to approve first: Don't take it to the IESG. Require approval only from the ADs for that area. And don't give them a name that makes them look like some slightly different kind of RFC. Call it blessed draft or something like that. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels
The waist of the hourglass doesn't need that much work... and in fact a mature system like the internet seems to quite successfully resist change there. joel On 10/27/10 2:48 PM, Bob Braden wrote: Tony, I note that there seems to be some correlation between the degradation of the IETF process and the disappearance of the Internet research community from the IETF (the US government decided that no further RD funding was required, since the Internet was done.) Bob Braden It would work if the overall process were more efficient. Now we effectively go WG I-D to full IS, which is what your eloquent overview of the driving force notes. If we truncated WG I-D at the common points people could agree to start implementing, and have PS actually document the evolution of the implementations, we would get back closer to when the IETF was productive. ... Tony ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: what is the problem bis
This discussion has a periodicy about 6 months. The premise is asinine, we can't go back to the early to mid 90s. What's asinine is to dismiss out-of-hand something has worked well in the past. The only reason we can't change the way we have discussions is that too many people are in the habit of thinking we have to do things the way we are doing them. To anyone with an engineering background, that's not a reason. (and what are the rest of you doing here anyway?) :) We had serious scaling problems with IETF in the late 1990s and we had to adapt because of the huge number of attendees we had. But attendance is way down since then. Powerpoint inhibits thinking. As it's nearly always used, it inhibits discussion. It makes IETF meetings very expensive, because they tremendously lower the value returned in exchange for the money invested to get people there. People who actually want to get work done have less incentive to attend IETF meetings than they used to. So the people who attend IETF meetings these days are less likely to be those with the best technical talent, and more likely to be goers who are just there to tout the company line and/or to watch what other people are doing. The amount of harm caused by IETF's overuse of powerpoint is huge. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: what is the problem bis
On Oct 30, 2010, at 12:38 PM, Joel Jaeggli wrote: the final arbiter of any test in the room is on the mailing list. True. But a room with a high ratio of active participants to total attendees makes a much better sounding board for providing constructive feedback, than a room with a low ratio. You get convergence on a sound proposal more quickly if you can get good feedback from face to face meetings. And (provided the attendees at such meetings represent a decent cross-section of interests), proposals that have enjoyed such feedback are more likely to be enthusiastically accepted by a mailing list. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Full-disclosure] IPv6 security myths
I would be quite curious to know your definition of failure, given that IPsec is currently deployed, and working in more than a few deployments ... On a possibly related note, IPv6 use deployed and working too ... /TJ On Oct 27, 2010 12:08 PM, Masataka Ohta mo...@necom830.hpcl.titech.ac.jp wrote: Steven Bellovin wrote: The core issue was indeed that IPsec was mandated for v6. We were *very* overoptimistic about how long it would take before roll-out started in earnest. In fact, we underestimated how long it would take to get good specs for all the important pieces. We also underestimated how long IPsec would take, though that was partially (but only partially) because IPsec version 1 (RFCs 1825-1829) had to be thrown away. Quite simply, it is merely that IPsec had totally failed long before IPv6 totally failed. FYI, total failure of IPsec is not the only reason of total failure of IPv6. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [Full-disclosure] IPv6 security myths
TJ [trej...@gmail.com] wrote: I would be quite curious to know your definition of failure, given that IPsec is currently deployed, and working in more than a few deployments On a possibly related note, IPv6 use deployed and working too ... Failure means that, I leave in the capital city of California and I can't find a single ISP that offers native IPv6. We're in the end of 2010. And no change in sight. Tunnels? Oh yes tunnels. I had that 10 years ago. You call that deployed? Michel. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels
It should be easier to get a specification to IETF standard than to start an alternative standards organization. I think that is still true and tried to convince the OpenID people that this was the case but they did not believe me. The question is priorities and costs. Having a process that is designed not to function imposes real costs and reduces the influence of the organization. On Sat, Oct 30, 2010 at 2:09 PM, Joel Jaeggli joe...@bogus.com wrote: The waist of the hourglass doesn't need that much work... and in fact a mature system like the internet seems to quite successfully resist change there. joel On 10/27/10 2:48 PM, Bob Braden wrote: Tony, I note that there seems to be some correlation between the degradation of the IETF process and the disappearance of the Internet research community from the IETF (the US government decided that no further RD funding was required, since the Internet was done.) Bob Braden It would work if the overall process were more efficient. Now we effectively go WG I-D to full IS, which is what your eloquent overview of the driving force notes. If we truncated WG I-D at the common points people could agree to start implementing, and have PS actually document the evolution of the implementations, we would get back closer to when the IETF was productive. ... Tony ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Website: http://hallambaker.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Full-disclosure] IPv6 security myths
TJ wrote: I would be quite curious to know your definition of failure, given that IPsec is currently deployed, and working in more than a few deployments ... Sorry for lack of clarification. My context is IPsec in the Internet, which excludes VPNs. Do you know some major application over the Internet using IPsec with transport mode? Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
