Re: IESG proposed statement on the IETF mission
Harald - I would agree that you are right here that the IETF's mission process and in fact operations have fluttered in the breeze but the breeze was caused by whoever was chair at the time's running by or away from the key issue that they as the chair were given the ability because of a very weak charter and very ambiguous processes (may instead of must everywhere) create whatever it is they wanted. The issue is that the wants and mandates of the chair's have changed over the years and so the IETF has changed in response to that. What that tends to indicate is that the IETF is responsive to changes in its management's desires but not in the proletariat's... So then what I suggest is the answer is a more rigidized standards process and in particular a set of unambiguous policies and procedures that are at least modeled if not tested before being released. And that are in and of themselves the same for all they are applied to or around. Todd Glassey - Original Message - From: Harald Tveit Alvestrand [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Sunday, October 26, 2003 9:44 PM Subject: RE: IESG proposed statement on the IETF mission --On 24. oktober 2003 18:07 +0300 [EMAIL PROTECTED] wrote: Hi Harald, I'm going to pick on one statement, which other have as well. It is important that this is For the Internet, and does not include everything that happens to use IP. IP is being used in a myriad of real-world applications, such as controlling street lights, but the IETF does not standardize those applications. I almost feel that this should just be dropped from the statement. My reasons being that I have been told by the IESG about protocol extensibility is that the IETF wants to have a tighter control over protocol extensibility, even for extensions thought to be for limited use or specific networks (for example, cellular networks). The reason being is that once something is out there, it often starts to be used in ways which were not originally planned or used outside of its original 'limited use' plans. Therefore, in order to ensure proper protocol behavior interoperability, the IESG wants to manage extensibility. This has been very true in SIP Diameter, for example. True. Nearly a year ago, we attempted to publish draft-iesg-vendor-extensions, to describe these problems in more detail - but we failed to get that finished. On the other hand, we see a protocol like RADIUS, which the IETF has never done a good job at working with or standardizing, being developed in 4 or more SDOs, and not in a colaborative manner. This makes a big mess with the RADIUS spec, and RADIUS does seem like a protocol that has a big effect on the Internet. You'll have no disagreement from me that RADIUS is a problem! So, in summary, the IESG has shown not to follow the above paragraph, sometimes even for good reasons. I can't think of a way in which modify the paragraph to make it any better - because there will always be examples of work that the IETF choses to standardize (or not) which will violate that part of the mission. Perhaps moving the 'for the internet to the previous paragraph is what is needed. as I've said before - I don't think we can come up with a mission statement that retroactively blesses everything we've done well before, or retroactively curses everything we've done badly. And we do require flexibility to do what's right. But without the ability to talk about what the mission of the IETF ... I think we'll do badly. Harald
RE: IESG proposed statement on the IETF mission
Harald, I almost feel that this should just be dropped from the statement. My reasons being that I have been told by the IESG about protocol extensibility is that the IETF wants to have a tighter control over protocol extensibility, even for extensions thought to be for limited use or specific networks (for example, cellular networks). The reason being is that once something is out there, it often starts to be used in ways which were not originally planned or used outside of its original 'limited use' plans. Therefore, in order to ensure proper protocol behavior interoperability, the IESG wants to manage extensibility. This has been very true in SIP Diameter, for example. True. Nearly a year ago, we attempted to publish draft-iesg-vendor-extensions, to describe these problems in more detail - but we failed to get that finished. So, I think we have to be careful about what we consider part of the IETF mission, if we cannot get basic agreement upon the implications of the mission statement. On the other hand, we see a protocol like RADIUS, which the IETF has never done a good job at working with or standardizing, being developed in 4 or more SDOs, and not in a colaborative manner. This makes a big mess with the RADIUS spec, and RADIUS does seem like a protocol that has a big effect on the Internet. You'll have no disagreement from me that RADIUS is a problem! So, in summary, the IESG has shown not to follow the above paragraph, sometimes even for good reasons. I can't think of a way in which modify the paragraph to make it any better - because there will always be examples of work that the IETF choses to standardize (or not) which will violate that part of the mission. Perhaps moving the 'for the internet to the previous paragraph is what is needed. as I've said before - I don't think we can come up with a mission statement that retroactively blesses everything we've done well before, or retroactively curses everything we've done badly. And we do require flexibility to do what's right. But without the ability to talk about what the mission of the IETF ... I think we'll do badly. The past is the past, I don't want to revisit the past. What I want to do is to look forward. We should have flexibility in terms of how to decide what the IETF can do, what it can't do and what it should (or shouldn't do). I think we cannot make a blanket statement in the mission that covers this. thanks, John
Re: IESG proposed statement on the IETF mission
- Original Message - From: Harald Tveit Alvestrand [EMAIL PROTECTED] True. Nearly a year ago, we attempted to publish draft-iesg-vendor-extensions, to describe these problems in more detail - but we failed to get that finished. I should probably get out more, but I wasn't familiar with this draft. I see that version 00 was announced. It looks to have been discussed in a couple of posts on ccamp (and mpls? but I didn't look), and revectored onto the main IETF discussion list, where it was the subject of two posts. The draft says The initial version of this document was put together by the IESG, suggesting that they were asking for input or other forms of help, but that didn't happen. (In your opinion:) Was this a case of insufficient agreement, or a case of insufficient cycles? Or something else? Spencer
RE: IESG proposed statement on the IETF mission
--On 24. oktober 2003 18:07 +0300 [EMAIL PROTECTED] wrote: Hi Harald, I'm going to pick on one statement, which other have as well. It is important that this is For the Internet, and does not include everything that happens to use IP. IP is being used in a myriad of real-world applications, such as controlling street lights, but the IETF does not standardize those applications. I almost feel that this should just be dropped from the statement. My reasons being that I have been told by the IESG about protocol extensibility is that the IETF wants to have a tighter control over protocol extensibility, even for extensions thought to be for limited use or specific networks (for example, cellular networks). The reason being is that once something is out there, it often starts to be used in ways which were not originally planned or used outside of its original 'limited use' plans. Therefore, in order to ensure proper protocol behavior interoperability, the IESG wants to manage extensibility. This has been very true in SIP Diameter, for example. True. Nearly a year ago, we attempted to publish draft-iesg-vendor-extensions, to describe these problems in more detail - but we failed to get that finished. On the other hand, we see a protocol like RADIUS, which the IETF has never done a good job at working with or standardizing, being developed in 4 or more SDOs, and not in a colaborative manner. This makes a big mess with the RADIUS spec, and RADIUS does seem like a protocol that has a big effect on the Internet. You'll have no disagreement from me that RADIUS is a problem! So, in summary, the IESG has shown not to follow the above paragraph, sometimes even for good reasons. I can't think of a way in which modify the paragraph to make it any better - because there will always be examples of work that the IETF choses to standardize (or not) which will violate that part of the mission. Perhaps moving the 'for the internet to the previous paragraph is what is needed. as I've said before - I don't think we can come up with a mission statement that retroactively blesses everything we've done well before, or retroactively curses everything we've done badly. And we do require flexibility to do what's right. But without the ability to talk about what the mission of the IETF ... I think we'll do badly. Harald
RE: IESG proposed statement on the IETF mission
Hi Harald, I'm going to pick on one statement, which other have as well. It is important that this is For the Internet, and does not include everything that happens to use IP. IP is being used in a myriad of real-world applications, such as controlling street lights, but the IETF does not standardize those applications. I almost feel that this should just be dropped from the statement. My reasons being that I have been told by the IESG about protocol extensibility is that the IETF wants to have a tighter control over protocol extensibility, even for extensions thought to be for limited use or specific networks (for example, cellular networks). The reason being is that once something is out there, it often starts to be used in ways which were not originally planned or used outside of its original 'limited use' plans. Therefore, in order to ensure proper protocol behavior interoperability, the IESG wants to manage extensibility. This has been very true in SIP Diameter, for example. On the other hand, we see a protocol like RADIUS, which the IETF has never done a good job at working with or standardizing, being developed in 4 or more SDOs, and not in a colaborative manner. This makes a big mess with the RADIUS spec, and RADIUS does seem like a protocol that has a big effect on the Internet. So, in summary, the IESG has shown not to follow the above paragraph, sometimes even for good reasons. I can't think of a way in which modify the paragraph to make it any better - because there will always be examples of work that the IETF choses to standardize (or not) which will violate that part of the mission. Perhaps moving the 'for the internet to the previous paragraph is what is needed. This leaves open the very interesting and difficult questions of how to measure quality, relevance, and timeliness. The IETF has identified interoperability, security, scalability and 'for the Internet' as essential, but without attaching measurements to those characteristics. John
Re: IETF mission boundaries (Re: IESG proposed statement on the IETF mission )
-BEGIN PGP SIGNED MESSAGE- Harald == Harald Tveit Alvestrand [EMAIL PROTECTED] writes: Harald In the discussions leading up to this document, we actually had 3 Harald different other levels of inclusivity up for consideration: okay, I very much like these descriptions. Harald - Everything that runs over the Internet is appropriate for IETF Harald standardization. Harald - Everything that needs open, documented interoperability and Harald runs over the Internet is appropriate for IETF Harald standardization. Harald - Everything that builds infrastructures on the Internet that Harald needs to be open and interoperable is appropriate for IETF Harald standardization. These are three levels that I understand, and each seems to enclose the next. Harald - Everything that can seriously impact the Internet is Harald appropriate for IETF standardization. This is very much more nebulous, because seriously impact is a question of very open judgement. ] Collecting stories about my dad: http://www.sandelman.ca/cjr/ | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[ ] [EMAIL PROTECTED] http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic(Just another Debian/notebook using, kernel hacking, security guy); [ -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys - custom hacks make this fully PGP2 compat iQCVAwUBP5g84oqHRg3pndX9AQH01AP/ayMZ2WJVxz7xZXVSu9Pbew9U1A+GLUFb PVgK45qNL/qsL95U4cU1SyV5Tn2YYTjWkSD4j8tVNHAX+HyoqDJPYgWFwevOKblY HCwUj3N6Y/U43TpIZ8+w8NqcIkV0Z4BPc9kjpSjiUeTOZ4nfY+Pbg3yS+vaUvWcd ThqgtWgB7Lc= =p3P3 -END PGP SIGNATURE-
Re: IESG proposed statement on the IETF mission
So yes Dean, I think you elude to the central issue - what is the common interest, and as the community was propelled almost forceably, and inexorably by market forces from a world where as Randy put it operators cooperated together, in a non-commercial endeavor based on very non-commercial values, into a very commercial world, did the community ever have a chance to take a big breath, inspect what has happened, and where it really wants to go from here. Ok, here is MY opinion on the central issue: Deployed communications systems are either military or commercial. Pure research doesn't deploy systems. OC-192 equipment and millions of miles of fiber aren't cheap. Those complaining about how great things were when they were non-commercial were preceeded by people complaining about working for the military. The people who don't want to service the commercial sector, and don't want to service the military sector, really don't realistically have much of a place in our society outside of pure research, and shouldn't be given control over the future commercial or military applications of the internet. But it comes down to a question of whether science serves public policy or whether public policy serves science. Which is the tail, and which is the dog? There is room for some pure science for nothing other than the sake of pure science, but most of the research has to be done for productive commercial or military purposes. I think this is a pretty general statement that is as true of biotech research as it is of communications research. And since the internet is now vastly commercial, and international, the leaders of the IETF ought to focus research on things that will be commercially useful. The present situation, in my opinion, the tail is wagging the dog. This should be changed. The IETF mission should make clear what the constituencies are, what the goals are, and what the priorities are, so that the tail does the wagging. It used to be that engineering and operations within a company cooperated together, sharing work and, of course, passwords. In small companies, this is still be true. But in many large telecom companies, engineering is denied access to the production systems, and only the operations staff can make changes. This is necessary to ensure commercial stability, since custom engineering changes don't scale well, and don't lead to widely stable systems, since the custom changes may not be made on all systems. Large groups work at arms length, even within a company, with well defined protocols and policies regarding who can do what. Of course, there are inevitable disagreements between engineering, operations, sales, etc. These are resolved civilly, within the organization, and may include appeals to senior management. Those that know me, know that I'm usually working in the engineering group, which means I am sometimes arguing with the operations group for access to a newly deployed production system. The first few times, I usually win. But I either have to stop asking or lose these disgreements, in favor of documented troubleshooting procedures for the benefit of improved stability. There are good reasons that practices that might have been nice for small companies are abandoned by big companies. The IETF has this same issue. Clearly, there are going to be even greater problems when many companies come together to work on the same problems. It is not reasonable to expect that a few people can just cooperate together and work something out for a large community. What worked for the Internet many years ago isn't going to work again--ever again--anymore than it would work for a large telecom company to share passwords between engineering and operations. --Dean
Re: IETF mission boundaries (Re: IESG proposed statement on the IETF mission )
The number of application protocols with the oomph to break the Internet is quite small however, it's not safe to assume that it's zero. any new killer app that were poorly designed could do it. also, you might be underestimating the damage done by HTTP (1.0 or later).
Re: IETF mission boundaries (Re: IESG proposed statement on the IETF mission )
The number of application protocols with the oomph to break the Internet is quite small OK, I've gotta ask - how many times do we break the Internet before we reverse this reasoning? (How many times is too many?) (signed) curious
Re: IESG proposed statement on the IETF mission
Dean Anderson wrote: On Thu, 16 Oct 2003, mark seery wrote: Trust model = Inherent in Eric's problem statement is the notion that end systems have the ability to impact the experience other Internet users have. Whether this is the result of an historical trust model, where people using the Internet were assumed to a) have clue and b) be acting in the best interests of the community, or whether this is the result of other community values, this diserves comment/debate, IMHO. I've noticed that the people who claim to have the most clue, frequently don't, ...most imposters are desperate to prove that they are not what they are... - Katherine Hepburn, Love Story that said, no one has clue in everything, and in almost any one thing, there is almost always some one with more clue, so this too is relative. and the people who claim most to be acting in the interests of the community, aren't. Patriotism is the last refuge of a scoundrel. - Samuel Johnson. that said there is a lot that is instructive about listening to the ghosts from the past. lessons in open processes as an immutable value for example. Clue has to do with being right, and time always reveals who and what is right. It is not always immediately apparent who is right. But the one with the clue will be shown to have been right later on But the assasination has usually taken place by then. The lesson of almost any complex society is dare to be different, and the gods will exact their revenge. It takes people of courage, stupidty or independent wealth to truly express what they think. That is why secret ballots exist in many democracies - it allows a broader range of non-stupid people to express their opinion (all beit on a narrow decision criteria). Community has to do with democratic, common interests. It is always interesting that the people who are most shrill about the interests community often want to exclude most of the community from the decision. Common interests I agree, which I think is probably the crux of the mission discussion. Whether a statement or any other single instrument is sufficient to cross this bridge is fair game for discussion. But undoubtely, IMHO, it is the definition, articulation, and recognition of what the common interest is that is the problem at hand. For example, I don't think IEEE 802.3 have any problems understanding what their common interest is - the propogation of Ethernet technology - with no qualms about the commercial realities of that common interest. What is the common interest of the IETF? Packets to the people? The propogation and use of IP (including Eric's expression of migrating applications from other technologies)? The refinement and perfection of connectionless networking techology? The development/standardization of technologies that address as many networking problem spaces as possible forming an umbrella under which we can throw many things by calling it the Internet? So yes Dean, I think you elude to the central issue - what is the common interest, and as the community was propelled almost forceably, and inexorably by market forces from a world where as Randy put it operators cooperated together, in a non-commercial endeavor based on very non-commercial values, into a very commercial world, did the community ever have a chance to take a big breath, inspect what has happened, and where it really wants to go from here. Given the seeminly overloaded semantics of mission perhaps a statement of common interest would indeed be more beneficial. As for the democratic bit, I have been giving a lot of thought recently to what a democracy is or should be - as such I am not sure what democratic is, so I leave that piece as an exercise to the reader. Best,..
Re: IESG proposed statement on the IETF mission
On Wednesday, October 15, 2003, at 12:57 PM, Eric Rosen wrote: The purpose of the IETF is to create high quality, relevant, and timely standards for the Internet. It is important that this is For the Internet, and does not include everything that happens to use IP. IP is being used in a myriad of real-world applications, such as controlling street lights, but the IETF does not standardize those applications. Yes, and towards a possibly more contentious application, see Voice over IP. Lots of VoIP work is being done without involving the internet at all. Used by telecoms for telecoms applications, where best effort isn't good enough because it needs to keep working when the power goes out. IP, yes, Internet, no. Against that you have voice over internet which is AKA voice chat and already abounds in true internet p2p apps like iChat, GnomeMeeting, and some programs on that other OS. These run on the public internet and benefit from the IETF design paradigms like edge-to-edge (aka end2end) and best effort but also have to accept the relevant drawbacks. simon Well, let's test this assertion. Suppose a consortium of electric companies develops a UDP-based protocol for monitoring and controlling street lights. It turns out that this protocol generates an unbounded amount of traffic (say, proportional to the square of the number of street lights in the world), has no congestion control, and no security, but is expected to run over the Internet. According to you, this has nothing to do with the IETF. It might result in the congestive collapse of the Internet, but who cares, the IETF doesn't do street lights. I would like to see the criteria which determine that telephones belong on the Internet but street lights don't! Another problem with your formulation is that the Internet is a growing, changing, entity, so for the Internet often means for what I think the Internet should be in a few years, and this is then a completely unobjective criterion. One would hope instead that the IETF would want to encourage competition between different views of Internet evolution, as the competition of ideas is the way to make progress. I also do not understand whether for the Internet means something different than for IP networking or not. I think it should also be part of the mission to produce standards that facilitate the migration to IP of applications and infrastructures that use legacy networking technologies. Such migration seems to be good for the Internet, but I don't know if it is for the Internet or not. -- www.simonwoodside.com :: www.openict.net :: www.semacode.org 99% Devil, 1% Angel
Re: IESG proposed statement on the IETF mission
Simon Woodside; Yes, and towards a possibly more contentious application, see Voice over IP. Lots of VoIP work is being done without involving the internet at all. Used by telecoms for telecoms applications, where best effort isn't good enough because it needs to keep working when the power goes out. IP, yes, Internet, no. Why, do you think, the Internet may stop working when the power goes out? It should not, which is required to certain ISPs by regulation at least in Japan. Against that you have voice over internet which is AKA voice chat and already abounds in true internet p2p apps like iChat, GnomeMeeting, and some programs on that other OS. These run on the public internet and benefit from the IETF design paradigms like edge-to-edge (aka end2end) and best effort but also have to accept the relevant drawbacks. voice chat? Are you assuming PCs? POTS telephone devices and terminal adaptors is the natural way of voice over the Internet. Note that end to end architecture means ultimate availability of fate sharing. Masataka Ohta PS According to the end to end principle, end user equipments should have their own power backup, of course, which is also the case with ISDN TA or cellular phone devices. Then, with multihoming, your connection is a lot more robust than that of a single telephone company.
Re: IETF mission boundaries (Re: IESG proposed statement on the IETF mission )
From: Eric Rosen [EMAIL PROTECTED] ... Sheesh!--next you'll be telling us that you never heard the phrase out of scope before last week. Sure I have. There's hardly a piece of work done by the IETF that someone hasn't claimed to be out of scope. It's just that the phrase is not used consistently. That's true. If we look at the historical facts about the work that the IETF has traditionally taken on, it's hard to draw any conclusion other than that anything is in scope which promotes and facilitates the use of the Internet and of IP infrastructure. And I think that's exactly what the IETF should be doing. That's wrong. At best it's meaningless. For example it supports lobbying Congress. The example I'm thinking about involved predecessors to OpenGL. As this example doesn't even involve communication over a network, I would agree that it is out of scope. ... It was out of scope, but not because it did not involve putting graphics stuff over UDP or TCP, because it did. My fellow employees in SGI's network group and I breathed a sigh of releaf when Ron returned from an IETF meeting to report that out of scope had carried the day against other IETF participants who thought that knowing people who knew about Nagle and congestion control and avoidance was enough to design graphics remote procedure calls or similar. It's not that other examples such as X couldn't have used more network knowledge to avoid problems (e.g. the mouse stuff), but that the network stuff is the tail of that and many other dogs. Because of my employement history, I may know a little more about how to do graphics in general or over IP networks than many IETF participants, but I know that I'm abjectly completely utterly incompetent for doing exactly what the IETF started to do in that case. Often the brutal WG chairs say they don't think the WG knows enough, but it's the scope arguments that carry the day. I've never had much luck myself with scope arguments, unless they could be backed up with an argument either that the center of expertise is elsewhere, or that the topic has no bearing on IP. Of course, people will sometimes be willing to agree that the center of expertise is elsewhere without necessarily agreeing that they themselves aren't experts ;-) Sometimes scope arguments are merely face-saving ways of saying we don't know what we are doing. Other times, scope arguments are merely polite ways of saying we don't think you know what you are doing. You almost never hear someone saying that sounds like a really good idea, but unfortunately it is out of scope. Yes, with the proviso that you mean you usually don't hear people really meaning that last sentence. You certainly hear those words a lot. If out of scope were removed as an acceptable reason to not do things, then you would never squelch bad efforts. I suspect the whole effort of defining IETF charters or missions is a very bad idea. It's often better to not spell things out, but to rely on the good judgement of the people running the show. Vernon Schryver[EMAIL PROTECTED]
Re: IETF mission boundaries (Re: IESG proposed statement on the IETF mission )
Scoping is certainly used successfully as an argument at the WG level, through the more common pronnouncement that would require a change to the charter.. Scoping aids WGs in being able to move the ball forward in the direction of predfined goals, and hence is a process aid. This is scoping at a micro level. I would think that the role of mission is to provide scoping at a macro level, the kind of scoping that determines whether a WG is established in the first place or not. More importantly I would suggest, the simple requirement for making binary decisions about whether something is in scope or not is necessary but not sufficient. An institution surely needs some way to guide its priorities as well. So one could for example agree with Eric's definition of what the IETF's mission is, but once that is done, what then guides the priorities of the IETF? I think you will find this to be at the heart of the debate: scoping=smaller workload=focused differentiation in the standards marketplace+better quality output. Every entity must decide what it is going to do uniquly better than any other entity. This is the purpose of mission. Generic catchall missions do not help entities keep the eye on that particular ball.
Re: IETF mission boundaries (Re: IESG proposed statement on the IETF mission )
The example I'm thinking about involved predecessors to OpenGL. As this example doesn't even involve communication over a network, I would agree that it is out of scope. ... [OpenGL example] It's not that other examples such as X couldn't have used more network knowledge to avoid problems (e.g. the mouse stuff), but that the network stuff is the tail of that and many other dogs. Because of my employement history, I may know a little more about how to do graphics in general or over IP networks than many IETF participants, but I know that I'm abjectly completely utterly incompetent for doing exactly what the IETF started to do in that case. Great scope example. The issue for OpenGL, however, demonstrates a gap in as much as the developers would probably have liked something like dccp so that they could use a library to get Nagle, backoff, etc. While we're a wire protocol sort of a group, we all should realize the importance of generality and good library support ;-) If out of scope were removed as an acceptable reason to not do things, then you would never squelch bad efforts. An effort isn't bad because it's out of scope. An effort is bad because it's bad, and we invest our faith in the IESG that they will use good judgment to catch bad efforts. If anyone on the IESG does not feel empowered to say no they should not be on the IESG. WG chairs need to vet their own group's work first, of course. And we could certainly do a better job on that. Eliot
Re: IESG proposed statement on the IETF mission
On Thu, 16 Oct 2003, mark seery wrote: Trust model = Inherent in Eric's problem statement is the notion that end systems have the ability to impact the experience other Internet users have. Whether this is the result of an historical trust model, where people using the Internet were assumed to a) have clue and b) be acting in the best interests of the community, or whether this is the result of other community values, this diserves comment/debate, IMHO. I've noticed that the people who claim to have the most clue, frequently don't, and the people who claim most to be acting in the interests of the community, aren't. Clue has to do with being right, and time always reveals who and what is right. It is not always immediately apparent who is right. But the one with the clue will be shown to have been right later on. Community has to do with democratic, common interests. It is always interesting that the people who are most shrill about the interests community often want to exclude most of the community from the decision. Therein lies the problem. --Dean
Re: IETF mission boundaries (Re: IESG proposed statement on the IETF mission )
The gist of this comment is that someone developing a network application protocol ought to somehow get a blessing from the IETF. Reality check. Who got the IETF approval to deploy ICQ, Kazaa, or for that matter HTTP? The fact that someone did something without the IETF's approval does not imply that what they did is outside the scope of the IETF, or that it is beyond the IETF's mission.
RE: IETF mission boundaries (Re: IESG proposed statement on the IETF mission )
According to you, this has nothing to do with the IETF. It might result in the congestive collapse of the Internet, but who cares, the IETF doesn't do street lights. I would like to see the criteria which determine that telephones belong on the Internet but street lights don't! thanks for making the most concise statement of the conflict here in the discussion so far! I think this point is one of the critical causes of conflict when talking about the IETF mission - and unless we lance the boil, actually talk about it, and attempt to *resolve* the issue, we will go on revisiting the issue forever, with nothing but wasted energy to show for it. Well, to paraphrase a well known leader, the IETF, how many divisions? The gist of this comment is that someone developing a network application protocol ought to somehow get a blessing from the IETF. Reality check. Who got the IETF approval to deploy ICQ, Kazaa, or for that matter HTTP? If the Internet is so fragile that a poorly developed application can break it, then the IETF response should not be to try control each application. It has to be, design checks that can be implemented by cooperating hosts and routers so that their neck of the Internet is in good health! -- Christian Huitema
Re: IESG proposed statement on the IETF mission
since both you and Scott pointed out this one --On 15. oktober 2003 12:48 -0400 Keith Moore [EMAIL PROTECTED] wrote: The purpose of the IETF is to create high quality, relevant, and timely standards for the Internet. I actually believe IETF has a somewhat wider purpose than that. What I usually say is we're trying to help the Internet work better. my personal belief is that the purpose of the *Internet technical community* is to make the Internet work better. But we have to admit to division of labor, and the part that we call the IETF needs to concentrate on standards, and the supporting functions of fora for experimentation and gathering of operational experience. Others do the work of pulling fiber, designing routers, arresting spammers and detecting virii. We, gathered as the IETF, should not (IMHO) attempt to take over those functions. Despite the fact that it's what many of us do when we're not doing IETF stuff! Harald
Re: IETF mission boundaries (Re: IESG proposed statement on the IETF mission )
--On 16. oktober 2003 13:15 -0400 Eric Rosen [EMAIL PROTECTED] wrote: - For the Internet - only the stuff that is directly involved in making the Internet work is included in the IETF's scope. In other words, routing, DNS, and Internet operations/management. Adopting this as the IETF's mission would be a very radical change indeed! I erred in describing that category. I should have used something else - it was not what the IESG thought it was saying in its proposed mission statement, so me recycling the term for the Internet in the bulleted list I made added confusion rather than clarifying. Sorry! (I still think it's a valid point on the scale. It leaves us with a much smaller IETF. But some people tend to think that's a positive side.) Harald
RE: IETF mission boundaries (Re: IESG proposed statement on the IETF mission )
Christian, we might be looking through opposite ends of this tunnel. --On 16. oktober 2003 15:15 -0700 Christian Huitema [EMAIL PROTECTED] wrote: I think this point is one of the critical causes of conflict when talking about the IETF mission - and unless we lance the boil, actually talk about it, and attempt to *resolve* the issue, we will go on revisiting the issue forever, with nothing but wasted energy to show for it. Well, to paraphrase a well known leader, the IETF, how many divisions? The gist of this comment is that someone developing a network application protocol ought to somehow get a blessing from the IETF. Reality check. Who got the IETF approval to deploy ICQ, Kazaa, or for that matter HTTP? For application protocols, I view it in the opposite direction - if someone comes to the IETF and *asks* for the IETF's advice, blessing or ownership, what are the conditions under which we say yes? Or no? For those that never ask, and never become important, I say not my problem. The number of application protocols with the oomph to break the Internet is quite small - offhand, I'd say that HTTP/1.0 probably was the closest try. If the Internet is so fragile that a poorly developed application can break it, then the IETF response should not be to try control each application. It has to be, design checks that can be implemented by cooperating hosts and routers so that their neck of the Internet is in good health! Now there's an idea. :-) The flipside is of course with those things that are *already* under IETF control, or critical for our infrastructure, for some reason. The abstracted version of the fights over MIME types, URI schemes, SIP extension etcetera seems to be don't extend until you've talked to us about what you're doing, and if we don't like it, don't try to pretend that we did (the P-headers, vnd. MIME types and the proposed faceted URI schemes); I'm not certain what the abstracted version of the fights over COPS, CR-LDP, RSVP-TE and so on are. The IETF has got fewer divisions than the Pope, of course. Anyone is free to ignore us. And we need to remember that, sometimes.
IETF mission boundaries (Re: IESG proposed statement on the IETF mission )
Eric, --On 15. oktober 2003 12:57 -0400 Eric Rosen [EMAIL PROTECTED] wrote: Well, let's test this assertion. Suppose a consortium of electric companies develops a UDP-based protocol for monitoring and controlling street lights. It turns out that this protocol generates an unbounded amount of traffic (say, proportional to the square of the number of street lights in the world), has no congestion control, and no security, but is expected to run over the Internet. According to you, this has nothing to do with the IETF. It might result in the congestive collapse of the Internet, but who cares, the IETF doesn't do street lights. I would like to see the criteria which determine that telephones belong on the Internet but street lights don't! thanks for making the most concise statement of the conflict here in the discussion so far! I think this point is one of the critical causes of conflict when talking about the IETF mission - and unless we lance the boil, actually talk about it, and attempt to *resolve* the issue, we will go on revisiting the issue forever, with nothing but wasted energy to show for it. In the discussions leading up to this document, we actually had 3 different other levels of inclusivity up for consideration: - Everything that runs over the Internet is appropriate for IETF standardization. Obviously, that might cause some reactions from organizations like the W3C, OMG, ISO, ITU, the power grid standardizers, the bank transaction standardizers and others even if the IETF were able to gather the required competence, it's hard to see how we could build a management structure that could handle everything. - Everything that needs open, documented interoperability and runs over the Internet is appropriate for IETF standardization. A bit smaller, but still huge, and hard to draw boundaries around. Advantage: Everything we currently work on is unquestionably part of the IETF's scope. - Everything that builds infrastructures on the Internet that needs to be open and interoperable is appropriate for IETF standardization. This would place SMTP, DNS and LDAP (in the original vision) inside the IETF's sphere, but would leave the traffic lights (and the current way LDAP is used) outside it. - Everything that can seriously impact the Internet is appropriate for IETF standardization. Argues for keeping HTTP and DNS, would include your hypothetical traffic lights, but would probably leave POP/IMAP out, and leaves people arguing about both SIP and L3VPN. - For the Internet - only the stuff that is directly involved in making the Internet work is included in the IETF's scope. It's far from clear in my mind what the right thing is, or what the appropriate path forward is if the IETF regards its purpose as being one or the other - we might, for instance, decide that we standardize stuff that needs to be open and interoperable, but have different evaluation criteria for those things than for those things that make the Internet work, and will dispose our resources accordingly - I don't know. And if we decide that certain things we currently do are outside our scope, we've got a responsibility to make sure the work effort is handled in a responsible fashion. But it's relatively clear to my mind that continuing to have both sides of a discussion argue based on the mission of the IETF, with conflicting definitions, is not the best thing for the Internet. So - rather than stating something completely vague, we put out a proposal. If it's the wrong proposal, it should be changed. But please be specific about what you think it should be changed to. makes sense? Harald
Re: IESG proposed statement on the IETF mission
Harald. Interesting, important, thanks. Internet usage == One of the large dynamics not explicitly mentioned is the increased commercial usage/value of the Internet and how that drives the community in new directions. Trust model = Inherent in Eric's problem statement is the notion that end systems have the ability to impact the experience other Internet users have. Whether this is the result of an historical trust model, where people using the Internet were assumed to a) have clue and b) be acting in the best interests of the community, or whether this is the result of other community values, this diserves comment/debate, IMHO. The basic dynamic of course that needs to be balanced is the rights of Internet users, the role and obligations of operators, and the creative abuse of the network that could lead to unforseen new value and applications. Discusion of trust models will inevitably also lead us down the road of discussing hairy issues such as (D)DOS - but isn't that one of the more pressing issues today? Network Architecture layers 1-9 = Firstly, seems there are four basic functions that need addressing in the building of internets (remembering the network of networks value, there is not one Internet): -Transport of packets from one edge of an internet to the other edge (PE if u like, but...). -Transport of packets from end system to end system over one of more internets -Management and operation of internets -Applications that make use of the above infrastructure Based on the inclusivity problem statement positions you have considered, and other comments WRT how much the IETF can do, it would appear that over time the last bullet point above might become disjoint from the first three. Not arguing that application development should be done at the IETF, but I think that some recognition needs to be made of the vastly different skill sets and interests of end-system operators and engineers and infrastructure operators and engineers. Perhaps the area concept needs another super-layer, especially given the vast difference in communities of liasion. Lastly, some discussion of layer 1-to-9 should take place. Seems to me the IETF works very well when focused at layers 3 to 4; has of course established many important application layer standards; but experiences challenging liasion when focusing below layer three (data/user plane) - PPP not withstanding. In the spirit of we can not do everything, this is deserving of discussion if for no other reason than to clear the air as we move forward. Perhaps one of the most important areas of focus is the connection of end systems and internets to other internets. This is an area that must allow for creative abuse of the network through both freedom of higher layer protocols and also the facilitation and participation of as many systems vendors as possible addressing cable, wireless, wireline,... This area should especially be supported by standards, implementation agreeements, and interoperability efforts. The immutable vs the mutable = Seems like it would be useful to separate the immutable from the mutable. Examples of immutable might be (not a prescription just examples): -rough consensus -running code -Chairs that operate in the best interests of the community -the UNIX-like adherence to development of small building blocks (also present in biology BTW). -network of networks Examples of the mutable might be: -over the next 5 years we are going to focus on (D)DOS Lancing the boil There is nothing nice, pleasant, or enjoyable about lancing boils, but if we are to do so, then the starting point should be the encouragement of the identification of the largest boils.
Re: IETF mission boundaries (Re: IESG proposed statement on the IETF mission )
That is wrong or at least a gross overstatement. If that's what you think, I invite you to make a list of all the IETF-standardized protocols and explain how they are all (or even more than 50% of them) needed to make the Internet work. There have been many things that the IETF has chosen to step away from but that ran and run over the Internet. Some graphics standards come immediately to my mind ... Those graphics standards were kept out of the IETF not because the working groups involved thought they didn't think they were experts, but because the subject was out of scope for the IETF. I'm not familiar with this particular case, but I don't see why protocols for distributing graphics would be thought to fall outside the scope of the IETF, any more than protocols for distributing voice or video. Of course, graphics standards that have nothing do with distribution of the graphics over IP would be out of scope. No committee is ever able to limit itself on grounds of insufficient expertise. Now, there is a gross overstatement! For everyone who proclaims himself (rightly or wrongly) to be an expert on some topic, there are always two other people who claim that he is clueless. It's not uncommon for a WG to refuse to pick up a topic because the consensus is that the topic's proponents are clueless.
Re: IETF mission boundaries (Re: IESG proposed statement on the IETF mission )
From: Eric Rosen [EMAIL PROTECTED] That is wrong or at least a gross overstatement. If that's what you think, I invite you to make a list of all the IETF-standardized protocols and explain how they are all (or even more than 50% of them) needed to make the Internet work. There's a progression here: 1. ad hoc network interoperability group forms. 2. it has some success and gains some fame. 3. it is besieged by people eager to borrow its printing press 4. it is besieged by people who know everything about everything and have a duty to write or at least control all standards on everything including what people perversions do in the privacy of their own networks. I've been complaining about #3 for many years. Examples of #4 include some of the more vigorous combatants in the IPv6 site local arena and the notion that notion that nothing is out of scope. There have been many things that the IETF has chosen to step away from but that ran and run over the Internet. Some graphics standards come immediately to my mind ... Those graphics standards were kept out of the IETF not because the working groups involved thought they didn't think they were experts, but because the subject was out of scope for the IETF. I'm not familiar with this particular case, but I don't see why protocols for distributing graphics would be thought to fall outside the scope of the IETF, any more than protocols for distributing voice or video. Of course, graphics standards that have nothing do with distribution of the graphics over IP would be out of scope. The example I'm thinking about involved predecessors to OpenGL. People who know about network stuff know enough to stuff bits into wires, but that's the earier part of things like OpenGL, Microsoft's alternative whose name eludes me, JPEG, MPEG, and so forth. No committee is ever able to limit itself on grounds of insufficient expertise. Now, there is a gross overstatement! For everyone who proclaims himself (rightly or wrongly) to be an expert on some topic, there are always two other people who claim that he is clueless. The other two base their claims on their own greater expertise and wouldn't dream of suggesting that they are not well suited for standardizing whatever it is. It's not uncommon for a WG to refuse to pick up a topic because the consensus is that the topic's proponents are clueless. Please name an example of such a case. I have seen WG chairs and others use brute force and out-of-scope arguments to halt nonsense, but I've never seen we don't know enough work. Often the brutal WG chairs say they don't think the WG knows enough, but it's the scope arguments that carry the day. Sheesh!--next you'll be telling us that you never heard the phrase out of scope before last week. Vernon Schryver[EMAIL PROTECTED]
Re: IETF mission boundaries (Re: IESG proposed statement on the IETF mission )
% --On 15. oktober 2003 12:57 -0400 Eric Rosen [EMAIL PROTECTED] wrote: % % Well, let's test this assertion. Suppose a consortium of electric % companies develops a UDP-based protocol for monitoring and controlling % street lights. It turns out that this protocol generates an unbounded % amount of traffic (say, proportional to the square of the number of % street lights in the world), has no congestion control, and no % security, but is expected to run over the Internet. % % According to you, this has nothing to do with the IETF. It might result % in the congestive collapse of the Internet, but who cares, the IETF % doesn't do street lights. I would like to see the criteria which % determine that telephones belong on the Internet but street lights don't! % % thanks for making the most concise statement of the conflict here in the % discussion so far! % I think this point is one of the critical causes of conflict when talking % about the IETF mission - and unless we lance the boil, actually talk about % it, and attempt to *resolve* the issue, we will go on revisiting the issue % forever, with nothing but wasted energy to show for it. % % In the discussions leading up to this document, we actually had 3 different % other levels of inclusivity up for consideration: % % - Everything that runs over the Internet is appropriate for IETF % % - Everything that needs open, documented interoperability and runs over % the Internet is appropriate for IETF % % - Everything that builds infrastructures on the Internet that needs to be % open and interoperable is appropriate for IETF standardization. % % - Everything that can seriously impact the Internet is appropriate for % IETF standardization. % - For the Internet - only the stuff that is directly involved in making % the Internet work is included in the IETF's scope. % % a discussion argue based on the mission of the IETF, with conflicting % definitions, is not the best thing for the Internet. % % Harald I guess for me, I always thought that the IETF and its precursors were interested in developing engineering solutions / designing protocols that would allow end2end or any2any communications, regardless of underlying transport media, be it seismic wave, avian carrier, radio waves or the PSTN. - At no time did I ever truly beleive that the systems that used these protocols/solutions would always be on and fully connected. Infrastructures that use IETF products have nearly always been only partially connected and many systems are not always on. So while a design goal might have been to support always on/fully connected state, the reality is that infrastructres have nearly always been disjoint/unconnected and endpoints come and go. But when they are connectable, they should function in a seamless, e2e fashion, at least IMHO. And then you neglect an unstated presumption in the last two bullet points: As perceived by who? --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise).
Re: IETF mission boundaries (Re: IESG proposed statement on the IETF mission )
- For the Internet - only the stuff that is directly involved in making the Internet work is included in the IETF's scope. In other words, routing, DNS, and Internet operations/management. Adopting this as the IETF's mission would be a very radical change indeed! While this particular mission statement does seem to reflect the interests of a certain notorious IESG member, let's not pretend that this has ever been the limit of the IETF's mission. The IETF has always been concerned with things that make the Internet more useful, and with things that expand the utility of the IP protocol suite. There's never been a time when for the Internet was an accurate representation of the IETF's concerns. You are of course welcome to propose such a radical change to the IETF's mission. But if you are going to circulate a document under the subject line IESG proposed statement on the IETF mission, you should make it clear that the IESG is proposing to make a complete change in the IETF mission. Instead, you give the impression that the IESG thinks that for the Internet is and has always been the IETF's mission. The formulation I like is Everything that needs open, documented interoperability and runs over the Internet is appropriate for IETF standardization. This is much truer to the IETF's current and historical practice. That doesn't necessarily mean that the IETF has to standardize everything that falls within its mission. For instance, a particular area might fall within the mission, but the IETF might not have the expertise to tackle it. A WG in that area could then be rejected on the grounds of insufficient expertise. Such decisions would have to be made on a case-by-case basis. Again, this is the way such decisions have always been made in the IETF.
Re: IESG proposed statement on the IETF mission
On Wed, 15 Oct 2003 12:48:37 EDT, Keith Moore said: I certainly don't believe only in rough consensus and running code - I also believe in explicit definition of goals and requirements, careful design by knowledgable experts, analysis, iterative specification, wide public review, etc. Of course, proper design and development techniques increase the likelyhood of running code - and proof by example running code is always a good way to achieve a consensus. pgp0.pgp Description: PGP signature
Re: IESG proposed statement on the IETF mission
It's an interesting document, but it looks to me a bit much like a problem description and I'm not sure how it relates to other existing work (the problem description document in the problem working group, most obviously). I particularly liked the discussion of the IETF mission - it could provide the basis for tackling one problem that's been raised on a number of occasions, which is that the organization doesn't have a clear sense of mission or vision. Even though in the first paragraph of the Social Dynamics section you say that As they are neither good nor bad, it is not appropriate to call them problems; rather think of them as social forces and dynamics a number of them really are framed as problems. Indeed, it would be hard to define some way in which statements like making integration more difficult are not problem statements. I'd really like to see the document, which I think has good fundamentals, refocused on mission and goals. Melinda
Re: IESG proposed statement on the IETF mission
On Tue, Oct 14, 2003 11:48:10PM +0200, Harald Tveit Alvestrand allegedly wrote: As part of the discussions about change process within the IETF, the IESG has come to believe that a somewhat longer statement of the IETF's mission and social dynamics might provide useful context for the community's discussion. As part of that, we'd like to put the following document out for feedback. It incorporates lots of ideas and some text from existing RFCs and IETF web pages, but is more focused on change than those have been. We hope it captures a sense of the context of the work of improving the IETF, by capturing some of the social dynamics which have been an implicit part of the IETF's work and style over the years. OK, but first, it doesn't clarify the mission, or the social contract. At most it makes a couple vague statements after describing some general problems. It looks like the IESG has some sense of where the problem-statement/solutions process is going, and wants to run with it. That's okay -- but please say explicitly that's what's happening, if it is. We also hope that by making some of those implicit elements more explicit, we may find it easier to understand how to make changes that will go with the grain of the IETF's history and culture. What I want is a renewed, clear statement of the fundamental principles of the IETF which must not be violated or weakened during the problem/solution process. It's important that the leadership of the IETF keep clear themselves on what the fundamental principles are, and to reiterate them when necessary (like now). That's part of the social contract itself. There are principles which are at the heart of the organization and which the (pseudo-)consensus process doesn't get to touch. The IETF Mission The IETF's mission has historically been embedded in a shared understanding that making engineering choices based on the long term interest of the Internet as a whole produces better long-term results for each participant than making choices based on short term considerations, because the value of those advantages is ultimately derived from the health of the whole. The long term interest of the Internet includes the premise that the Internet is for everyone. Two years ago, the IESG felt that making the mission of the IETF more explicit was needed. The following terse statement has since been promulgated, first by IESG members and then by others: The purpose of the IETF is to create high quality, relevant, and timely standards for the Internet. The purpose of the IETF has always been to make the Internet work better, in measurable operational terms. All else descends from that. We do standards because we have to, for now and for the future. Why do we care about network operators being in the room if our prime mission is to make standards? Why do we care if there are two interoperable implementations? The operations work of the IETF is important unless it is being taken care of elsewhere. It isn't frosting on a standards body cake, it's just as important as standards. Beyond that, yes, the IETF is primarily an SDO, because many operational issues and agreement on deployment BCPs are being taken care of by other means, and also because standards is our main measurable output in the eyes of the outside world. The above statement applies, but it is not a basic principle. It derives from our fundamental responsibility, to have an Internet that works well today and is robust and flexible enough to work well in the future. It is important that this is For the Internet, and does not include everything that happens to use IP. IP is being used in a myriad of real-world applications, such as controlling street lights, but the IETF does not standardize those applications. A very poor distinction. Everything runs on the Internet eventually, regardless of what private area it was meant for to start with. Experience is that everyone wins if there are Internet-compatible ways of doing things from the beginning. I fully expect street light control to run as a secure service along with many other services over a generic IP network. However, it's okay to say that priority will be given to work on the public Internet. The IETF has also had a strong operational component, with a tight bond, and hence coordination, between protocol developers and network operators, and has had many participants who did both. This has provided valuable feedback to allow correction of misguided standardization efforts, and has provided feedback to sort out which standards were actually needed. As the field has grown explosively, specialization has set in, and market pressures have risen, there has been less and less operator participation in the IETF. This has nothing to do with either mission or social contract. Are you saying therefore we need to change our mission? Similarly for almost all of the
Re: IESG proposed statement on the IETF mission
overall, I like the document. some comments: However, while Dave Clark's famous saying We do not believe in kings, presidents, or voting. We believe only in rough consensus and running code, is this an accurate quote? I've usually seen it written We reject kings, presidents, and voting. We believe in rough consensus and running code. I agree with this form, but not with the way you've stated it. I certainly don't believe only in rough consensus and running code - I also believe in explicit definition of goals and requirements, careful design by knowledgable experts, analysis, iterative specification, wide public review, etc. The purpose of the IETF is to create high quality, relevant, and timely standards for the Internet. I actually believe IETF has a somewhat wider purpose than that. What I usually say is we're trying to help the Internet work better. We do this partially by authoring and maintaining protocol standards, but we use other mechanisms also. In addition to standards, we produce informational and experimental documents and BCPs. We provide formal and informal advice and feedback to various parties about operational practices, implementation practices, efforts by other SDOs, proposed regulations, etc. All of these are relevant to, and consistent with, the purpose of helping the Internet to work better. We *ought* to provide more architectural direction or advice - our failure to resolve architectural issues in advance of deployment of products with conflicting views of the architecture (or in some cases, a simple lack of care or foresight on those vendors' parts) has caused a number of conflicts and operational problems, and has impaired the ability of the Internet to support diverse applications. I also believe that some amount of experimentation (perhaps not all that is being done under IETF's purview) is part of the process of trying to make the Internet work better The IETF has identified interoperability, security, and scalability as essential, but without attaching measurements to those characteristics. that's a start. there are a lot more characteristics than these that should be considered in a design, that we haven't articulated yet, but we need to. It is important that this is For the Internet, and does not include everything that happens to use IP. IP is being used in a myriad of real-world applications, such as controlling street lights, but the IETF does not standardize those applications. I disagree with the sentiment as I understand it. I don't think it's realistic anymore to take the view that what people run entirely on private networks is their own business and outside of IETF's purview. NATs, private addresses, and DHCP with short lease times have all had devistating effects on the Internet's ability to support applications. Insecure applications can facilitate the breeding of viruses that affect the entire network even if their intended interactions are only between a local client and server. We do have to limit our scope. We don't have the ability to scale to the point where we could standardize everything that uses IP, and it would be silly of us to try to claim authority to do so. But it might be reasonable for us to define standards for how local networks work (to provide applications with a predictable environment), or to define standards which all applications should adhere to (to minimize security issues) which can be incorporated by reference into other protocol specifications. regarding the section on Quality and Architectural Review. what strikes me about this section is the (implicit) assumption that architecture is done after the fact. rather than looking ahead to minimize and resolve conflicts well before they acquire the inertia of wide deployment, we try to fix things after the fact.
Re: IESG proposed statement on the IETF mission
The purpose of the IETF is to create high quality, relevant, and timely standards for the Internet. It is important that this is For the Internet, and does not include everything that happens to use IP. IP is being used in a myriad of real-world applications, such as controlling street lights, but the IETF does not standardize those applications. Well, let's test this assertion. Suppose a consortium of electric companies develops a UDP-based protocol for monitoring and controlling street lights. It turns out that this protocol generates an unbounded amount of traffic (say, proportional to the square of the number of street lights in the world), has no congestion control, and no security, but is expected to run over the Internet. According to you, this has nothing to do with the IETF. It might result in the congestive collapse of the Internet, but who cares, the IETF doesn't do street lights. I would like to see the criteria which determine that telephones belong on the Internet but street lights don't! Another problem with your formulation is that the Internet is a growing, changing, entity, so for the Internet often means for what I think the Internet should be in a few years, and this is then a completely unobjective criterion. One would hope instead that the IETF would want to encourage competition between different views of Internet evolution, as the competition of ideas is the way to make progress. I also do not understand whether for the Internet means something different than for IP networking or not. I think it should also be part of the mission to produce standards that facilitate the migration to IP of applications and infrastructures that use legacy networking technologies. Such migration seems to be good for the Internet, but I don't know if it is for the Internet or not.
RE: IESG proposed statement on the IETF mission
Hi Scott, Similarly for almost all of the rest. What's the point? Are you reiterating the problem-statement work? They're doing all right, although perhaps you could help push the work to completion. It would be much more useful for you to reaffirm the fundamental principles that are not on the auction block. From your perspective, what are those fundamental principles? Margaret
Re: IESG proposed statement on the IETF mission
One would hope instead that the IETF would want to encourage competition between different views of Internet evolution, as the competition of ideas is the way to make progress. what I would say instead is that the IETF should encourage this competition within the sphere of architectural discussion - well in advance of development of specific standards or deployment of specific products.
Re: IESG proposed statement on the IETF mission
On Wed, Oct 15, 2003 01:01:53PM -0400, [EMAIL PROTECTED] allegedly wrote: Hi Scott, Similarly for almost all of the rest. What's the point? Are you reiterating the problem-statement work? They're doing all right, although perhaps you could help push the work to completion. It would be much more useful for you to reaffirm the fundamental principles that are not on the auction block. From your perspective, what are those fundamental principles? I can't do that today, but will reply soon.
