Re: Subscriber List Damage
1) Have you brought this up with the mailman folks? I've interacted with them and they seem like a responsive set of folks. I'm sure that this sort of thing would horrify them. 2) 3 years since the last backup? Oi. Mike Glen wrote: All - I was asked by the IAOC to post a message to the IETF and SIP lists, to ensure that people were aware that the subscriber lists for the IETF and SIP lists were damaged as a result of an anomaly in TMDA and Mailman that occurred Thursday night. Basically, TMDA misbehaved, and, in the process, caused Mailman to encounter a transient failure in the reading of its databases for these two lists. As a result, rather than simply holding the mail and retrying it, Mailman decided to discard the current list databases and re-create them from 3-year-old data, for both the IETF and the SIP lists. *sigh* No email was lost to the system or the archives; however, some people may have missed some messages, or may still not be resubscribed to the list. Of course we restored the files from backups; however, we want to make sure that everyone gets the mail they missed, and that everyone is subscribed to these lists who wishes to be subscribed. So... If you're reading this message in your email box, you're subscribed to the list identified in the subject line, and all should be okay. If you're reading this message in the archives, wondering why you're not getting list mail, please take a moment to resubscribe yourself to the list, which should resolve your problem. And regardless, if you feel you missed any mail, we do have the archives available for your reference. IETF List Subscription Link: https://www.ietf.org/mailman/listinfo/ietf IETF List Archive Link: http://www.ietf.org/mail-archive/web/ietf/ SIP List Subscription Link: https://www.ietf.org/mailman/listinfo/sip SIP List Archive Link: http://www.ietf.org/mail-archive/web/sip/ We are in the home stretch of getting TMDA removed and replaced on the servers, and I apologize for any inconvenience caused by this issue. Because server problems apparently happen only in the dead of night, you can be sure that we feel any and all pain anyone may be experiencing. If you need any assistance, please contact the IETF Secretariat, using the links at: http://www.ietf.org/secretariat/ Thank you, Glen Barney IT Director AMS (IETF Secretariat) ___ 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: WG Review: NETCONF Data Modeling Language (netmod)
Andy Bierman wrote: > I don't think a formal WG process is needed to determine that > the strongest consensus exists for the approach currently outlined > in the charter. The 15 people on the design team represented > a wide cross section of those actually interested in this work. > I am among the 10 - 15 people who were not involved in the design team, > but agree with the charter. That seems like a lot of consensus > for this technical approach. > > There seems to be a repeating pattern here where a large cross section of interested people manage to either mostly hash out their differences or are committed to grin and bear whatever the consensus is only to be thwarted by a small set of (self) appointed Internet Earls with little or no stake in the game. The IETF should be fostering getting that upfront ego-deflation, etc, done ahead of working group formation, IMO, as it makes for functional rather than dysfunctional working groups. But as it stands right now, those Internet Earls pretty much have veto power through extremely vague "We are not pleased" proclamations which the would-be working group has no means of clearing except for throwing open the entire can of worms again (and again and again). This really sucks and is extremely demoralizing to those who have invested more than a reasonable amount of time on the work. What's even worse is that all the exercise does is create delay since there was nothing actionable about the Proclamation in the first place. Mike, knitting ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [dkim unverified] Re: IESG Statement on Spam Control on IETF Mailing Lists
Eliot Lear wrote: > Russ, > > >> When IETF lists are housed somewhere other than ietf.org, they are >> supposed to include an archive recipient so that there is an archive >> available at ietf.org (perhaps in addition to the one kept at the >> place where the list is housed). >> >> > > I'll agree with Phill's conclusion on this one. > > I think there is probably convenience value to housing the mailing lists > at the IETF. It allows for a single whitelist, reduction in those > annoying monthly messages that we eventually all filter into the > bitbucket. Also, it probably is easier to effect and audit policy > (such as we have any) in terms of message retention, uniform access, etc. > The other things is when we start DKIM signing (HINT HINT), it will give a single identity for reputation, etc to latch onto. Mike ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Blue Sheet Change Proposal
Eric Rescorla wrote: > At Thu, 3 Apr 2008 20:10:12 -0400 (EDT), > Scott O. Bradner wrote: > >> Ole guessed >> >>> My understanding is that the blue sheet serves mainly as a record of >>> "who was in the room" which I think is largely used to plan room >>> capacities for the next meeting. >>> >> the "blue sheets" are required as part of the basic openness >> process in a standards organization - there is a need to know >> "who is in the room" (see RFC 2418 section 3.1 for the actual >> requirement) >> >> the blue sheets become part of the formal record of the standards >> process and can be retrieved if needed (e.g. in a lawsuit) but are not >> generally made available >> >> as pointed out by Mark Andrews - email addresses can be useful in >> determining the actual identity of the person who scrawled their >> name on the sheet - so it is an advantage to retain them >> >> I'm trying to understand how the blue sheets contribute in any >> significant way to the spam problem - someone whould have to be >> surreptitiously copying them or quickly writing down the email >> addresses - both could happen but do not seem to be all that >> likely there are far more efficient ways to grab email addresses >> >> so, my question is "is this a problem that needs solving"? >> > > The only reason I've heard is that some claim that people don't > write their names on the blue sheets out of concern over spam. > This doesn't seem very reasonable to me... if you post on any public list -- like this one -- your likelihood for harvest is far, far higher. Let's face it, in 2008 trying to have "private" email addresses as a spam defense strategy is oh so 1998. Mike ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Possible RFC 3683 PR-action
Noel Chiappa wrote: > > From: Michael Thomas <[EMAIL PROTECTED]> > > > So I've never met you, Noel. And I certainly don't have any reason to > > believe that this email I'm responding to wasn't forged. > > (Responding to the point of your message, rather than the actual words... :-) > > I think there are two parts to the problem: the first is "does this electronic > identity correspond to a real person", and "how can that electronic identity > securely post messages". (I assume that was your point, yes?) > > As to the first, something like a PGPmail web of trust would work. E.g. you've > never met me, but you probably have met Dino or TLi, and they have met me, and > can confirm (in both directions) that we're real. > > As to the second, well, basic email isn't terribly secure (alas); however, > there are a number of heuristics. First, for any list I'm on, I will > certainly notice if a fake "jnc" starts posting! And you can look at the > Received-from: headers to make sure the email came from where it says it came > from. And it's easy enough to track me down and call me on the phone (again, > people you know can verify that the phone number is real). Etc, etc... > The point that I was trying to make is exactly that this is all rather squishy as you I'm sure agree with. Given the squishy nature of this, it seems rather difficult to try to enforce broad authorizations (= anonymity vs. consensus in this particular case). I'm not even sure I understand what "anonymity" means in that particular context... that I can't google the email address and get enough confirming evidence of non-doghood? I suspect that if we ever tried to codify this sort of stricture, we'd soon wish we hadn't. Mike, could be a dog too ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Possible RFC 3683 PR-action
Noel Chiappa wrote: > > From: Peter Constable <[EMAIL PROTECTED]> > > > Frankly, it strikes me as somewhat odd that a body acting as a > > standards-setting organization with public impact might allow any > > technical decision on its specifications to be driven by people > > operating under a cloak of anonymity. Expressing an anonymous > > [criticism]? No problem. Influencing determination of a consensus with > > public impact? That should not be allowed, IMO. > > Excellent point. > > So I've never met you, Noel. And I certainly don't have any reason to believe that this email I'm responding to wasn't forged. How do I know that you're not a dog? Mike ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IONs & discuss criteria
Dave Crocker wrote: > Mostly, we agree on these points. Handled properly, placing review items in > an > issues list can be helpful to all parties, as long as each issue is clearly > stated and possible resolutions or constructive guidance are included. > > One caveat: Sometimes it is the aggregate review that is most significant > and > breaking it into constituent 'issues' loses the broader concerns. > I can't imagine dealing with something even vaguely contentious without the issue tracker. However as I've seen it used, there's a fair amount of power in being able to declare on a wg list that something is an ISSUE that needs to be tracked. In particular, I've seen a lot of cycles expended on 'issues' that clearly have little or no following. It can be pretty time consuming and disruptive. Maybe we need some better gating functions to the issue tracker, but it would have to be careful to not squash comments/issues from left field (ie, from cross-area, disinterested, etc) with some crushing new process. Mike ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: a thanks to the Gen-ART reviewers
Andrew Newton wrote:
> To Eric, Spencer, and all the other Gen-ART reviewers: Thank you.
>
> My experience with Gen-ART reviews has been very positive, and I
> appreciate your work and effort. I realize you weren't seeking public
> praise, but your volunteer contribution to the good of the IETF should
> be recognized.
>
I have to say that I really like these and the cross area reviews a lot. As
an author/editor having to digest zillions of posts on the lists mixed with
time and entropy, it gets really hard to look at the draft with the
critical eye
of somebody who might have to actually try to make sense of it. Not to
mention trying to determine what the draft says versus the lore that's
built up around it.
If I could make a suggestion, what might really be useful as well is
collecting
implementation notes, and especially what throws people off when coding
up the draft, or implements things in new and unintended ways. Unintended
can sometimes be very cool, but often it's that the draft isn't
sufficiently
precise.
Mike, who tries to do this but given a cookie cutter form
might do better
> On Mar 7, 2008, at 2:45 PM, Eric Gray wrote:
>
>> Minimally, as one of the people to whom that has happened, it would be
>> nice if at least an initial ("thanks for the review and comments")
>> mail
>> included the commenter, in every case. Even a "I wish you would stop
>> bothering us with all of these silly comments" would be a response.
>> Of course, I presonally would prefer that that sort of response was
>> not
>> addressed to the list, with or without me on it. :-)
>>
>
> ___
> 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: Transition status (was Re: ISO 3166 mandatory?)
My $.02 -- the new list software being used was using a new version of Mailman that was stripping DKIM signatures out (which will be fixed in later versions of Mailman). I contacted the support folks with a config patch to stop doing that and it was implemented a day later. I'd say that's pretty damn impressive. Mike Dave Crocker wrote: > Bill Fenner wrote: > >> On 2/20/08, John C Klensin <[EMAIL PROTECTED]> wrote: >> >>> How much more of this will it take before you conclude that we >>> have a problem? >>> >> John, >> >> Forgive me for saying so, but this sounds like a very extreme >> response to me. (Unless the expected answer is "A lot") >> > > > > Since a) I'm a ready critic of anything IETF, and b) since John and I have > tended to agree about IETF operational problems, here's my own view on the > current status of the transition: > > Seems to be going pretty well and maybe even excellent. > > (My grammar engine tried to write 'excellently' but failed.) > > We flogged the issue of the strategic approach to changing IETF operations, > back > when it was moved from CNRI. While I thought, and think, that the strategic > issues were handled badly by the IETF -- no matter what criticisms of CNRI > one > might subscribe to -- that ship has long sailed, so current -- hmmm. pun. > current. get it? -- concerns ought to focus on current operations. > > I was taught a long time ago to use a different model for operations quality > assessment than for engineering quality assessment. The difference is due to > the > jobs having different types and degree of control over output, as well as > tending to have differences in rewards. Engineers are usually praised with > praise. Operations (and especially administration) is usually "praised" by a > low complaint rate. It is easy to appreciate good engineering. All too often, > folks fail to communicate appreciation of good operations, but I think the > IETF > community has been better than average in expressing appreciation of IETF > operations staff. > > The cost of making a transition like this be nearly flawless would be very > high > and the sequence would be very slow, since it would include massive amounts > of > pre-testing and careful, iterative consultation with IETF management and/or > the > IETF community. The IETF doesn't run on that kind of budget or schedule, so > my > own criteria for a transition like this are: 1) is a problem due to > someone's > outright thoughtlessness or silliness, or 2) is the recovery from a > transition > problem handled badly -- for any reasonable definition of badly. > > I would not expect inherited tools to have been documented well or written > for > optimal portability. So I'd expect the tools to present some challenges. > Equally, I'd expect new staff to demonstrate a learning curve, and that means > rough edges. Given that this is the IETF's second change in operations > administration in a very short time, I'd expect the current transition to be > particularly difficult. > > The number, type and rate of transition problems hasn't struck me as all that > remarkable. Maybe low; maybe not. Certainly hasn't seemed high. To me, it > is > more important to ask how the problems that have occurred have been handled, > and > the handling has seemed quite good, both in the details and the tone. Fixed > quickly and with whatever adjustments as are needed to minimize damage -- as > opposed to inconvenience -- to those affected in the IETF community. > > If there are specific, higher-level changes to the transition or to basic > operations that ought to occur, we probably ought to see them raised > individually. > > d/ > ___ IETF mailing list IETF@ietf.org http://www.ietf.org/mailman/listinfo/ietf
Re: [dkim unverified] Re: I-D Action:draft-rosenberg-internet-waist-hourglass-00.txt]
Jonathan Rosenberg wrote: > >> More heresy: maybe we should work on hacks to TCP to allow it to >> have non-reliable e2e delivery so that it was more friendly to real time >> protocols built on top of it. > > As you probably know folks absolutely have done this for exactly the > reason you cite. No actually, I didn't know that... is this some kernel specific hacks to deal with the head of line blocking problem? Or something else entirely? Mike ___ Ietf mailing list Ietf@ietf.org http://www.ietf.org/mailman/listinfo/ietf
Re: [dkim unverified] Re: I-D Action:draft-rosenberg-internet-waist-hourglass-00.txt]
Jonathan Rosenberg wrote: > Harald Tveit Alvestrand wrote: > >> While I disagree with Jonathan's assertion that we should insert an >> entirely useless (for all but NAT) UDP header in front of all new >> protocols we design, >> > > Well, I'd hardly characterize, "allowing it to work across the public > Internet" as a property that is useless. Statements like, "useless for > all but NAT" trivialize what the Internet has evolved into. There is NAT > everywhere. Lets accept it and design for what the Internet is, and not > for the Internet as we wish it would be. > > You may not like it, but its reality. > Well, if we're talking about reality, why don't we talk about UDP? UDP is an imperfect fit for NAT's and firewalls because it's stateless and the stateful ALG needs to educe state from those packets. If it's an protocol riding on top of UDP, the ALG is bound to get it wrong at times. Which as far as I've heard happens all the time. As in, UDP is no panacea. If you really want to put a stake in the ground here, it seems to me that TCP is on a lot firmer ground. Why else would a lot of these IM protocols and things like Skype use TCP fallback? It's because it's the only thing that reliably works and they're not in the business of navel gazing about whether they shouldn't do that because of its architectural ugliness. More heresy: maybe we should work on hacks to TCP to allow it to have non-reliable e2e delivery so that it was more friendly to real time protocols built on top of it. Mike ___ Ietf mailing list Ietf@ietf.org http://www.ietf.org/mailman/listinfo/ietf
dkim sign ietf lists
Lucy Lynch wrote: As an old multicast warrior and a long time NOC volunteer I'd point out that we've been eating our own dog food for years. The world didn't end and the network never melted completely ;-). All the fine folks involved in *hard* technologies like DNSSEC, DKIM, mobility, multicast, new routing solutions, etc. should be following this discussion with a mixture of dread and befuddlement. I'm not sure I'd say DKIM is a "hard technology" but... what would it take to get all of the IETF lists signing with DKIM? How can I help? Mike ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Spammers answering TMDA Queries
Keith Moore wrote: the problem I have with DKIM filtering is that it is only effective for domains that can reasonably insist that all of the mail originated by users at that domain go through that domain's submission servers. this is a corner case, not the general case. Back in the day, we didn't have any of this VeePeeEn tomfoolery. I could just telnet in and that was that. I'm sure that our IT folks paid dearly in time, equipment, and support to throw up that wall, yet they did it and as far as I can tell we all survived the move. I don't see anything especially different with mail: if you want accountability, you have to do real live work -- part of which is placing restrictions on access. TANSTAAFL. what you are failing to see is just how much reliance on VPNs (and source IPs) to do authentication cripples the network. sure it's better than nothing, but it's also very inflexible and an architectural dead end. C'est la guerre. In fact, I'm well aware of all of those things, and I'll even allow that our IT folks were probably aware of all of those things too -- they undoubtedly took a lot of flak from the Eldar who probably said the same thing. I'm also pretty sure that they would dismiss anybody who told them to tear out their VPN gear because it cripples the network and is an architectural dead. Same goes for email. sure the spammers will learn to not use DKIM domains, but they'll just move to other domains, This is a feature, not a bug: I don't have to outrun the bear, I just need to outrun you. I'll remind you that as a condition to working in IETF we are all pledged to use our judgment as to what's best for the Internet as a whole...not just for those who can run faster than others. I guess I must have been in the bar when they had that pledge of allegiance. But even allowing that there is any such pledge, to the degree that we enable domains to control who uses their name and be accountable when they behave badly is certainly a net good thing IMO. Your original makes it sound like there's some inherent right to be heard. There isn't. If you don't want to be accountable, then maybe I just don't want to bother sorting your wheat from chaff. Mike ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Spammers answering TMDA Queries
Keith Moore wrote: the problem I have with DKIM filtering is that it is only effective for domains that can reasonably insist that all of the mail originated by users at that domain go through that domain's submission servers. this is a corner case, not the general case. Back in the day, we didn't have any of this VeePeeEn tomfoolery. I could just telnet in and that was that. I'm sure that our IT folks paid dearly in time, equipment, and support to throw up that wall, yet they did it and as far as I can tell we all survived the move. I don't see anything especially different with mail: if you want accountability, you have to do real live work -- part of which is placing restrictions on access. TANSTAAFL. sure the spammers will learn to not use DKIM domains, but they'll just move to other domains, This is a feature, not a bug: I don't have to outrun the bear, I just need to outrun you. Mike ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Spammers answering TMDA Queries
Brian E Carpenter wrote: Speaking personally, I think annual reconfirmation is quite reasonable. The message sent to the user should make it clear that it is an annual process. Except... the annual confirmation is probably going to get accidentally deleted by a lot of people because they think it's the monthly notice. If this is a real problem, wouldn't it be better to take it up with the mailman folks since I'd expect that it's not just ietf? I've been working with them on dkim related stuff and they are quite reasonable folks. Maybe they have some ideas on this front. Mike ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Spammers answering TMDA Queries
Paul Hoffman wrote: At 6:49 PM -0400 10/2/07, Russ Housley wrote: 1025 mail addresses have "confirmed" their address. I would bet that at least 20% of the confirmed are spam addresses (or autoconfirmed addresses) Thoughts? How was that 20% number guessed at?. If 200 spammers (or even 20!) were on the TDMA list, we should be seeing tons of spam on the lists; so far, we are not. Maybe they're just harvesting addresses? Mike ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: ideas getting shot down
Keith Moore wrote: Paul Vixie wrote: which is why i'm proposing a standard of "demonstrable immediate harm" rather than the current system of "that's not how you should do it" or "that's not how i would do it". That's the wrong standard, it sets the bar way too low. IETF shouldn't endorse anything unless it has justification to believe it is good; IETF should not discourage anything unless it has justification to believe it is bad. And that justification should come from engineering analysis (or measurement, if it's feasible). Sadly, a lot of people in IETF do not have engineering backgrounds and don't understand how to do such analysis. This is something we need to change in our culture. Feh, that seems awfully self-important to me (where "self" == "ietf"). "The IETF" (putting aside that it isn't a hive mind) isn't the ultimate arbiter of good and bad, or useful/useless. Often there is utility to the notion of "if you're doing to do this questionable thing, at least do this questionable thing consistently". What you're advocating toes the best is the enemy of the good line. Nothing would make the IETF irrelevant faster than crossing that line. Mike ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Symptoms vs. Causes
Christian Huitema wrote: There are a large number of protocol designs--even existing protocols--which are compatible with the general paradigm of "user U proves possession of password P to server A without giving A a credential which can be used to impersonate U to server B". HTTP Digest, TLS-PSK, SRP, and PwdHash all come to mind. The difficult parts are: (1) putting a sensible UI on it--including one that isn't easily spoofed (see the extensive literature on how hard it is to build a secure UI. (2) Getting everyone to agree on one protocol. Please add: (3) The chosen solution is immune to dictionary attacks. Well if we're going here then: (4) The chosen solution requires that I have to remember zero or fewer non-dictionary passwords Mike ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: DNS as 1980s technology [was Re: The Internet 2.0 box Was: IPv6 addresses really are scarce after all]
Roger Jørgensen wrote: On 8/24/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: No reason to attack him like you did and I specifically want to address this because mailing lists have a much larger audience than their participants. If such attacks are not answered it creates barriers for new blood to enter into the IETF process. Please don't do this. A wild guess from my side, I think quite some fresh blood are scared of by the path they have to follow to get through with their ideas or thoughts. Not so much the way their questions are answered but it certainly don´t help to be bitched at either:) IMO, there is almost no point days of trying to engineer a protocol in the IETF that doesn't have some real world grounding ahead of time. At the very least, it shows that somebody(s) have made more of a commitment than just getting another RFC number on their resume. This also neatly routes around the damage of being shouted down while an idea is in its infancy, and spares the ridicule if it really was a bond-headed idea since you can abandon it instead of taking it to IETF. No such escape valve exists for ungrounded/untested protocols, unfortunately. I wonder what percentage of RFC's are stillborn these days. Mike ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Review of draft-hartman-webauth-phishing-05
Sam Hartman wrote: Ah. I must admit that I find the whole concept of informational documents a heck of a lot less useful, but your reading of 2026 is of course correct. I'll probably still end up treating informational documents as close to ietf consensus statements (but not recommendations) in my head because honestly I cannot find any other way to think about it that makes any sense to me. I certainly view an informational docmuent that has gone through an ietf last call as a statement from the IETF. We'll add this to one of the many areas where I completely fail to get RFC 2026. I definitely don't want to block other work with this document. I think that to be particularly useful I'd like to get to a point where we can say that having authentication schemes that meet these requirements would be useful and that for some value of we significantly greater than me, we think that would be a useful step along the road to combatting phishing. I thought I was trying to have that discussion here; you at least seem to think that is not the case. At some future point we might charter work with the goal of doing something similar to those requirements; in such a case, we might decide to hold that work to these requirements. We're not discussing doing that today. If I believe there is a reasonable chance of success I'm willing to put in significant effort towards achieving my goal. Absent that belief I'm more interested in getting something out and working on running code. So, Here is a proposed IESG note that I think is consistent with my intent and RFC 2026: This document proposes requirements for HTTP authentication that are intended to help combat the problem of phishing. These requirements attempt to reduce the consequences of a user being tricked into using a server provided by an attacker instead of the server they intended to trust. These requirements have no normative force; publication of these requirements does not bind future work to follow them. Sam, I guess the question I have is why an individual submission is actually the right vehicle for this sort of document. From the outside -- though pretty interested in the phishing problem -- I'd think that a more community consensus type of document with more teeth (ie, some normative force) would be a Good Thing if consensus could be found. I read quite a few of these comments as being more of the nature that there wasn't a very good forum to shape the content. I can sympathize with the notion that comments on IETF list during last call for a document as important and likely controversial is insufficient. This list is noisy enough after all. Mike ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
requirement documents
Henning Schulzrinne wrote: Part of the problem may be historical: Requirement documents are a relatively recent phenomena and likely postdate 2026. I suspect the original intent of informational documents was to document non-IETF protocols for the benefit of implementors, as well as record various other non-standards items such as April 1 poetry or workshop results, where it is pretty clear that this is the opinion of the author or some definable group, such as the IAB. On the other hand, I have yet to see working group-issued requirements documents being used for anything except shadow boxing (and, occasionally, recording some early WG thinking), so maybe we shouldn't take them too seriously. I have a less jaded view of requirement documents than Henning, but I suppose I should since I've written a couple. They can certainly function as Henning says, but for the last one I took on writing, the situation was pretty dire: endless email threads, people talking past each other, complete non-clarity on what the end goals -- and challenges -- really were, etc, etc. If you add on top of that egos attached to concrete drafts which are often not at all apparent what problems _they're_ trying to solve, it makes it nearly impossible to even know what people even disagree on, let alone agree on. For that kind of situation, biting the bullet seems like a sensible way forward. It's a pretty thankless job in many ways though in those situations: wading through endless threads trying to make some sense of the cacophony is not much fun. Yet it did settle things down to a great extent, even if it was mainly from sheer exhaustion. Mike ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: e2e
Keith Moore wrote: I have no problem breaking bounce/redirect. Yes, it has its uses, but so do open relays, which we don't have anymore. The current levels of mail abuse means that it's necessary to throw away a little baby with the bathwater to keep the toxic waste out of the bath. sorry, this is a nonstarter. being able to set a forwarding address is extremely important, and breaking Sender is indefensible. (Sender is useless unless it preserves the original identity of who or what sent the message.) Yet, mangling forwarders which break signatures -- like this list -- are indistinguishable from every day forgery. I agree that destroying mailing list functionality is unacceptable, but we shouldn't kid ourselves that there aren't unintended consequences from the original everybody- trusts-each-other-group-hug assumptions present in the design. Mike ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: e2e
Fred Baker wrote: What we need to do is figure out how to let the intelligent network core work cooperatively with the intelligent edge to let it do intelligent things. Right now, the core and the edge are ships in the night, passing and occasionally bumping into each other. Isn't that the essence of the problem though? That is, signaling between trust domains is an inherently difficult thing to scale up? It seems to me that even setting up static relationships within a semi-trusted domain is pretty hard (say, so-called "Voice lans" or suchlike), but managing the complexity of signaling just makes the eyes of operators to glaze over. When I wrote that draft on rsvp vs. mobility vs. security ages ago, it quickly became obvious that the combinatorics get quickly out of hand, and that draft was just about the _theory_ of doing such a thing; gawd help what the actual real life complexity is with different vendors, buggy software, people trying to game such a system, etc, etc. Out of it I came away with new appreciation for the power of Brute Force, and Ignorance with respect to just throwing bandwidth at the problem. So I guess I have to wonder whether ships in the night is such a bad thing. One thing we do know is that reality has a tendency to distort and magnify warts, even with seemingly "simple" applications. As you add edge "tussles", the complexity seems to go through the roof. Maybe these kinds of things can be done in small, centrally marshaled deployments, but for the whole internet? Mike, not advocating end-complexity-as-faith either ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: New models for email (Re: e2e)
Hallam-Baker, Phillip wrote: I have a slightly different take from John here. My strong belief is that a proposal for a new protocol that does the same thing as SMTP but slightly better is a total non starter. No matter how much better the protocol is the cost of transition will dominate. The only way that I see a new email infrastructure emerging is as a part of a more general infrastructure to support multi-modal communication, both synchronous and asynchronous, bilateral and multilateral, Instant Messaging, email, voice, video, network news all combined in one unified protocol. You mean SIP? Mike ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: e2e
Keith Moore wrote: this is not a way to make the network more robust. Robust for what? Spammers? The simple fact of the matter is that the alternative is to just shut down port 25 given the growth in both volume and complexity to filter. That ain't robust either. Dealing with false positives is the cost of doing business on the internet these days. Welcome to reality. people who cite "reality" generally do so because they lack justification for their statements. The thing is, Keith, I don't lack justification. I've seen the numbers with my own eyes in our own largish organization with an IT staff that's super paranoid about about false positives (free clue: guess who some of our customers undoubtedly are?) find a way to make reputation servers accountable to both sender and recipient, then we can talk about robustness. until then, they're just another form of DoS attack. Attacking people in the field as "DoS attackers" who are just trying to get by given the escalating onslaught is... something. In that Cluepon short of a Happy Meal kind of way. Mike ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: e2e
Keith Moore wrote: The communication system isn't being a filter, properly speaking - it is simply routing some traffic to black holes using standard routing technology. And it doesn't relieve the application of the burden of filtering. But it can help reduce the volume of crapola at the application. ...at the cost of dropping legitimate traffic. the thing is, the set of valid senders for you and the set of valid senders for everyone at cisco is very different, and the latter set is much fuzzier. and those reputation services won't take responsibility for the mail that you lose by trusting them, nor are they accountable to the senders either. this is not a way to make the network more robust. Robust for what? Spammers? The simple fact of the matter is that the alternative is to just shut down port 25 given the growth in both volume and complexity to filter. That ain't robust either. Dealing with false positives is the cost of doing business on the internet these days. Welcome to reality. Mike ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Do you want to have more meetings outside US ?
Would it really be so horrible to, say, have a per day rate? I know that
there
are a lot of people who are only interested in one or two wg meetings and
would just assume go home instead of hanging around, kibbutzing in wg's
that you're only peripherally involved, etc. That in and of itself may help
improve the SNR...
Mike
Edward Lewis wrote:
At 15:51 -0400 7/30/07, Matt Pounsett wrote:
I was talking to a couple of people this week about what I consider
to be a
related issue: the fact that for the two or three wg meetings I'm
interested
in, there's little point in me being at the meeting for a whole week.
I can relate, I left Chicago on Tuesday.
What about holding two or three meetings smaller meetings a year for
each
area, and then just one big meeting for the full IETF? That would bring
down the cost of the individual area meetings and therefore the
admission
fee, make them smaller and therefore capable of fitting into a wider
range
of hotels, and would likely result in fewer nights of hotel stay for
a lot
of people.
This idea has been tossed around before. The rationale for
maintaining large meetings, all under "one roof" has been to maintain
coherency across all of the areas. I was told that there have been
times in some other standards bodies where one area will develop a
standard that is completely incompatible with a standard developed by
another area. ("I was told" meaning that I have forgotten all the
particulars of the story by now.) While all we should need is the
IESG to be present together, by the time you count up the areas and
weeks in a year and the ability of the IESG to travel...we just keep
up having our large conventions.
Take a look at this for an extreme counter example:
http://www.itu.int/events/monthlyagenda.asp?lang=en
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
Re: Updating the rules?
Robert Sayre wrote: Also from the draft: "At least for the strong security requirement of BCP 61 [RFC3365], the Security Area, with the support of the IESG, has insisted that all specifications include at least one mandatory-to-implement strong security mechanism to guarantee universal interoperability." I do not think this is a factual statement, at least when it comes to HTTP, which is where my interest lies. [...] On the other hand, I've seen with SIP where forcing the working group to do this has been extremely counter productive. The reason is that since it was backend loaded, ramming in S/MIME and TLS was rife with mistakes and in the case of S/MIME was a solution in search of a problem. Since we're talking about how things actually turn out from process, it would be good to acknowledge that the process in this particular case was ultimately counter productive: instead of taking the time to get security right, we institutionalized incorrect/non-interoperable behavior. I seriously doubt that SIP is the only offender here as general clue as to how to do this right is still arguably lacking, and it most certainly doesn't get done in a fevered month before last call. IMO, the process needs to take into account the reality of when we are trying to graft security protocols onto implemented/deployed protocols like SIP, SMTP... It's an effort unto itself and needs to be carefully considered, and hopefully by a group of people whose goal is to make something that's _useful_ and _interoperable_ rather than just squeaking through the IESG mandated process. Mike ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Should I* opinions be afforded a special status? (Re: [saag] Declining the ifare bof for Chicago)
Brian E Carpenter wrote: On 2007-06-27 17:42, Michael Thomas wrote: Brian E Carpenter wrote: One thing that would make a significant difference would be if WGs really took responsibility for their own quality control. Even at the trivial level, the IESG still gets drafts that don't pass ID-nits (but that is getting better, thanks to PROTO shepherding). But maybe we should be pushing harder to make WGs responsible for getting final external reviews done (and responded to). That would just be more delegation along the path that's been followed for the last several years. Part of the problem with cross area review is that there's such a flood of documents that it's pretty impossible to know unless somebody tells/asks you to review it that you should care. Indeed. The current reviews such as Gen-ART and secdir reviews don't just happen spontaneously; specific reviewers are triggered by a "dispatcher." As I said, I'm a little skeptical about "expert review", but for so-called experts as well as the laity in other areas, it might be nice to have some indexing when it touches areas which are known to contain land mines. We also need reviewers to look for land mines in unexpected places. We already do this to some degree with Security Considerations, but they often read as a "Full Disclosure" part of a contract rather than the basis of how operation security is intended in the draft itself. What might be nice is to have some cross domain Cliff's Notes capturing the jist of how this draft uses or affects other areas? So that people in other areas can determine more easily if something whacky might be going on and pique their interest in reading it? Were this done sooner in the process rather than later, we well might be able to nip more whackiness before it bubbles all the way up to the IESG. It sounds like that would be done before passing the document on for AD review. Is that your idea? Yes -- well before. Maybe something something along the lines of what it builds on, might impact, might be applicable to, etc. The problem that I see is that there a fair amount of beg, borrowing and stealing (good) and that is often done without the keepers of those things knowledge until pretty late in the game (bad). Take DNS for example since it's a favorite franken-building block. Would anybody in the namedropper crowd be likely to know if, say, the routing crowd was using DNS in some new way? Probably not. If, however, we had a dashboard which named out the cross-area dependencies in, oh say, the area section or the working group page or somewhere like that it would at _least_ give you a clue that there might be something interesting to look at in an area you normally pay no attention to. Mike ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Should I* opinions be afforded a special status? (Re: [saag] Declining the ifare bof for Chicago)
Brian E Carpenter wrote: One thing that would make a significant difference would be if WGs really took responsibility for their own quality control. Even at the trivial level, the IESG still gets drafts that don't pass ID-nits (but that is getting better, thanks to PROTO shepherding). But maybe we should be pushing harder to make WGs responsible for getting final external reviews done (and responded to). That would just be more delegation along the path that's been followed for the last several years. Part of the problem with cross area review is that there's such a flood of documents that it's pretty impossible to know unless somebody tells/asks you to review it that you should care. As I said, I'm a little skeptical about "expert review", but for so-called experts as well as the laity in other areas, it might be nice to have some indexing when it touches areas which are known to contain land mines. We already do this to some degree with Security Considerations, but they often read as a "Full Disclosure" part of a contract rather than the basis of how operation security is intended in the draft itself. What might be nice is to have some cross domain Cliff's Notes capturing the jist of how this draft uses or affects other areas? So that people in other areas can determine more easily if something whacky might be going on and pique their interest in reading it? Were this done sooner in the process rather than later, we well might be able to nip more whackiness before it bubbles all the way up to the IESG. Mike ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: On Experts [Re: Should I* opinions be afforded a special status? (Re: [saag] Declining the ifare bof for Chicago)]
Brian E Carpenter wrote:
On 2007-06-15 18:04, Michael Thomas wrote:
Thomas Narten wrote:
If a respected security expert (one who has reviewed many documents,
contributed significantly to WG efforts, etc.) comes to a WG and says
"there is a problem here", but 5 WG members stand up and say "I
disagree and don't see a problem", do you really expect the security
expert's opinion to be given strictly equal weight and to just be
overruled since 5 voices are greater than 1?
Context matters here. I've seen situations where the so-called "expert"
is unable to articulate the problem, is rocking a personal hobby
horse of theirs, is expressing a general philosophic point without much
attention to the actual problem (see "unable to articulate"). Etc. Also:
it may just be me, but this gradual creep toward "experts" having a
named, and different status is bothersome ("expert review"). It sweeps
under the rug that this is really a continuum of cluefulness,
experience,
as well as frankly political considerations, some of which are more
odious than others.
Mike, just to try clarify the "expert review" issue. That term comes
up specifically for IANA assignments that are controlled more than
First Come First Served and less than RFC Required. There's a full
discussion in draft-narten-iana-considerations-rfc2434bis but my
short version is: we can't expect IANA to have in-house expertise
for every registry, and we don't want an IETF debate about every
relatively routine assignment. Having designated experts seems to
be the only reasonable and scaleable solution.
Yet, this not the only place where I've seen "expert review"...
I prefer personally to use a term like "specialist" for review
of drafts, or "generalist" in the case of Gen-ART reviews. You
can be a specialist without being an expert :-)
which I take to be what you're referring to here. Let me say that
I'm happy to get cross functional review whenever I can get it. But
the way that Thomas posed his question "should 5 wg ignorants
overrule one `expert'?" shows that there can be a downside when,
in fact, the `expert' is off in the weeds for the reasons (and more)
I mentioned above. Since "expertry" is really a continuum of
competence and that becoming a recognized "expert" is one part
clue, one part clique, and probably one part availability, we shouldn't
give their expertise _too_ much power -- especially on well worn
ratholes. Also: as this "expert review" thingy becomes more popular --
and powerful -- parceling it out to a single person has a tendency to
pave over what happens when subject area experts meet: they often
disagree. Therein lies danger for the unhappy working group on
the receiving end: you're just postponing that fight for later in the
process. Worse is when the "expert" demands satiation of a favorite
hobby horse, typically of the kind that other experts find either
uninteresting, or not worth the fight since there's no skin off their
nose.
So getting back to Thomas' question: as always with engineering,
"it depends.", and I hope that those sending out the "experts" are
cognizant of that as well.
Mike
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
Re: Should I* opinions be afforded a special status? (Re: [saag] Declining the ifare bof for Chicago)
Thomas Narten wrote:
If a respected security expert (one who has reviewed many documents,
contributed significantly to WG efforts, etc.) comes to a WG and says
"there is a problem here", but 5 WG members stand up and say "I
disagree and don't see a problem", do you really expect the security
expert's opinion to be given strictly equal weight and to just be
overruled since 5 voices are greater than 1?
Context matters here. I've seen situations where the so-called "expert"
is unable to articulate the problem, is rocking a personal hobby
horse of theirs, is expressing a general philosophic point without much
attention to the actual problem (see "unable to articulate"). Etc. Also:
it may just be me, but this gradual creep toward "experts" having a
named, and different status is bothersome ("expert review"). It sweeps
under the rug that this is really a continuum of cluefulness, experience,
as well as frankly political considerations, some of which are more
odious than others.
Mike
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
Re: consensus and anonymity
Henning Schulzrinne wrote: This is not some hypothetical case. In that WG, there had been no consensus for a year+ and it seemed unlikely that one would emerge, except by exhaustion. Thus, the ADs proceeded with a vote, with the properties described previously, which was then used as a basis for a protocol decision. (Disclosure: I was at the losing end of that decision.) You could have always done what megaco did: flip a coin. At least that's pretty hard to game. Mike, "before we flip that coin, lets be clear on the question again: 'heads I win, tails you lose' right?" On Jun 1, 2007, at 2:02 PM, Michael Thomas wrote: Henning Schulzrinne wrote: The current process doesn't work very well when voting is required, after hum-style consensus has been inconclusive. Why should voting be required? If the goal is consensus, "inconclusive" shows that you haven't achieved it. Right? That seems to me that the process is *working* as intended. Mike ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: consensus and anonymity
Henning Schulzrinne wrote: The current process doesn't work very well when voting is required, after hum-style consensus has been inconclusive. Why should voting be required? If the goal is consensus, "inconclusive" shows that you haven't achieved it. Right? That seems to me that the process is *working* as intended. Mike ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: consensus and anonymity
Brian E Carpenter wrote: On 2007-05-31 22:08, Michael Thomas wrote: One thing that occurs to me is that in my initial message I implicitly felt that the room hands/hums were a more accurate assessment of consensus than the list. I guess that I should fess up that I've always felt that the "consensus is determined on the list" is something of a charming myth. I don't think people unable to travel to meetings would agree. Since our objective is to discover technical problems with a proposed consensus, I think it's essential to allow any netizen to raise problems. One email technical comment pointing out a serious flaw has far more weight than a hundred people in a room going "mmm". It seems that people have read more into my initial idea than I had really meant. I only meant it to be limited to consensus calls on the mailing list where somebody might not be comfortable publicly saying their +1. This is orthogonal to the question of anonymity of somebody who doesn't feel comfortable bringing up a technical problem on the list ala the example of Dean on the SIP list recently. The reason I say it's a charming myth is that the list is pretty lousy since it's usually a very small set of people who will speak up. Ie, the protagonists. At meetings, you get a broader sense including the intensity. As somebody who hasn't been to the last few IETF's, I well aware of the "not being there" part. Still, I think it's a myth that these hums are *just* the sense of the room and no more. They're clearly a lot more than that as it almost always brings a conclusion to some point of contention, and when it's brought up again on the list you can almost always be guaranteed a "but we decided this in Oslo!". Myth, meet reality. Mike ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: consensus and anonymity
Andy Bierman wrote: Michael Thomas wrote: I think the inability of the IETF to make decisions in an open, deterministic, and verifiable manner is a major flaw. It promotes indecision and inaction. Is there any human decision making process that has all of these characteristics? Or that even believes that those are axiomatic? Dishonesty by the management is a problem regardless of what system we have. Most wg's these days have two chairs, so collusion would need to be at least that deep, and probably require an AD to be on board too. If that really were the case, I doubt any system is likely to perform very well. Only transparency can prevent corruption. Preventing corruption is not the end product of the IETF. Producing good/useful protocol specs is the end product of the IETF. Thus "corruption" is just one consideration. Life is messy that way. But this cultural thing does bug me. It seems unsatisfying to me that our pat answer to cultural differences is "become more western". The language issue is already asking quite a lot of the rest of the world. I don't see the cultural bias here. Which culture are you from? Mike ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: consensus and anonymity
Andy Bierman wrote: Spencer Dawkins wrote: Just following up here... From: "Lakshminath Dondeti" <[EMAIL PROTECTED]> But, I wonder why anonymity is an important requirement. The mailing list verification has at least two properties that are more important to the IETF: the archives provide for anyone to be able to verify the consensus independent of the IETF hierarchy (chairs, ADs and whoever); further the archives provide a means to verify the consistency of any IETF participant, chairs or ADs at any given moment, candidates for WG chair and I* positions, and anyone in general. We've been telling new WG chairs for several years that - they really need to have most discussions in public/on mailing lists, - we recognise that some people aren't comfortable challenging others in public, and - we recognise that this discomfort may be more common in some cultures than in others. So, for reasons that both John and Lakshminath identified, we've been asking WG chairs to encourage participants to engage in public discussions, but to be receptive to private requests for assistance on how to carry out those discussions. The alternative - a WG chair who tells the working group that the apparent WG consensus on the mailing list is being overruled because of anonymous objections that the WG chair cannot share with the WG, or because of private objections that the WG chair is "channeling" from a back room - would make voting seem reasonable (or, to use Mark Allman's characterization in another thread, "seem charming"). This is not an alternative. If you are not willing to make your technical objections to a technical specification publicly, then they cannot be part of the IETF decision-making process. If that's true, then why do we have hums at wg meetings at all? A hum doesn't give the reasoning; it's a binary quantity. What's to prevent a WG Chair from "padding" the anonymous "votes"? If 5 people in public (WG meeting or mailing list) are for some proposal, and the Chair says, "I heard from 6 people who are against this, but don't want their identities known, so the proposal is rejected." Not acceptable. Dishonesty by the management is a problem regardless of what system we have. Most wg's these days have two chairs, so collusion would need to be at least that deep, and probably require an AD to be on board too. If that really were the case, I doubt any system is likely to perform very well. But this cultural thing does bug me. It seems unsatisfying to me that our pat answer to cultural differences is "become more western". The language issue is already asking quite a lot of the rest of the world. Mike Thanks, Spencer Andy ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: consensus and anonymity
One thing that occurs to me is that in my initial message I implicitly felt that the room hands/hums were a more accurate assessment of consensus than the list. I guess that I should fess up that I've always felt that the "consensus is determined on the list" is something of a charming myth. Of course if we went with the room consensus, gaming the system would just be done by different means, so my feeling shouldn't be taken as endorsement of that as an alternative. Mike Lakshminath Dondeti wrote: Oh, I understand cultural sensitivities, but I have never heard of not wanting to challenge in the public (except the disagreeing with the employer thing). The problem with that is that if people don't like something and can't speak up or will only speak through a chair or an AD, it allows natural avenues for abuse. The chair or the AD might as well be making decisions at that point. Even anonymous voting has verifiability as the crucial part of requirements. If our consensus process is not independently and openly verifiable, we might as well close shop! Lakshminath PS: BTW, I agree with Melinda that we should not allow a minority to block progress; in any type of consensus process, unfortunately some of us will be at the losing end of things. On 5/31/2007 12:33 PM, Spencer Dawkins wrote: The alternative - a WG chair who tells the working group that the apparent WG consensus on the mailing list is being overruled because of anonymous objections that the WG chair cannot share with the WG, or because of private objections that the WG chair is "channeling" from a back room - would make voting seem reasonable (or, to use Mark Allman's characterization in another thread, "seem charming"). Thanks, Spencer ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
consensus and anonymity
Hallam-Baker, Phillip wrote: The problem with consensus is how you decide to count the undecideds/neutrals. In most cases of controversy there will be a small group pro, a small group con and the bulk of the WG will be somewhere inbetween. If the breakdown is 25%/25%/50% a biased chair can effectively decide the outcome by choosing to interpret 'no objection' as 'no support' or vice versa. One thing that occurs to me is that there is usually a huge disconnect between the participation in hums at a meeting and the email equivalent on the working group list. I'd say that it's typically between one and two orders of magnitude at a meeting more hands/hums than on the list. And of course, on the list it's usually just a rehash of the same active participants with a few stragglers thrown in. Maybe part of the problem with the "official" consensus taking on the list is that it isn't sufficiently anonymous? It's pretty easy in a crowd to hum or put up your hand in a sea of others; on the list, it requires quite a bit more conviction. Apathy is the other likely reason, but there's not much we can do about that short of working group demolition derby videos or suchlike. So might having the ability to contact the chairs in private to register their preference be reasonable? I don't recall seeing this in any of the working groups I've participated in. Mike ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums
Brian Rosen wrote: The cable systems use the MAC address of the DOCSIS modem to determine which subscriber is asking for location. It's not perfect, because it is possible to move a DOCSIS cablemodem from one house to another within some area (often the service area of the CMTS, but in many systems, less than that). The ability to move without detection is a problem the have for other revenue sources and there is some effort being put into systems to detect that kind of thing. The incidence of moving the cablemodem without notice is apparently very small. You don't get the location of the server, you get the location of the client. That's only because there's an out of band arrangement with the MSO and the subscriber. DHCP itself gives no such information. Wireless substantially confuses the matter too. All it takes is two Pringle's cans to cast that relationship in doubt. Mike Brian -Original Message- From: Michael Thomas [mailto:[EMAIL PROTECTED] Sent: Friday, April 20, 2007 9:39 AM To: Brian E Carpenter Cc: 'GEOPRIV WG'; 'Dawson,Martin'; ietf@ietf.org; 'Allison Mankin'; 'John Schnizlein' Subject: Re: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums Brian E Carpenter wrote: On 2007-04-20 09:21, Hannes Tschofenig wrote: DHCP is not a great choice in a mobile environment and also not when it comes to more complex location representations. Why can't a mobile system have a locally valid DHCP record (+/- the length of a wireless link)? For that matter, why couldn't a DHCP server have real-time triangulation data, if it exists at all? Do you mean more complex than can be expressed by RFC 4776 and RFC 3825 together? If you look at DOCSIS cable, a single head end can subtend a huge amount of cable in a single bridged domain. I seem to recall that in a rural Canadian MSO I worked with it was 10's if not 100's of miles. I have no clue how accurate GEOPRIV tries to be, but it sure seems that if the location of the headend/dhcp relay is only piece of information you have, your accuracy is going to be pretty lousy in many cases. If this information is intended for first responders, it seems that all you're doing is pointing to the right haystack to start searching for the needle. Mike, who probably shouldn't open his mouth here ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums
Brian E Carpenter wrote: On 2007-04-20 09:21, Hannes Tschofenig wrote: DHCP is not a great choice in a mobile environment and also not when it comes to more complex location representations. Why can't a mobile system have a locally valid DHCP record (+/- the length of a wireless link)? For that matter, why couldn't a DHCP server have real-time triangulation data, if it exists at all? Do you mean more complex than can be expressed by RFC 4776 and RFC 3825 together? If you look at DOCSIS cable, a single head end can subtend a huge amount of cable in a single bridged domain. I seem to recall that in a rural Canadian MSO I worked with it was 10's if not 100's of miles. I have no clue how accurate GEOPRIV tries to be, but it sure seems that if the location of the headend/dhcp relay is only piece of information you have, your accuracy is going to be pretty lousy in many cases. If this information is intended for first responders, it seems that all you're doing is pointing to the right haystack to start searching for the needle. Mike, who probably shouldn't open his mouth here ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Tracking resolution of DISCUSSes
Brian E Carpenter wrote: On 2007-01-15 17:11, Michael Thomas wrote: Michael Thomas, Cisco Systems On Mon, 15 Jan 2007, Brian E Carpenter wrote: Why not simply: - copy all Comments and Discusses to the WG mailing list - hold all discussions on the WG mailing list until resolution Why would we do this for technical typos and other things that are essentially trivial? I'd expect an AD to enter WG discussion when raising fundamental issues, but not for straightforward points. This seems sort of like a red herring to me: typo posts typically don't elicit much wg discussion in my experience. But please help me here: it seems that DISCUSS as currently instantiated is a conversation between the authors/wg chairs acting as liasons with the IESG. This sets up sort of a representative democracy kind of situation vs. a direct democracy that would be a conversation directly on the wg list. I can understand the IESG's desire for filtering, but that does place a lot of power in the hands of the wg's representatives. And power always begats abuse at some point... is this really what was intended? Abuse wasn't intended, obviously, but delegation was. Put simply, ~200 WG Chairs scale better than ~16 ADs. This rather assumes that the chairs and/or authors are always able to remember not only the material that is currently before the IESG, but also the history of how it got there. As an author, it's hard enough to keep track of the former and the latter is back in the realm of the super-human again. So when you get a DISCUSS which may well involve the intricacies of a very long and hard slog in the working group where many competing parties finally agreed to a consensus... how as the representatives do you know whether you are telegraphing the will of the working group? It's very hard, and at a late date it is *very* easy to make very basic mistakes again which not only negate the consensus of the working group, but are potentially just plain wrong. And that's assuming that there are no agendas, hidden or otherwise. So all in all, for an otherwise rather direct democratic kind of institution, I find the implied(?) representative nature of the backend linkages, non- transparency of process, and the juxtaposition of a fresh-but-disinterested ruling body next to the inured-but-interested working group sets the stage for a lot of potential process problems/abuses/surrender-and-ship-it kind of outcomes. That doesn't seem right. Mike ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Tracking resolution of DISCUSSes
Michael Thomas, Cisco Systems On Mon, 15 Jan 2007, Brian E Carpenter wrote: Why not simply: - copy all Comments and Discusses to the WG mailing list - hold all discussions on the WG mailing list until resolution Why would we do this for technical typos and other things that are essentially trivial? I'd expect an AD to enter WG discussion when raising fundamental issues, but not for straightforward points. This seems sort of like a red herring to me: typo posts typically don't elicit much wg discussion in my experience. But please help me here: it seems that DISCUSS as currently instantiated is a conversation between the authors/wg chairs acting as liasons with the IESG. This sets up sort of a representative democracy kind of situation vs. a direct democracy that would be a conversation directly on the wg list. I can understand the IESG's desire for filtering, but that does place a lot of power in the hands of the wg's representatives. And power always begats abuse at some point... is this really what was intended? Mike ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IESG Success Stories
Spencer Dawkins wrote: I strongly agree with John's reasoning here. But please keep reading... [] I really didn't want to take this off on this well trod tangent because it was... pretty much a tangent. And I definitely didn't mean this turn into some sort of grudgathon :) Now, backing off a few billion nanometers, When Michael kicked off this thread, his posting began: So what occurs to me is that a reasonable question to ask is whether there are some legitimate success stories where a DISCUSS has actually found big or reasonably big problems with a protocol that would have wreaked havoc had they not been caught. I ask because ... My impression is that drafts that capture experience with IETF working group dynamics are painful and useful (thinking specifically of the case studies in the draft that became http://www.ietf.org/rfc/rfc3669.txt). I think Michael's question is important enough to answer. I think I can think of some examples where the answer is "yes", but this isn't about what *I* think, it's about what our experience has been. Do other people think that collecting DISCUSS success stories is helpful? I have two points to add - - Michael asked specifically about SUCCESS stories. The level of cynicism in the circles I run being sufficiently high, I'm asking about the same thing Michael is asking about, where "success" matches the dictionary definition. - if people want to collect DISCUSS "success" stories, of the more ironic nature, I ask that we do this, going forward, and not looking backward. Depending on how you count Jon Peterson, we seated new ADs for almost half the IESG last year, and we know that we will pick up at least a few more new ADs this year, because some people have already said they will not return. We don't need to replay 30 years of history, and even going back to the beginning of ID tracker use would be less than helpful. If you have relevant deep dirt from the recent past, please feel free to file recalls and provide NomCom input, of course. But I hope everyone already knows that. Right... my point here is that metrics are often eye opening -- for all parties concerned. Even somewhat flawed and subjective metrics, so long as they are taken with the proper grains of salt. My sense is that if we did things like track DISCUSSes, time to resolution, length of DISCUSS in proportion to, oh say, the length of the draft or oh say the amount of time the working group took to get it to the IESG it might frame some of these debates in something resembling reality. Or as my initial suggestion about tracking whether these DISCUSS's are paying off when you factor in that all engineering is a tradeoff. As in, how do we know if the process is working? How do we know if the angst from us non-IESG folk about delay is justified, or would it have better spent trying impose discipline on the working group? I guess I'm just a gprof kind 'o guy. Mike ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IESG Success Stories
Brian E Carpenter wrote: Michael, 1. ADs physically don't have time to read intermediate drafts oustide their own Area. So while they may suspect that a WG is heading in a worrisome direction, they aren't in a position to do much about it. 2. ADs are collectively instructed by our rules to act as the reviewers of last resort - it's the IESG that takes the final responsibility to say a document is good enough. 3. Unfortunately, WGs do sometimes agree on drafts that prove to have signifcant defects when critically reviewed outside the WG. Put these facts together and you *will* get a reasonable rate of significant (i.e. hard to resolve) DISCUSSes, and in the nature of things they will come from ADs outside the Area concerned. Brian -- My focus was actually a lot more narrow: I wasn't trying to insist that AD's be super-human, and I honestly believe that the job they do is extremely difficult. My gripe is when an outside AD takes an interest in the work, goes to the f2f meetings, maybe reads the drafts but then waits to IESG evaluation time to DISCUSS their issues. If they know they have a problem(s), it would be *far* better to air that sooner rather than later for all parties concerned. Doing this leads to the perception of a imperious and capricious IESG. This is a very different situation where you get a DISCUSS where it's a surprise to all parties from an AD not involved at all; the former should have been resolved before it got to last call, the latter is the process working correctly. IMO. Mike ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IESG Success Stories
John C Klensin wrote: If an AD who was responsible for a WG came up with an issue about that WG's work and raised it only during or after Last Call, I'd expect either a really good explanation or a resignation. I certainly would not expect it to happen often. But, IMO, we have an IESG and, indeed, an IETF rather than a collection of different organizations addressing per-area issues precisely to increase the odds of catching serious cross-area and cross-perspective issues before things go out. Like it or not, unless the relevant WG makes an effort to get broad reviews at critical "early" points, there will always be a risk of late surprises as someone --in the community during Last Call or on the IESG-- suddenly wakes up and says "but how does this relate to XYZ". I was obviously not clear enough on my first post because I wasn't referring to the shepherding AD or the poor AD's who have paid no attention at all who are then tapped to do their job. It's really the in between AD's that I think really exasperate the wg participants -- if they've paid enough attention to attend the wg meetings and perhaps even subscribe to the mailing list and registered concerns, I really think they owe it to the working group to either get them out when the working group is in active issue resolving mode, or to... well, just live with it. Or something. Frankly it does a lot of damage to the IESG's reputation when you know that there's likely going to be trouble, but there is nothing you can do to fend it off ahead of time because those AD's have only given vague allusions to their non-amusement. It promotes the vision of the unitary IESG which I think is a bad thing. With regard to textual nit-picking and evaluation of worthiness of prose, I tend to agree with what I think you are saying. However, if a document is too badly written to permit interoperable implementations to be constructed without clarifying conversations among implementers, authors, and/or the WG, then the document is a failure and needs pushback. As with late surprises, somewhat more proactive effort on the part of WGs could prevent many of the problems we see, but... I was using "wordsmithing" rather broadly. My probably idiosyncratic meaning of "wordsmithing" here was "will this DISCUSS change the mechanics of the protocol or not". If the answer is no, we're really just making the document more ready for publication IMO. Something that does bring that possibility is obviously a lot more serious. It's been my admittedly limited experience that my version of "wordsmithing" is a lot more common, and the source of a lot of delay to varying degrees of dubiousness. Mike ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
IESG Success Stories (was: "Discuss" criteria)
So what occurs to me is that a reasonable question to ask is whether there are some legitimate success stories where a DISCUSS has actually found big or reasonably big problems with a protocol that would have wreaked havoc had they not been caught. I ask because it seems to me that the main things that wreak havoc with protocols tend to be rather subtle and not likely to be very visible to someone whose sum experience with the work is their assignment to read the current draft. That's not a slap at the people whose job is to review, only that it seems to me to be asking for super-human abilities. From my limited experience with DISCUSS -- and last call for that matter -- is that the focus is far more geared toward wordsmithing than actual mechanics of the protocol (from relatively disinterested parties, that is). While I have no issue with tightening up drafts for publication, it doesn't seem reasonable to be holding up the works for endless amounts of time _just_ because somebody -- or some faction of bodies -- isn't convinced that a draft is the prose they deign worthy. The other thing that occurs to me -- and I know this has been brought up in many different forms -- is that if an AD _was_ following the working group to some degree, why is it legitimate for them to wait for IESG evaluation to voice comments that affect the protocol's operation? That is, why aren't they held just like anybody else to voice those in WG last call when the WG is far more responsive to dealing with issues? These "IESG Surprises" really hurt the community by leading to the general perception that the IESG is capricious in a royally anointed kind of way. Mike Hallam-Baker, Phillip wrote: More recalls? How many have we had? I looked into what it would take to engage the recall process. I don't think it is possible to use it without tearing the whole organization appart. With reference to John's recent campaigns I note that we still have a situation where IETF practice is to employ a two stage standards process but the process documents describe a mythical three stage process. The IESG appears to be unwilling to either change the process document to reflect reality or to begin applying the three stage process. And I don't even have visibility into the process to know which individuals are the holdouts. The only response I am ever going to get back is the passive voice 'people on the IESG were not happy with the proposal'. This is a real business issue for me, not a theoretical one. I spend too much time having to counter FUD claims that some IETF protocol or other is 'merely' draft and that it should not therefore be considered. People in the Internet area understand the mendacity but this is not the case in banking. I can explain the fact that according to the IETF HTTP 1.1 is still a draft standard but in doing so I have to conceed the fact that the IETF processes are broken at which point the proprietary FUD peddled chips in. There are cases where consensus does not work. This is one of them. There is clearly no consensus in the IESG to either follow the process document or to fix it to match current practice. So we have the organization stuck in a decade long deadlock. This is where you need to have leadership (another thing that the NOMCON process is expressly designed to exclude). -Original Message- From: John C Klensin [mailto:[EMAIL PROTECTED] Sent: Saturday, December 30, 2006 8:57 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: ietf@ietf.org Subject: Re: "Discuss" criteria Dave, Scott, At the risk of repeating what a few others have said in different form, a few observations. Please understand that these comments come from someone who has been more consistently and loudly critical about even a hint of IESG arrogance and assertions of their power than either of you and who has formally proposed a significant number of ways of dealing with those problems --real or imagined-- than, I think, anyone else in the community... none of which proposals have gone anywhere. I believe that, ultimately, the IETF has to pick IESG members who can do the job of evaluating documents and consensus about it and then let them to do that job. And we had better pick people to do that job who technical judgment and good sense we trust. If we can't do that, then we are in big-time, serious, trouble: trouble from which no set of rules or procedures can rescue us. Much as it makes me anxious, I think we ultimately need to let an AD raise a Discuss because he or she has a bad feeling in his or her gut... and pick people who will use that particular reason with considerable care and who will challenge each other and work to understand the objection and either better document it or remove it as appropriate. If that discussion is abused in particular cases, I think it means that we need more appeals and, if there is a pattern, more recalls. In a long-term tradi
Re: draft status links on the wg pages?
Dave Crocker wrote: Bill Fenner wrote: Mike, Check out http://tools.ietf.org/wg/ and see if that gives you the view you're looking for. Bill, thanks. I suspect that's what Michael has in mind, except for one minor enhancement: Put a link to that page on the working group's main IETF page. A working group's main page really is its home page and, therefore, ought to bring together references to all relevant information. Given that the Tools folk have created yet-another useful mechanism, making each working group's page have a link to its related status information now becomes a trivial effort, with substantial benefit. Right, this is really cool -- although a link from the ietf wg page would be nice, the tools version almost looks like wg page v2.0 with a few additions (like the charter, milestones, etc.) cheers, Mike ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
draft status links on the wg pages?
First I have to say that I really like the draft tracker, and kudos for those responsible for making it happen. In fact, I like it so much that it seems to me that it would be nice to have a link directly to it from the working group page with its list of drafts. Ie: draft-foowg-bardraft-00.txt (link to draft) sts (link to the status tracker) Even nicer might be to display the actual tracker state as, say, the button itself. Mike ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: SRV records considered dubious
Keith Moore wrote: I don't expect there to be very many standards based protocols in the future that are not Web Services. I've seen lots of fads come and go, and so far I've seen nothing to convince me that Web Services is not yet another fad. Time will tell. Angle brackets are now as inescapable as ASCII was twenty years ago. Only for people who can't actually evaluate the consequences of protocol design decisions at the presentation layer. Admittedly, some things do get chosen by evolution. We have power-of-two word sizes now, and all hardware these days has to deal reasonably efficiently with eight-bit bytes. That's because these were found to work well over several decades of experience. But there are lots of reasons to avoid representing all data in a format that requires all of that data to be examined looking for delimiters, sometimes multiple times, by every machine that touches it. The point is that if you use a DNS Domain Name as the index you want to use the DNS as part of the distribution mechanism. The point is that the distributed information store that we currently know as DNS is separable from the protocol that we call DNS, and we can (if we are careful) design a new protocol that will let us access that information store more flexibly while still keeping the views consistent between the DNS protocol and the new protocol. Sure, but is the trust anchor that DNS more importantly provides? On today's internet with all of the vested interests could the devil we don't know possibly be any better than the one we do? I can imagine the only reasonable name for a working group that attempts that is BLACKHELICOPTERS. Mike ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: draft-kolkman-appeal-support
Gray, Eric wrote: Sam, et al, I doubt that noting an appeal has been determined to have merit is especially useful. As Sam implies below, it is possible to have controversy over this point, and any controversy is likely to mean no annotation of "merit" will occur in many cases. Ignoring for the moment the potential for recursion (do we need to have supporters for the "merit" of an appeal after the fact?), it seems to me that it might be more useful to treat any appeal for which there was not an absolute consensus that "no merit" could be ascribed to the appeal, as an appeal with merit. The reason I asked is because this is in the context of a (d)dos attack on the appeals process. Some people are clearly more litigious than others, but if the appeal at least has merit that seems a lot more acceptable than those who keep bringing up baseless junk. Maybe we need an IESG work duty program for problem appealers. No more appeals until you've done X amount of community duty. I guess that requiring that they wear orange jumpsuites might be a little over the top. Mike -- Eric --> -Original Message- --> From: Sam Hartman [mailto:[EMAIL PROTECTED] --> Sent: Tuesday, October 17, 2006 11:11 AM --> To: Michael Thomas --> Cc: John C Klensin; Ned Freed; ietf@ietf.org; Eliot Lear --> Subject: Re: draft-kolkman-appeal-support --> --> >>>>> "Michael" == Michael Thomas <[EMAIL PROTECTED]> writes: --> --> Michael> John C Klensin wrote: --> >> (1) The "supporter" procedure/requirement should be triggered --> >> only is someone shows symptoms of being a vexatious --> appellant. --> >> People who are entering their first appeals don't trigger it. --> >> People whose last appeal was successful, even in part (that --> >> would need to be defined, of course, and that might not be --> >> easy) don't trigger it. The only folks who need to look for --> >> supporters are those who have appealed before and --> whose appeals --> >> have been rejected as without merit. --> >> --> >> --> --> Michael> Can an appeal be rejected with merit? --> --> Yes. I think Robert's recent appeal was rejected that way. I --> personally think that Jefsey's appeal against the LTRU registry doc --> set was a reasonable appeal although we declined to make --> any changes. --> I suspect many people may disagree with me and argue that --> this appeal --> was without merit. --> --> I think the SPF and Sender ID appeals clearly had merit. --> I'm not sure --> whether we rejected them though. --> --> --> ___ --> Ietf mailing list --> Ietf@ietf.org --> https://www1.ietf.org/mailman/listinfo/ietf --> ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: draft-kolkman-appeal-support
John C Klensin wrote: (1) The "supporter" procedure/requirement should be triggered only is someone shows symptoms of being a vexatious appellant. People who are entering their first appeals don't trigger it. People whose last appeal was successful, even in part (that would need to be defined, of course, and that might not be easy) don't trigger it. The only folks who need to look for supporters are those who have appealed before and whose appeals have been rejected as without merit. Can an appeal be rejected with merit? Mike (2) The definition of someone permitted to be a "supporter" must, as several people have pointed out (Ned, IMO, most eloquently), be broad enough to include active IETF contributors who don't attend meetings. One class of action that might need appealing would be a procedural decision that would [further] impede the ability of those people to effectively get work done in the IETF and they _must_ have standing to appeal such measures by themselves or in conjunction with others who are similarly impacted. I would have no problem with a requirement that someone actually be a human being with some active interest or involvement in the IETF -- what some other standards bodies describe as a "materially concerned party". But requiring meeting attendance as proof of that seems to violate all sorts of IETF principles. (3) The idea that, if someone successfully appeals, or supports an appeal, on one action, they should be permanently barred from supporting similar appeals in the future is seriously broken. It could only have a chilling effect on the generation of appeals, legitimate ones as well as bogus ones, because one would want to save endorsements for important-enough occasions. It is also at variance with a principle that has been discussed recently on the IETF list wrt mailing list behavior and complaints: how an appeal is processed and considered should depend on its substance and merits, not on the identity of the submitter. This is particular important if someone who is relatively more familiar with IETF processes and fluent in English is asked to prepare an appeal on behalf of someone who is not -- a situation that, if anything, we want to encourage since I believe that well-drafted appeals tend to take less IESG and IAB time than ones in which those bodies have to spend time figuring out what the real problem is or what is wanted. Now, clearly, the above has the implication of "one free appeal per customer". If the bad guys whom Olaf is trying to protect against got themselves organized into a cabal, they could manage a denial of service attack. But I'm not sure that is a real, as distinct from theoretical risk and, more important, I think it is a risk we have to run if we want to have a viable appeals process. However, as I read the above, I wonder if the model of the I-D is backwards and your observation about "vexatious litigants" should be carried a bit further. Suppose we consider this situation as somewhat more like the mailing list abuse issue than one in which we assume that every person filing an appeal is the enemy until proven otherwise. If we adopt a model of that sort, then: We change the possible responses to an appeal from, broadly, "yes" or "no" to "yes", "no", and "no, and this is irrational and/or obviously totally without merit". The latter, which could itself be appealed but not by the subject (only by someone else on his, her, or its behalf), would imply something analogous to posting restrictions: a period in which the person was barred from appealing, or needed supporters, or something else. Similar to posting restrictions, the requirements/ barriers could be escalated if they needed to be applied additional times. That is obviously just an outline with a number of details that would need filling in, but it seems to me it has the important property of shifting the balance from "everyone who considers filing an appeal is presumed to be an attacker on the process" to "those who abuse the appeals process get their leashes shortened". Since I believe that the ability to easily appeal silly or inappropriate actions is a key part of our process model --one that wards off the need for much more heavyweight and complex procedures-- it seems to me that is the right way to balance things. john p.s. for those who have had in-the-hall discussions with me about appeals and prevention of DoS attacks in the last few years. Yes, I have changed my mind. Making things harder for those who use the appeals mechanisms to insist that the IETF follow its own pro
Re: NOMCOM term limits... Re: Now there seems to be lack of communicaiton here...
todd glassey wrote: I originally said two...and would prefer that. What I am saying is that there should be a total of two or three instances as a NOMCOM candidate and that is a much different statement than figuring who is in office now and who is eligible...As to what it prevents-career Internet Standards jockey's. And since the purpose is to keep the IETF honest, I want the same term limits for any and all IETF positions, including the TRUST as well. I usually route around ietf political damage as much as possible, but the real life experience at least here in California is that this is a load of hooey. Term limits don't do any of these things, they just rearrange the deck chairs. There will always be "Internet-Standards-Jockeys", it's just a question of whether the power they wield is transparent or not. Making them move to the shadows -- as power brokers always do when they can't be in power themselves -- changes the dynamic, but it doesn't do what you claim. The one thing that it *does* do is create clue scarcity when that wasn't a necessary outcome before. Which of course benefits the power brokers, not the process or constituency. But if you really want to prevent "career Internet Standards Jockey's", why not go to the root of the problem: IETF participation in general. Why wouldn't it be a good idea to prevent people who've been participating for, oh say, 5 years to participate anymore? That would really clear out the dead wood. Mike ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: LA -> San Diego transportation (Was: Re: Meetings in other regions)
Dave Crocker wrote: Clint Chaplin wrote: One data point: IEEE 802 is in San Diego this week, and I've met at least one attendee who flew through LAX to get here; that is, he took LAX -> SAN as his last leg. the flight is so short, one can feel guilty taking it. however the effort to rent a car from an airport, drive through Southern California traffic, and then either have the car sit for a week or try to dump it upon arrival, all make taking that short flight a reasonable choice. Or go through SFO. Given the fixed time costs of getting a plane in the air at all, the time difference between SFO and LAX are probably negligible. Of course one must make certain that SFO's runways are both open... Mike ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
+1
Is it just in my part of the ietf woods, or is this becoming a widespread phenomenon? If so, is this a good thing or a bad thing? On the one hand, it can be really difficult to get a feel for consensus on a mailing list where silence may mean agreement, boredom with the topic, or just... silence. And then there's the general problem that since we're engineers articulations of agreement generally start with some form of "it depends". So maybe a short hand way of saying "this is good enough for me, let's not go into the weeds by my agreeing for potentially different reasons" is a generally Good Thing. On the other hand, it sure seems like this sort of thing can be gamed. That is, somebody posts something and three or four of the usual suspect chime in with their +1 and lo and behold it looks a lot more like consensus than the previous "it depends" tomes. But is it really consensus, or is it just (benignly) a way for the usual suspects to signal to each other that they are willing live with another's proposal (which is not to say that that is necessarily a small thing in itself)? And what about when it's not benign? Could it be that +1 could be a way to short circuit inspection and debate in er, um, more, um, politicized settings? That and it seems all so very me too! Mike ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: are we willing to do change how we do discussions in IETF?
Keith Moore wrote: I am still waiting to see a description of the defects you believe that you have identified in either forum. I have asked you to describe them here several times, you have refused. And I've already partially explained why I'm not doing things that way. But in addition to that - mailing lists discussions are much better at elicting knee-jerk reactions than encouraging thoughtful reflection, and this is something that needs thoughtful reflection. Let me see: 1) you don't want to read the wg mailing list 2) you don't want to have issues opened up on the issue tracker 3) you can't be bothered to write an ID when you said you were going do two years ago 4) we're approaching last call, and I'm going to assume you think you're entitled to have us stop and wait until you do write something up 5) in mean time, we're just going to have to take your word about the weapons of mass destruction^H^H^H^H^H^H^H^H^H^H^H^H^H problems with DKIM. Is this your idea of "adult supervision" and "pipelining" that should be emulated for and wide across IETF working groups? Mike ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: are we willing to do change how we do discussions in IETF?
Keith Moore wrote: No, Dave, you insisted on interrupting me and shouting me down when I tried to raise these issues in the BOFs - doing your best to prevent me from making my case. We had three bof's, and Dave was a chair of bof #2 only. And you're not just one voice, you are one of the document authors. No he isn't. As for rough consensus, you seem to forget that there are two necessary conditions for standardization - one is rough consensus, the other is technical soundness. Thus far, I see a huge amount of effort on your part at making disparaging oblique remarks with no substance that anybody could act on if they were so inclined. The last round produce the same harrangue with promises to tell us why we're all screwed up and... no follow through. Until we see some real follow through with real issues, I have to assume that you're more interested in the art of harrangue than saving DKIM from the heathens. Mike ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: not listening
Keith Moore wrote: I also know that others have raised similar issues on the DKIM list since then, and fairly recently. But the current documents don't reflect any awareness of those issues or attempt to address them. That's why I said "not listening". We have from day one had an issue tracker. Please be specific. I haven't looked at the issue tracker. I've seen messages that were posted to the list that were saying much the same things I said at the BOFs and before the WG was chartered, and I've read the current documents and seen that the issues are not addressed or acknowledged. Which is to say that we have a process -- that we've published and followed -- and you couldn't be bothered to use it. Our issues tracker has been ridiculously open to issues too, but still no issues, no specific complaints. The prerequisite of listening is utterances somewhat crisper than "Harrumph". Mike ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
not listening
Keith Moore wrote: I also know that others have raised similar issues on the DKIM list since then, and fairly recently. But the current documents don't reflect any awareness of those issues or attempt to address them. That's why I said "not listening". We have from day one had an issue tracker. Please be specific. Mike ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: are we willing to do change how we do discussions in IETF? (was: moving from hosts to sponsors)
Keith Moore wrote: There's already a means for "external reviewers" to do so: read the drafts, make comments, add issues to the issue tracker. It's really not rocket science. That's not quite sufficient, because most WGs aren't proceeding according to good engineering discipline (e.g. they're doing things in the wrong order, like trying to define the protocol before the problem space is understood), there's little external visibility of what the WG is doing (so it's difficult to make timely input without actually following the entirety of the mailing list discussion), and often, nobody with any authority over the WG is checking to see whether the WG is actually responding appropriately to such comments. A more formal process is necessary. By whose standard? If you think that's going on, I'd think it would be appropriate to take it up with the relevent WG chairs and AD's. Last I heard, they're the stakeholders. Having some new sclerotic "pipeline" involved with the life blood of a working group sounds like a recipe for working group infarction to me. In other words, we don't want to distract WGs with useful input ... better that they should keep their heads in the sand for the entire 2-3 years of their existence and then produce irrelevant or even harmful output. And that way, maybe a few influential people within the WG can coerce the WG into producing something that favors their employers' short-term interest even if it harms other interests or glosses over important limitations. I repeat: There's already a means for "external reviewers" to do so: read the drafts, make comments, add issues to the issue tracker. It's really not rocket science. What you seem to want is some sort of cabal of dilettants who don't actually have to pay very much attention, but by their rank alone get to exercise veto power. Yuck. I don't suppose you have anybody in mind for such an IETF version of landed gentry? Mike ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: are we willing to do change how we do discussions in IETF? (was: moving from hosts to sponsors)
Keith Moore wrote: True. Which is why it's necessary to handle the reviews in a pipelined rather than a stop-and-wait fashion. But part of the reason IETF's process is so slow is that the only meaningful checks we place are at the end - so a working group typically labors to the point of exhaustion without having received any external feedback, so when the feedback does arrive the working group is so dysfunctional that it's nearly incapable of fixing anything (and it is often in denial about what is wrong). Providing more early feedback will speed up the process rather than slow it down. There's already a means for "external reviewers" to do so: read the drafts, make comments, add issues to the issue tracker. It's really not rocket science. Having some new sclerotic "pipeline" involved with the life blood of a working group sounds like a recipe for working group infarction to me. Mike ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: are we willing to do change how we do discussions in IETF?
Keith Moore wrote: On Fri, 23 Jun 2006 16:18:40 -0400 "Burger, Eric" <[EMAIL PROTECTED]> wrote: I would offer that in *some* groups the running code bar is reasonable. I would have little objection to requiring running code as a test of feasibility of a new idea. I would object strongly to an argument that just because someone has running code, means it's a good indication of adequacy of the protocol...DKIM is a great example of a poorly designed protocol that has been justified by running code. This is simply untrue. The fact that we had running code across multiple disparate code bases was offered only as an indication as to the maturity of the draft. We never said that was the only reason or even the primary reason that the working group should be formed and that it progress to PS. None of the participants that I've come across think that running code trumps rough consensus -- both of which has been chugging alone nicely, I'll add. Mike ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: are we willing to do change how we do discussions in IETF?
Keith Moore wrote: I would have little objection to requiring running code as a test of feasibility of a new idea. I would object strongly to an argument that just because someone has running code, means it's a good indication of adequacy of the protocol. Specific examples aside, I agree. Running code should be a necessary condition for something to progress, but not a sufficient one. I think we would do well to require a reference implementation as a condition for Proposed Standards from new working groups or individual submitters...but there are other conditions that we should impose that are far more important. Such as, a requirement for formal cross-area review of the design goals document and of preliminary specifications as a prerequisite before producing a reference implementation. How utterly sclerotic. And what is the IETF, the code police? If ever there were a need to make the IETF utterly and completely beside the point, this suggestion would be the perfect way. Mike ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
ASCII is dead, long live ASCII (was: Image attachments to ASCII RFCs)
Hallam-Baker, Phillip wrote: John, You mean that we should update the current medieval print format to take advantage of the best technology available to the Victorians? Why go to all that trouble to create infrastructure to support an obsolete document format when we can get all the infrastructure required to support a modern, open format that delivers professional results for free? Moreover there is a much higher probability that third party tools will support a common W3C/IETF format than an IETF only format. Which tools would those be? Cat, tr, emacs, vi, grep, cut, sed, curses, wc, more or less? Am a Luddite. I like ASCII. I despise PDF, and most especially its hideous anti-aliased fonts. As software engineer, I don't need drawings that I can use to run a lathe or a milling machine. Simple stick figures, ladder diagrams, and boxes for bits and bytes are about all I really need to see to transform an RFC into code. As protocol designer, the fewer Paper Clips sent by Beelzebub himself, the better. If it can't be edited using the buffer gap method, I'm not interested. Victorian? Pah. The death of Prince Albert of Ascii would require a minimum of a year of mourning, and a smart new black wardrobe for Phill. Not to mention a cross sovereign. Mike, we are not amused. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Best practice for data encoding?
Theodore Tso wrote:
On Mon, Jun 05, 2006 at 08:21:29PM -0400, Steven M. Bellovin wrote:
More precisely -- when something is sufficiently complex, it's inherently
bug-prone. That is indeed a good reason to push back on a design. The
question to ask is whether the *problem* is inherently complex -- when the
complexity of the solution significanlty exceeds the inherent complexity of
the problem, you've probably made a mistake. When the problem itself is
sufficiently complex, it's fair to ask if it should be solved. Remember
point (3) of RFC 1925.
One of the complaints about ASN.1 is that it is an enabler of
complexity. It becomes easy to specify some arbitrarily complex data
structures, and very often with that complexity comes all sorts of
problems. To be fair, though, the same thing can be said of XML (and
I'm not a big fan of a number of specifications utilizing XML either,
for the same reason), and ultimately, "you can write Fortran in any
language".
Ultimately, I have to agree with Steve, it's not the encoding, it's
going to about asking the right questions at the design phase more
than anything else, at least as far as the protocol is concerned.
As far as implementation issues, it is true that ASN.1 doesn't map
particularly well to standard programming types commonly in use,
although if you constrain the types used in the protocol that issue
can be relative easily avoided (so would using XML, or a simpler
ad-hoc encoding scheme). I don't think there is any right answer
here, although my personal feelings about ASN.1 can still be summed up
in the aphorism, "Friends don't let friends use ASN.1", but that's
mostly due to psychic scars caused by my having to deal with the
Kerboers v5 protocol's use of ASN.1, and the feature and design bloat
that resulted from it.
Here's my down in the trenches observations about XML and to some degree
ASN.1.
XML gives me the ability to djinn up a scheme really quickly with as
much or as
little elegance as needed. If nothing else, XML quite rapidly allows me
to hack up
intpreters that would otherwise been another parsed text file casuality
residing in /etc.
And most likely, if they could read the previous text encoding, the XML
is about as
transparent. This is a very nice feature as it allows common parsers,
leads to common
practices about how to lay out simple things, and common understanding
about what
is right and wrong. So, for my standpoint XML is "no more ad hoc
parsers!", which
is good from a complexity standpoint, especially when you look at how
spare the
base syntax is.
That said, anything that requires nested structure, etc XML is probably
just as
inadequate as anything else. And who should be surprised? Don't blame the
Legos that they self-assemble into a rocket ship. One big plus about XML is
that I can just _read_ it and hack up pretty printers in trivial time.
ASN.1 that is,
um, abstract necessasrily needs to go through a translation layer which IMO
is never as fun and convenient -- and absolutely discourages dilitante
hacking (when
is the last time you fiddled with an XML file vs. the last time you
fiddled with
ANS.1? never for the latter?).
I guess that what part of what this devolves into is who we're writing these
protocols/schemes for: machines or people? That, I think, is a huge false
dilemma. We clearly are writing things for _both_ (the executors and the
maintainers) ; the only question in my mind is whether an easy for human
to maintain encoding is too inefficient on the wire for its task. In some
cases it clearly is, but those cases are becoming the outliers -- especially
at app layer -- as the march of memory and bandwidth plods on.
So with all of these wars, the sexy overblown hype ("yes of course XML can
solve world hunger!") often eclipses the routine and mundane tasks of
writing
and maintaining a system (golly, I need a config file for this, it's
been a while
since I wrote a really crappy parser. woo woo!). C'est la vie.
Mike
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
Re: Best practice for data encoding?
David Harrington wrote: I agree that complexity breeds bug-prone implementations. I wasn't around then; did anybody push back on SNMPv1 as being too complex? http://www.cert.org/advisories/CA-2002-03.html is mainly about SNMPv1 implementations. ;-) I wasn't there to push back, but when I got asked to implement it back then the Simple part such seemed like something between a fib and the Big Lie. Did we really need ASN.1 to define a debug peek/poke-like protocol? Mike dbh -Original Message- From: Steven M. Bellovin [mailto:[EMAIL PROTECTED] Sent: Monday, June 05, 2006 8:21 PM To: David Harrington Cc: [EMAIL PROTECTED]; ietf@ietf.org Subject: Re: Best practice for data encoding? On Mon, 5 Jun 2006 20:07:24 -0400, "David Harrington" <[EMAIL PROTECTED]> wrote: Hi The security problems identified in http://www.cert.org/advisories/CA-2002-03.html "Multiple Vulnerabilities in Many Implementations of the Simple Network Management Protocol (SNMP)" are not caused by the protocol choice to use ASN.1, but by vendors incorrectly implementing the protocol (which was made worse by vendors using toolkits that had the problems). If "Multiple Vulnerabilities in Implementations" were used to condemn the encoding methods of protocols that have been incorrectly implemented, then we would have to condemn an awful lot of IETF protocols as being very (security) bug prone: Works for me More precisely -- when something is sufficiently complex, it's inherently bug-prone. That is indeed a good reason to push back on a design. The question to ask is whether the *problem* is inherently complex -- when the complexity of the solution significanlty exceeds the inherent complexity of the problem, you've probably made a mistake. When the problem itself is sufficiently complex, it's fair to ask if it should be solved. Remember point (3) of RFC 1925. I'll note that a number of the protocols you cite were indeed criticized *during the design process* as too complex. The objectors were overruled. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF lists as RSS?
Alexandru Petrescu wrote: Is it possible to read content of the IETF lists (WG discussions, announce, etc) as RSS feeds? I think the IETF doesn't provide it as such, but is there maybe a gateway mailman-rss that would allow to read it so? Please excuse if the technical formulation is aberrant, I'm just getting familiar with RSS feeds. The problem I have is that I'm subscribed to a relatively many IETF (and non-IETF) lists, some that I browse more often than others, and the mailbox is quickly exceeding my provider's capacities, as well as many other providers' I guess. Changing subscriptions to all lists is painful (even if IETF offers a IETF-wide change option, not all do) and I wouldn't go through it again, but maybe one last time. Perhaps this is unhip and in the way, but mail2news might be a solution here. Mike, gnus r00lz ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Jabber chats (was: 2 hour meetings)
Brian E Carpenter wrote: Just a general comment: I think that as far as decision-taking is concerned, we need to treat WG jabber sessions (and teleconferences) exctly like face to face meetings - any "decisions" taken must in fact be referred to the WG mailing list for rough consensus. Otherwise, the people who happen to attend a particular jabber session or teleconference have undue influence. So, it would be OK for a WG chair to write to the WG "On yesterday's jabber session, there was a strong consensus to pick solution A instead of B. The arguments are summarized below and the full jabber log is at X. Please send mail by if you disagree with this consensus." It would not be OK to write "On yesterday's jabber session we decided to pick solution A." Yep, that's exactly what I had in mind -- a proxy for actual f2f meetings to hopefully cut down on the thashing about on the list itself as people are just trying to understand one another. Mike ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Jabber chats (was: 2 hour meetings)
Keith Moore wrote: sometimes I find remote participation (via audio streaming and jabber) more effective than actually attending the meeting. I sometimes am surprised to find that the extra distance makes it easier for me to see what is relevant. I also think it might be less distracting to attend a meeting from my own office than to be in a room full of people who aren't paying attention. Maybe there's an intermediate between email and full f2f time? Something like having well known jabber chats to simulate the quickness of f2f conversation without having to be there? There is some amount of precedence for this with the IESG's telechats. They could be structured like regular wg meetings with moderation, etc for well known ones, and the same room could be reused for ad hoc/sidebar discussions when not in use. Mike ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Guidance needed on well known ports
Noel Chiappa wrote: > From: "Steven M. Bellovin" <[EMAIL PROTECTED]> >> Another option, now that I think about it, though, is a TCP option >> which contained the service name - one well-known port would be the >> "demux port", and which actual application you connected to would >> depend on the value in the TCP option. > Like tcpmux, port 1, RFC 1078? You know, as I was typing that, I was thinking "I'll bet someone has something that does this, and I just don't know about it, and I'm going to look dumb as toast"... Sigh... :-) Which leaves us the obvious question: why aren't more people using TCPMux, if it already exists? Because port 80 exists? Mike ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Venue requirements - canoe?
Sounds a lot more like a distributed denial of service attack to me. Mike Gray, Eric wrote: Sounds to me like this comes under the Transport Area - at least as far as flooding control is concerned. Avoidance of flooded paths, on the other hand, might be a routing Area problem. --> -Original Message- --> From: Steven M. Bellovin [mailto:[EMAIL PROTECTED] --> Sent: Monday, March 20, 2006 11:09 AM --> To: Tim Chown --> Cc: ietf@ietf.org --> Subject: Re: Venue requirements - canoe? --> --> We clearly need to tell the Routing Area to work on better flooding --> algorithms. --> --> --Steven M. Bellovin, http://www.cs.columbia.edu/~smb --> --> ___ --> Ietf mailing list --> Ietf@ietf.org --> https://www1.ietf.org/mailman/listinfo/ietf --> ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: "too many notes" -- a modest proposal
Brian E Carpenter wrote: Eliot Lear wrote: Douglas Otis wrote: I suspect that at the moment, I am the guilty party in consuming bandwidth on the DKIM list. With the aggressive schedule, the immediate desire was to get issues listed, corrected, and in a form found acceptable. Without going into all the reasons why here, I asked Doug to separate out issues into separate messages. Exactly. If a WG group is discussing a dozen separate issues in parallel, an active participant can easily send several dozen *constructive* messages in a day. Our problem with disruptive messages can't be solved by counting bytes. Is there really a working group that can realistically deal with a dozen separate issues in parallel? I know that when I see a dozen or so issues posted to a mailing list, my eyes glaze... Mike ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF65 hotel location
John Levine wrote: Cue ten further emails describing various Google Earth mashups that correlate restaurants with capacity, wait time and geek acceptability If we could morph it into a signup system that distributed people according to restauant capacity and avoided the problem that someone says "I hear there's a burrito place on X street" and a herd of 300 IETFers shows up there, since they don't know any other places to go, then you'd really have something. I'm afraid it's beyond IETF's expertise to come up with distributed burrito processing protocols. Mike ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
"too many notes" -- a modest proposal
It seems to me that a lot of what causes working group lists to melt down is simply the volume of traffic -- usually with plenty of off-topic banter, or exchanges of dubious value, with the resulting conjestive collapse of our wetware buffering. On good days, the drop algorithm may be more sophisticated than tail drops; on bad days... Perhaps we should take a lesson from TCP and set a receive window on IETF mailing lists in the face of conjestion. The sender is thus obligated to keep the transmission within the window, and as a side effect to consider the quality of the, um, quantity. Just this simple step would greatly limit (purposeful) DOS attacks and other death spirals. It also mitigates the "free speech" attacks by not throttling based on content (which is inherently contentious), but based on wg mailing list "bandwidth". in all modesty, Mike ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: bozoproofing the net, was The Value of Reputation
Harald Tveit Alvestrand wrote: [] Sigh. Can I suggest that a little exponential backoff on all parts may be appropriate? As one of the authors of the dkim draft, this has been an extremely painful thread to watch. Mike ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: WG Review: Domain Keys Identified Mail (dkim)
John C Klensin wrote: In addition, there is, I think, one other approach that might be appropriate, but only in very limited circumstances. That approach applies where there is a well-thought-out approach with design team consensus, evidence of implementation, and no clearly-identified technical concerns.Then, and only then, I think that an approach of "the WG gets to challenge the base spec and assumptions, but to change them only if there is good reason and consensus to do so" is plausible with a standards track target. I think that XMPP, and the XMPP language, probably is an instance of that case. Other than claims and counterclaims, I've seen little that would permit the IETF community to form a consensus about exactly what stage the DKIM work (and implementation, deployment, and demonstrate that it accomplishes whatever is being claimed) is really at, a consensus that seems to me to be necessary to determine whether it should be chartered as a WG if there are going to be any restrictions at all on what that WG can consider. That strikes me as sad since, beyond philosophical debates, it seems to me to be the key issue. I obviously think it's closer to #4 than anything else. Note I wasn't weighing in about whether this piece of word-smithy vs that was better or not, just my concern that the lack of negotiation/feedback make the backward compatibility problem far more nettlesome than other protocols that have that luxury. There is a substantial risk that a bunch of gratuitous thrashing around -- or worse a greenfield makeover ala MEGACO -- will cause this effort to crater. Given MARID, I don't think we get many chances and that this is really a situation where the best is the enemy of the good. As such, I think it's reasonable for the charter to limit the scope of changes to those that will really tighten up the mature parts of the specs instead of a, IMO, futile -- and destructive -- trip back to first principles. False dichotomy? Maybe, but not out of the question if there is no limit at all, and that's pretty bothersome for those of us who advocated taking this to ietf and tried really hard to make this look like something that would pass ietf muster. Finally, I understand that for many people there are larger principles at stake about the nature of ietf, etc, etc. I can't tell you how thrilled I am that we are the posterboy for _that_ argument. Mike ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: WG Review: Domain Keys Identified Mail (dkim)
Cullen Jennings wrote: My current understanding is that the deployments are small enough that changes are still easy and that non backwards compatible changes are already expected. Mail is, in fact, pretty different than most IETF protocols insofar as it's a store and forward system where there can be no expectation of end to end negotiation which is generally helpful for smoothing out protocol botches and incompatible changes. With mail every time you make an incompatible change, you have to hope that the receiver at the far end is in synch with that incompatible change or you're pretty well hosed. With each one the utility of the protocol is divided and conquered. I'm not sure who Keith was talking about with his broad brush assertion -- there are probably about 30+ people who've had a hand in the creation of the current drafts before we ever brought it to IETF, but my concern is that given complete lattitude the resulting thrashing around will produce an extremely narrow intersection between compatible senders and receivers. Which will constitute failure in all likelihood. On the other hand, I think its really a stretch to say that we are unwilling to listen, or that we're looking for a rubber stamp. We have already agreed to -- and incorporated -- a substantial backward incompatible change (the canonicalization) due to feedback (and threats) we got. What I'm hoping for is that there is a sufficiently high barrier that cosmetic changes not be good enough reason to make a backward incompatible revs. Equally disasterous would be to throw this entire area open for a greenfield design; considerable time and effort has been expended, and frankly Keith's observations don't strike me as new or novel -- we've been at this for many years at this point, and his points have been hashed and rehashed many times over the years by the people who have been paying attention to this more than just the week before and after a BOF. Mike ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Petition to the IESG for a PR-action against Jefsey Morfin posted
Harald Tveit Alvestrand wrote: It doesn't make me feel good either. But the alternatives I saw were: - Don't do anything, and let Jefsey continue doing damage - Make a solo proposal (or one with its supporters gathered privately) to the IESG for a PR-action - Be public, and see who else agreed with my opinion what about: - killfile the person and encourage others to do the same? Is Usenet really that distant of a memory? And the dynamics would probably work the right way too: on Usenet, there can be an amusement factor associated with the abuse bottom's torment which makes for a sustained feedback loop. But this is a professional organization, not an electronic cocktail party so I'd expect convergence more often than the feedback loop. This leaves the chairs who would have to deal with the person, but one would assume that it would eventually get lonely doing write-only posts and eventually go away. Only if that didn't work should the posting death penalty be contemplated, IMO. Mike, with no opinion on the specific case ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: delegating (portions of) ietf list disciplinary process
Dean Anderson wrote: [adhomirama] Regardless of all of this officialdom, might it be useful to put together a list of h:j equivalents for Thunderbird and other popular mail clients to make this list a more enjoyable read? Mike ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: net.stewards [Re: BitTorrent (Was: Re: [Isms] ISMS charter broken- onus should be on WG to fix it)]
Brian E Carpenter wrote: Michael Thomas wrote: I know that we aren't the net.cops, but are we not net.stewards either? Up to a point, but there are limits to what we can do. We can request that the RFC Editor not publish things we think are damaging. The IESG does this a few times a year. Similarly, we can request that IANA not register things we think are damaging, or at least to label them as potentially dangerous. We can publish screeds about damaging practices. The IAB does this a few times a year. We can try to develop non-damaging solutions for requirements where the easy solutions are damaging, and we can try to repair our own damage (as HTTP 1.1 repairs HTTP 1.0) This is more or less what I had in mind. Correct me if I'm wrong, but http 1.0 wasn't the invention of the ietf, but sprang forth outside of its purview. Http 1.1 was a response to the many difficulties placed on the net because of http 1.0, and there was an active feedback loop between the http world and the net (ietf) world to adapt both at layer 7 as well as below. Http, after all, was The Big Thing for all parties, so it's not surprising that there was active cross interest. What facinates me about p2p is that it was clearly the next Big Thing, but there seems to be no feedback loop operating whatsoever. I guess that surprises me. Thomas brought up qos/diffserv and operator business models which is certainly something ietf clue level could assist on, but it seems that we neither know them, nor do they know us and that both sets of people seem satisfied with that. I'm not saying that it's bad -- it's just a very surprising outcome. Ought both sides be that confident that the net as engineered today is what it needs to be for this Big Thing and the Big Thing after that? Or that our fertilization is really the correct mix to prepare the ground for the next Big Thing? But we can't prevent people from deploying solutions that we didn't develop, and we shouldn't even try to IMHO. I wasn't suggesting control, but much more that the cross pollination of clue isn't happening and whether we should be alarmed about that. In particular, what does that say about ietf? Some have suggested that it means that we've done our job, but that strikes me as a wee bit too self-satisifed for my taste. Mike ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: BitTorrent (Was: Re: [Isms] ISMS charter broken- onus should be on WG to fix it)
Scott W Brim wrote: On 09/15/2005 17:09 PM, Paul Hoffman allegedly wrote: At 1:50 PM -0700 9/15/05, Michael Thomas wrote: Which is pretty much the elephant in the room, I'd say. How much of the net traffic these days is, essentially, not in any way standardized, and in fact probably considers ietf old and in the way? Not sure why this is an elephant; who cares? I have seen numbers that show that a huge percentage of traffic is P2P of various flavors, but I haven't seen anyone saying that this is having any negative effects. The metaphor I'm trying to use this week is that the IETF is landscapers and we provide a fertile, beautiful area for people to go wild and create excellent gardens. What you're describing is not a bug, it's feature. It means the IETF have done their job. If there were interoperability problems in the fundamental and/or widespread technologies being used in the Internet, then there would be a problem (we're working on those). Congratulations. Perfect. And then someone with less clue decided to plant Kudzu. We have nothing to say about that? I know that we aren't the net.cops, but are we not net.stewards either? Mike, asking. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: BitTorrent (Was: Re: [Isms] ISMS charter broken- onus should be on WG to fix it)
Paul Hoffman wrote: At 1:50 PM -0700 9/15/05, Michael Thomas wrote: Which is pretty much the elephant in the room, I'd say. How much of the net traffic these days is, essentially, not in any way standardized, and in fact probably considers ietf old and in the way? Not sure why this is an elephant; who cares? I'm not sure; maybe it's really a mutual non-admiration society, and everybody's happy? But it's an elephant insofar as it's pretty darn big trafficwise, and the fact that ietf doesn't seem concerned? I have seen numbers that show that a huge percentage of traffic is P2P of various flavors, but I haven't seen anyone saying that this is having any negative effects. I don't think this is _entirely_ true: p2p stuff definitely has, um, interesting effects on, say, voip at home, and some of the p2p apps -- especially the earlier ones if I recall correctly -- had some pretty nasty effects on various networks. Are we to believe that they are largely self-healing problems as bad p2p apps will eventually correct themselves since it's in their interest? Is it reasonable to believe that there is enough general clue that they could be expected to do that? And the collective clue of the ietf is not really needed to help this along? I'll note that many protocols -- good and bad -- spring from somebody's head. Some of them become successful too. Very successful. And ietf has no say about them at all. Is this the new reality? But for layer 7 protocols, file sharing may be the only major market that has wholly ignored the IETF. This isn't that unusual really, but what facinates me is that the reverse seems true as well. Yes, if one that has bad congestion control becomes popular. But, given the mindshare of BitTorrent these past few years, that seems pretty unlikely. But surely BitTorrent isn't the last one that will come along. I guess the base question is this: is the net robust enough to really allow experimentation with flash crowds of millions of alpha testers? So far it has, but we're layering more and more stuff onto the net too -- like voip -- that are pretty sensitive to average expectations (I'm thinking about things like Vonage, not managed services). Is that a danger for the overall internet architecture? That is, is there a price for this benign neglect that has yet to surface? Mike ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: BitTorrent (Was: Re: [Isms] ISMS charter broken- onus should be on WG to fix it)
Paul Hoffman wrote: At 5:32 PM -0700 9/14/05, Michael Thomas wrote: You mean we could invent Bitorrent? :) BitTorrent (note the spelling) does a lot of very nice things, but not those. For those interested, the BitTorrent protocol is described at <http://www.bittorrent.com/protocol.html>. Always the risk when one is being flippant, but I only meant that the world outside of ietf seems to be taking on a lot of these issues without ietf's advice and consent. Mike, doesn't it strike others as odd that ietf is completely outside of the p2p bizness? In this case, there is no advantage to the developer of the protocol to have it worked on in the IETF, nor even published as an RFC. It came out of one person's head, he was able to experiment with it live on the net, and he retains the ability to tweak the specs whenever he feels like it. It has worked remarkably well, given the variety of clients and servers available for the protocol, and the huge amount of traffic that is moved daily over it. Which is pretty much the elephant in the room, I'd say. How much of the net traffic these days is, essentially, not in any way standardized, and in fact probably considers ietf old and in the way? I'll note that many protocols -- good and bad -- spring from somebody's head. Some of them become successful too. Very successful. And ietf has no say about them at all. Is this the new reality? Sure seems like it to me. Should we be concerned? Might there be film at 11 at some point because of it? Mike, or is it too soon for another ietf ossification thread? ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Isms] ISMS charter broken- onus should be on WG to fix it
Ned Freed wrote: Ned Freed wrote: > If I were to object to Eliot's proposal (I don't - in fact I strongly > support > it), it would be on the grounds that the IETF should be taking a long > hard look > at the issues surrounding call home in general, not just in the special > case of > SNMP. I'll bite: what could the IETF do if it looked long and hard? Well, the one approach that immediately comes to mind is that the introduction of a third party might provide a means of getting timely information about software updates without sacrificing user privacy. Such a third party would act as a repository for update information provided by vendors. Applications would then "call home" to one of these repositories rather than directly to the vendor. Various anonymyzing tricks could be employed to minimize information leakage even if the third party was compromised. You mean we could invent Bitorrent? :) Mike, doesn't it strike others as odd that ietf is completely outside of the p2p bizness? ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Isms] ISMS charter broken- onus should be on WG to fix it
Ned Freed wrote: If I were to object to Eliot's proposal (I don't - in fact I strongly support it), it would be on the grounds that the IETF should be taking a long hard look at the issues surrounding call home in general, not just in the special case of SNMP. I'll bite: what could the IETF do if it looked long and hard? Mike ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: ISMS working group and charter problems
Margaret Wasserman wrote: Hi Mike, At 8:41 AM -0700 9/7/05, Michael Thomas wrote: In answer to Margaret's question about how it would know where to "call home", it seems to me to be about the same problem as with traps/informs. I haven't had anything to do with this wg, but it seems pretty plausible that you'd initiate the session from the agent using a trap/inform over tcp/ssh/whatever and then just reuse the connection for subsequent pdu's sort of akin to http 1.1 reuse. It would just all sort of fall out of the overall snmp architecture. So, every time a notification sender sends a trap or notification it would set-up a TCP connection to each of the notification receivers in its list and keep that connection up indefinitely? Would it reestablish ithose connections when they fail? How long would it keep a connections up if it never receives a command request on that particular connection? Please remember that not all notification receivers _are_ command requestors, and not all command requestors are notification receivers. I think there's a fair amount of room between "never" and "indefinitely" on how/when to keep a connection up. As I mentioned, http 1.1 seems to handle this and if nothing else we certain have a lot of data about its efficacy. I do think that if you built a mechanism for a command responder to open a connection to a command requestor, the MIB for configuring the new mechanism might resemble the MIB that is used to determine notifications should be sent, but I don't think that it will be identical and I do not think that the current MIB should be overloaded in this way. Correct me if I'm wrong, but I thought that http 1.1 was pretty spartan on any sort of settings and/or negotiation of the kinds of parameters you brought up. That is, each side decides for itself what those values ought to be, and the provisioning of them is out of scope. Since the web is essentially an any-any kind of environment, is there some reason to believe that a more restrictive relationship -- as one would expect manager to managed to be -- would bring new or different considerations than we already have a lot of experience with? BTW, nothing about your note explains to me why you think that this mechanism should be defined in a Security area WG that is working on a completely separable problem. If you really think that defining call home for SNMP is something that the IETF should do, I would encourage you to get together with Eliot and request a BOF in the OPS area. That's because I haven't formed an opinion on it. My main point is that this doesn't seem to me to be any sort of wildly divergent architectural proposition, at least on the front of who "initiates" a connection. As Harald pointed out, I really can't see how you'd prevent some industrious developers from using SNMP in this way regardless of how the working group is chartered, and from that standpoint it might be better to get ahead of the ball on it if it were inevitable, and it does seem to have a fair number of security considerations. The question I have for Eliot though is why he believes that SNMP is the right vehicle for this kind of "call home" functionality in the first place. Maybe it's my own prejudice, but SNMP seems a little klunky for what I'd envision "call home" is trying to achieve. Mike ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: ISMS working group and charter problems
Brian E Carpenter wrote: And just BTW: I find "call home" reasonable to specify too, once you've done TCP. It's obvious enough that I think it will be added to implementations whether or not we specify it, so we should have very strong reasons not to do so. "Call home" is IMHO a fairly radical departure for SNMP and raises trust model questions that I don't find easy to get hold of. It seems quite distinct from both firewall traversal and NAT traversal, conceptually, even if they might be a side-effect of calling home. Really? What is a trap/inform but a "call home" by another name? In answer to Margaret's question about how it would know where to "call home", it seems to me to be about the same problem as with traps/informs. I haven't had anything to do with this wg, but it seems pretty plausible that you'd initiate the session from the agent using a trap/inform over tcp/ssh/whatever and then just reuse the connection for subsequent pdu's sort of akin to http 1.1 reuse. It would just all sort of fall out of the overall snmp architecture. Mike ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: what is a threat analysis?
This thread began as a complaint against a particular requirement being imposed on a particular pre-working group effort. No it did not. Stop imputing my motives. Mike ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: what is a threat analysis?
Brian E Carpenter wrote: Ned Freed wrote: Brian E Carpenter wrote: > Michael, you've had some quite concrete responses which I hope > have clarified things, but I really want to say that making > Internet protocols secure isn't a hoop jumping exercise; it's > more like a survival requirement, and has been for ten years > at least. Where did I say that? Of course you didn't, and the implication that you did say that was nothing but a strawman, a tactic I'm sad to say often seems to crop up in discussions on the IETF list. Excuse *me* but Mike's note that I was responding to said (in part): So, if this is going to be yet another hoop that the IESG and IAB sends working groups through like problem statements, requirements documents and the like, I think it ought to be incumbent on those people demanding such things to actually both agree and document what it is that they are demanding. He explicitly raised the question of hoop jumping, which for me at least carries a strong implication of pointlessness. That's what I was responding to. So you've fixated on the word "hoop". Fine. Delete it and the original question still stands. More recently he said: Do you seriously think you could write a "threat analysis" given the definition in 2828? which reads "$ threat analysis (I) An analysis of the probability of occurrences and consequences of damaging actions to a system." As a glossary definition, that seems admirably clear. I repeat: could you write a threat analysis based upon the definition in 2828? That was suggested by somebody as being adequately defined for my original question. For a complex case, I'd expect to ask some experts for help in determining the type of threats to be considered in particular. And I would study 3552 carefully, warts and all. But the bottom line is that this is hard work to get right - compare the Security Considerations of RFC 3056 with RFC 3964 for example. The reason I brought this to this list is because there's no clarity about what is meant by a "threat analysis", though it seems to be cropping up more and more in the IETF process (look ma! no hoops!). If it's going to be part of our process, then I think its incumbent on those who want to impose the process to be clear about what they're asking for, and for that process to not be an idiosyncratic. The waste of time here is not the process per se, but the work on drafts, etc, that are not what the person making the demand is asking for. Do you have an objection to clarity in process? Mike ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: what is a threat analysis?
Harald Tveit Alvestrand wrote: One small point. --On 11. august 2005 07:52 -0700 Michael Thomas <[EMAIL PROTECTED]> wrote: Brian E Carpenter wrote: Michael, you've had some quite concrete responses which I hope have clarified things, but I really want to say that making Internet protocols secure isn't a hoop jumping exercise; it's more like a survival requirement, and has been for ten years at least. Where did I say that? My issue is that if people are going to invoke process, they should be prepared to define what the process is. And not just hand waving; concrete pointers to documents that have been through the rough consensus mechanism so that all parties can shoot for a common goal. I did not hear at any stage Russ claiming that asking for a threat analysis was "invoking process". He was asking for information that would allow him to make up his mind about whether or not to support DKIM becoming a WG. Then maybe we can call it a "process gate", or something else entirely. My main point still remains: if you're going to impose conditions, it seems only fair that the conditions be understandable by all concerned, and most especially if multiple people are calling for the same process gate that they actually _agree_ on what constitutes at least the form of fulfillment. This conversation here has thus far not relieved any of my unease that there really is any such agreement across all those who think this is a good process gate. As far as I know, there is no formal process called "ask for a threat analysis". Some people would argue that there should be, and if that argument were to be adopted, it should certainly have guidance attached to it. My feeling is that it's probably a good thing for requirements drafts to talk about. In the case of a security protocol, it seems very reasonable that requirements are derived at least in part from the threats they are intended to address. Non-security protocols would probably do very well to consider up front what the security requirements are in any solution space. Mike ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: what is a threat analysis?
Stephen Kent wrote: Folks, I thought that what Russ asked for was not a threat analysis for DKIM, but a threat analysis for Internet e-mail, the system that DKIM proposes to protect. The idea is that only if we start with a characterization of how and why we believe adversaries attack e-mail, can we evaluate whether any proposed security mechanism, e.g., DKIM, is appropriate, relative to that threat analysis. That's pretty much my guess, but at least 2 other people guessed completely wrong. Which is really why I'm vexed by this -- why should we have to be guessing in the first place? As I said, at least 5 members of the IESG or IAB piped up about this as if it were self evident. Here's something I wrote a while back which I intend to dust off and propose as the basis for a formal requirements draft that we have promised in our charter. Sections 4 and 5 are kind of what I would think of as being asked here as a threat analysis, but as I've stated, I'm not really sure that this jibes with what other people think is being asked for. http://www.mtcc.com/standards/draft-thomas-mass-req-00.txt Mike PS: this still needs some editing, especially in the requirements section, so don't take this as my current position... ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: what is a threat analysis?
Brian E Carpenter wrote:
Michael, you've had some quite concrete responses which I hope
have clarified things, but I really want to say that making
Internet protocols secure isn't a hoop jumping exercise; it's
more like a survival requirement, and has been for ten years
at least.
Where did I say that? My issue is that if people are going
to invoke process, they should be prepared to define what
the process is. And not just hand waving; concrete pointers
to documents that have been through the rough consensus
mechanism so that all parties can shoot for a common
goal.
And to answer your question, no it hasn't been answered
because I've yet to hear from the people -- and there were
many on both the IESG and IAB -- who were asking for it.
Do you seriously think you could write a "threat analysis"
given the definition in 2828?
Mike
Brian
Michael Thomas wrote:
Having a "threat analysis" was brought up at the plenary by Steve
Bellovin as being a Good Thing(tm). At the MASS/DKIM BOF we are
being required to produce such a thing as a prerequisite to even
getting chartered as a working group. The problem that I have (and
Dave Crocker at the plenary) is that there doesn't seem to be
any definition of what a "threat analysis" is. Contrary to what
it seems many people demanding such a thing suppose, the term
isn't self evident. Maybe I've missed it but I'm not sure that
I've ever seen one. Worse, I'm not very sure that the people who
were telling us that we needed one could easily be able to come to
consensus on what constitutes a threat analysis.
So, if this is going to be yet another hoop that the IESG and IAB
sends working groups through like problem statements, requirements
documents and the like, I think it ought to be incumbent on
those people demanding such things to actually both agree and
document what it is that they are demanding. This is not just
annoyance at yet more process on my part, but a real desire to
not have people waste a lot of time producing documents that
fail to meet a definition that is otherwise only determined by
multiple iterations of "that's not what we want". This is, in
fact, what happened this time around, and has happened in the
past with the SIP wg.
Mike
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
what is a threat analysis?
Having a "threat analysis" was brought up at the plenary by Steve Bellovin as being a Good Thing(tm). At the MASS/DKIM BOF we are being required to produce such a thing as a prerequisite to even getting chartered as a working group. The problem that I have (and Dave Crocker at the plenary) is that there doesn't seem to be any definition of what a "threat analysis" is. Contrary to what it seems many people demanding such a thing suppose, the term isn't self evident. Maybe I've missed it but I'm not sure that I've ever seen one. Worse, I'm not very sure that the people who were telling us that we needed one could easily be able to come to consensus on what constitutes a threat analysis. So, if this is going to be yet another hoop that the IESG and IAB sends working groups through like problem statements, requirements documents and the like, I think it ought to be incumbent on those people demanding such things to actually both agree and document what it is that they are demanding. This is not just annoyance at yet more process on my part, but a real desire to not have people waste a lot of time producing documents that fail to meet a definition that is otherwise only determined by multiple iterations of "that's not what we want". This is, in fact, what happened this time around, and has happened in the past with the SIP wg. Mike ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Port numbers and IPv6
Ned Freed wrote: Mind you, I'm not saying that TCP needs to be redesigned ASAP to allow for a larger number of source ports. IMO the pain would probably outweigh the gain. But that doesn't mean nobody is hitting the 65536 limit imposed by source port numbers. They are, it causes problems, and this needs to be kept in mind. Out of curiosity, doesn't SCTP have a bigger port space (or its moral equivalent)? If so, would that be a better option? Mike ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: BOF: SLRRP
On Wed, 2005-02-23 at 10:32, Marshall Rose wrote: > may i draw your attention to the Simple Lightweight RFID Reader > Protocol BOF being held at IETF 62? Isn't putting not just one, but _two_ diminutives into a name severely tempting the gods? Mike signature.asc Description: This is a digitally signed message part ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Excellent choice for summer meeting location!
On Fri, 2004-12-31 at 12:39, Glen Zorn (gwz) wrote: > > let's keep going to minneapolis for as long as they'll tolerate > us, > > and let's try to find summertime destinations that are equally > > appalling to the MFLD community. paris, in that regard, should be > > OFF the table. > > Don't worry, O Calvinist Guardian of Virtue: there is little > pleasure to be found in Paris in August; the cafes will be > shuttered, even the cab drivers will have left the city. IETF puritanism: the haunting fear that someone, somewhere might be having a bottle of Lamarche Vosne Romanee "La Grande Rue". Mike, '88 was a pretty good year signature.asc Description: This is a digitally signed message part ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Why, technically, MIP and IPv6 can't be deployed
I think that this begs the question of where the larger problem lies: while IP can run over pigeons, bailing wire and quite possibly chewing gum, there are clearly some media that IP runs over better. Looking at the various wireless media, they are either somewhere between completely hopeless (cellular with its purpose built PSTN roots) to "overhelpful" (bluetooth) to sort of ok for a first order approximation (802.11). IMO, what we need are radio networks whose L1/L2's are built with IP in mind first and foremost -- not afterthoughts, not "one of many". There are surely some things that IP -- both v4 and v6 -- could do better, but what they will never be able to do is work well over a broken L1/L2. Until we have wireless media which are trying to work with rather than at cross purposes with IP, it really doesn't matter what IETF specifies. Finally: I rather get annoyed when L1/L2 people tell me "that's not the way our L1/L2 works!", blah, blah, blah. Fine. Engineer us something that does work; stop telling us to engineer for broken media. IP has won in the marketplace in case they have been asleep for the last 10 years. Mike On Tue, 2004-11-09 at 04:14, Masataka Ohta wrote: > Tim Chown wrote: > > IPv6 is defective in so many ways. But, w.r.t. WLAN, here is the > reason. > > > Could you describe why exactly IPv6 can't run on the (layer 2?) WLAN > > infrastructure? > > That ND extensively, without any valid reason to do so, use > multicast, which is not acknowledged at WLAN L2, means IPv6 > or its ND is unreliable over congested WLAN. If multicast > ND packet is lost by congestion, it is not retransmitted by L2. > > MIP failed mostly because there has been no standards MIP over > link technologies, which are adaptation layers between L2 and L3. > > RFC2002 does not specify anything about how CoA addresses can > be obtained, which is fine, if and only if there are other > specifications on link or provider dependent ways to do so. > > IPv6 made it worse by trying to standardize ND as *THE* adaptation > mechanism, even though the mechanism *MUST* depend on details of > L2 and *MUST* be different L2 by L2. > > As a result, IPv6 won't stably run over WLAN, multicast over which > has characteristics much different from wired Ether. > > Masataka Ohta > > > > ___ > Ietf mailing list > [EMAIL PROTECTED] > https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF60: time needed for check-in at San Diego?
Michael Richardson writes: > -BEGIN PGP SIGNED MESSAGE- > > > > "Fred" == Fred Baker <[EMAIL PROTECTED]> writes: > >> Try to get a direct flight or through San Francisco. > > Fred> I hear that. But (west coast perspective...) I avoid SFO like > Fred> the plague. When fog sets in, they shut down one runway, and > Fred> flights throughout the US get delayed. And what is San > Fred> Francisco famous for? > > Ah, but that's why the lineup at SFO is so much shorter! > And, if the flights are delayed, it's okay if the lineup is longer. It's clear and sunny here today. Can't imagine what this scurrilous "fog" hearsay that Fred's on about. Mike, but west of twin peaks doesn't count ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Chinese IPv9
JORDI PALET MARTINEZ writes: > Complete compilation of news at > http://www.ist-ipv6.org/modules.php?op=modload&name=News&file=article&sid=622 > > But I guess is an hoax ? Or the revenge of J*m Fl*mm*ng? Mike, 4 is to 6 as 6 is to 9? > > - Original Message - > From: <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Monday, July 05, 2004 5:05 PM > Subject: RE: Chinese IPv9 > > > > See also: > > > > http://www.chinatechnews.com/index.php?action=show&type=news&id=1405 > > > > Google gives about 4000 hits for IPv9. > > > > Including of course RFC 1606 > > > > :-) > > > > Gordon > > > > -Original Message- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of > > [EMAIL PROTECTED] > > Sent: Monday, July 05, 2004 3:15 PM > > To: [EMAIL PROTECTED] > > Subject: Chinese IPv9 > > > > > > Hi, > > > > a german computer magazine reported that China > > is developing their own IP address scheme as > > IPv9 ( http://www.heise.de/newsticker/meldung/48859 ) > > in order to improve "security" (probably spelled: censorship). > > They cite > > > > http://news.xinhuanet.com/english/2004-07/05/content_1572719.htm > > > > It is to be used inside China, and they will have routers > > as gateways to ipv4 and ipv6 and the borders of China > > (obviously not letting everything pass through). > > > > Does anyone know details about this protocol? > > > > What's the IETF's opinion (if IETF does have anything like an > > IETF's opinion) about such an effort? > > > > regards > > Hadmut > > > > > > > > ___ > > Ietf mailing list > > [EMAIL PROTECTED] > > https://www1.ietf.org/mailman/listinfo/ietf > > > > ___ > > Ietf mailing list > > [EMAIL PROTECTED] > > https://www1.ietf.org/mailman/listinfo/ietf > > > > > ** > Madrid 2003 Global IPv6 Summit > Presentations and videos on line at: > http://www.ipv6-es.com > > This electronic message contains information which may be privileged or > confidential. The information is intended to be for the use of the individual(s) > named above. If you are not the intended recipient be aware that any disclosure, > copying, distribution or use of the contents of this information, including > attached files, is prohibited. > > > > > ___ > Ietf mailing list > [EMAIL PROTECTED] > https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: spoofing email addresses
Perry E. Metzger writes: > I think the easy solution is just to block port 25 You can stop right there. The rest is so much wishful thinking. Mike > unless someone asks > for it to be opened. Average users have no idea what > port 25 does or even what TCP is, so they won't care. > > Perry > > ___ > Ietf mailing list > [EMAIL PROTECTED] > https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
