Last day: Call for volunteers: narrative minutes of IESG meetings
Today's the last day to volunteer. By the way, we're thinking of picking two volunteers, to share the load. Brian Original Message Subject: Call for volunteers: narrative minutes of IESG meetings Date: Mon, 25 Jul 2005 08:50:05 -0400 From: Brian Carpenter [EMAIL PROTECTED] To: IETF Announcement list ietf-announce@ietf.org The comments on the attached proposal were strongly favourable. The IESG would now like to call for volunteers to act as its Recording Secretary (scribe) for a 6 month trial period. Volunteers should write to iesg@ietf.org by August 2nd. We'll keep names confidential, unless of course people choose to volunteer in public. Details will be settled with the chosen volunteer, but the general guidelines are: - the scribe will attend the regular IESG telechats (11:30 - 14:00 US ET on alternate Thursdays; this time cannot be changed). - the scribe will record narrative minutes of the discussions, and will not take part in the discussions except to ask for clarifications. - the narrative minutes will be published after review by the IESG. The intent is to do this about two weeks after the meeting in question. - confidential items (principally personnel discussions) will not be reported in detail. The scribe will not take part in any sessions that liaisons are excluded from (i.e. nominating discussions and appeal discussions). Brian Carpenter Original Message Subject: A proposed experiment in narrative minutes of IESG meetings Date: Thu, 14 Jul 2005 15:19:34 +0200 From: Brian E Carpenter [EMAIL PROTECTED] Organization: IBM To: ietf@ietf.org The IESG is interested in carrrying out an experiment to publish narrative minutes for IESG meetings as well as the regular minutes of decisions taken. Currently the IESG minutes are a formal record of decisions taken and (like the agenda) are generated semi-automatically by the secretariat. This is a well-oiled process that we don't want to disturb. However, the community clearly would like more information about the way the IESG reaches its decisions, beyond the record of comments on each document that is stored in the I-D tracker. We propose that, for an initial period of 6 months, a member of the community will be added to regular IESG meetings as a recording secretary who will write narrative minutes of the discussions, which will be posted publicly after IESG review for accuracy. (As always, personnel discussions will need to remain private or be minuted with great care.) The IESG welcomes comments on this proposal, to iesg@ietf.org or ietf@ietf.org as appropriate. If the community seems to be in favour of this experiment, we will soon call for volunteers and pick one person to act for the initial six months. After six months, we will ask the community whether the results justify continuing the effort. The main question will be whether the community is getting useful extra information. (Thanks to Spencer Dawkins for triggering this idea.) Brian for the IESG ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Let's make the benches longer.... (Re: draft-klensin-nomcom-term-00.txt)
On rereading, my previous reply could have been better formulated.. --On 1. august 2005 12:42 -0400 Eric Rosen [EMAIL PROTECTED] wrote: the normal process for AD replacement involved choosing which of the people who had worked with the AD for a long time could do the job this time, In American vernacular, this procedure is known as cronyism. Generally, one doesn't expect to see this advocated in a public forum ;-) The selection mechanism I advocated was the following (quoted from the expired draft): 5. Details All members of the leadership are selected by the nomcom for membership in an area. The nomcom also selects which member is supervisor and vice supervisor for an area. [UNCERTAIN]The supervisor may also be selected by the members of the council, or by other means. Yearly selection by the council? It's also been suggested that instead of nomcom selecting everyone, the leadership team can make selections to the area councils, based on recommendations from the area supervisor. This would not increase the load on the nomcom as much as envisaged here. [/UNCERTAIN] Special care should be taken that the composition of area teams and the leadership team results in functional teams. (The term area supervisor is a concept that is a successor to the current term AD - the draft tried to use new names to point out that things changed.) One core difference between this idea and directorates is that directorates serve, explicitly, at the pleasure of an AD; ADs can create, disband or replace directorates without any public input or control. Your concern is one reason why the idea was different. Note that nothing here prevents the nomcom from picking people outside the council to be supervisor; if all is well, common sense would say that they don't, but when things are not well, they should have the power (IMHO). But the idea didn't generate any groundswell of let's do it, either in the community or in the IESG, so I turned to fixing things that were more obviously broken, with more obvious fixes. Harald ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Completely out of scope: Restaurant reccomendation
Yesterday I had a very nice salad in this slightly overpriced restaurant down the road from the IETF venue. Its a Brasserie specialized in Fruit de Mere. I ordered Salade Italienne. Very nice indeed, until I hit a bug, covered in olive oil, that was enjoying the salad too. I am not a specialist in insects but I know cockroaches come in many different shapes and forms. The small animal covered in oil could have been a baby cockroach. I signaled the waiter and after several Oh-la-la's he offered me a new salad. I lost my appetite so I refused. So far nothing to complain about. But then came the bill. I was charged. Then I specifically asked if something could be done about that. And to be honest I'd settled for anything symbolic, free wine, free desert, espresso, anything. But the waiter could not be convinced. Hence my recommendation. Do not go to: Le Ternes Pereire 84, Avenue de Ternes 75017 Paris Actually pass by, look at the menu, and if the waiter tries to convince you to come in just mention the cockroach in the salad. http://www.bio.umass.edu/biology/kunkel/cockroach.html --Olaf PS. Somebody suggested that it would be nice to have a meeting Wiki for recommendations on restaurants, stories about pickpockets, and other non process and non technical cruft. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Completely out of scope: Restaurant reccomendation
So, who is going to volunteer to set up said wiki? I'm not technically proficient On 8/2/05, Olaf M. Kolkman [EMAIL PROTECTED] wrote: PS. Somebody suggested that it would be nice to have a meeting Wiki for recommendations on restaurants, stories about pickpockets, and other non process and non technical cruft. -- Clint (JOATMON) Chaplin Wireless Security Technologist Wireless Standards Manager ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I'm not the microphone police, but ...
At 17:22 01/08/2005, Spencer Dawkins wrote: That would be fine, if I changed the Newcomer's Orientation :-) Spencer Spencer, However, many people here are not using their 'individual money' to get here in Paris. Our name badges list our employers (in most cases). I think its a different issue if I come to the mic and say, 'We at the ACME company would like to state, for the record, that we support the foo bar proposal and hope it becomes an official RFC as soon as possible. It doesn't bug me one-way or another if folks state their name who pays the bills. Spencer, I do not claim that my technical positions are correct, but that they are independent and I pretend they prove that IETF is what it claims: by individuals. I pay dearly that independence for years (which has many other RD advantages). This permits me, may be clumsily but loyally, to support for free the interests of open-source, of small industries, of developing countries, of a user-centric architecture. So, what is sad is when I am asked by an IETF establishment member do you realise how much you _cost_ to the industry?. Which industry? Not mine in any case. Fostering competition is not favoring my competition. This is why I suggest the real danger for the IETF is the collusion of large organisations through external consortia to get a market dominance through de facto excluding IETF standardisation and IANA registry control. And this is why I suggest the best way to address it is simply to ask for the truth, the whole truth. Participation should be individual, but published details should include who foots the costs, the corporation, the relevant consortia and main customers for consultants. We need everyone, including commercial consortia, individual searchers, non-profits, Government, Academic projects, etc., but, please read RFC 3869, on a equal participation opportunity basis. This is the only way to obtain open, scalable and uniform standards. I live nearby the Palais des Congrès. But I do not come since I am not invited for free by IASA as we are invited by ICANN. The IETF policy must be consistent: there is no reason to pay personal money to help interests I defend to be treated unequal, due to often disclosed but non published affinities. They get there far more than what they pay for, why would I in addition subsidise them? jfc ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Completely out of scope: Restaurant reccomendation
On 8/2/05, Olaf M. Kolkman [EMAIL PROTECTED] wrote: Yesterday I had a very nice salad in this slightly overpriced restaurant down the road from the IETF venue. Its a Brasserie specialized in Fruit de Mere. I ordered Salade Italienne. Very nice indeed, until I hit a bug, covered in olive oil, that was enjoying the salad too. I am not a specialist in insects but I know cockroaches come in many different shapes and forms. The small animal covered in oil could have been a baby cockroach. I signaled the waiter and after several Oh-la-la's he offered me a new salad. I lost my appetite so I refused. So far nothing to complain about. But then came the bill. I was charged. Then I specifically asked if something could be done about that. And to be honest I'd settled for anything symbolic, free wine, free desert, espresso, anything. But the waiter could not be convinced. Hence my recommendation. Do not go to: Le Ternes Pereire 84, Avenue de Ternes 75017 Paris Actually pass by, look at the menu, and if the waiter tries to convince you to come in just mention the cockroach in the salad. http://www.bio.umass.edu/biology/kunkel/cockroach.html --Olaf PS. Somebody suggested that it would be nice to have a meeting Wiki for recommendations on restaurants, stories about pickpockets, and other non process and non technical cruft. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf You should have refused to pay citing health concerns, and thretened to report the restaurant. Exactly what kind of conditions does the kitchen have that a baby cockroach would make it into the salad? And further, why would it be common enough that they would have to charge for these salads, or not be profitable? ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Reminder: IAOC Office hours
All - Members of the IAOC will be holding office hours tues/wed/thurs in Room 325M form 3:30-4:30PM. Take the elevator next to the terminal room up to 3.5 and follow signs. A draft pdf of my slides for the Plenary can be viewed at: http://koi.uoregon.edu/~iaoc/ietf-63-iaoc-lel.pdf Please drop by if you have questions or comments. Lucy E. Lynch Academic User Services Computing CenterUniversity of Oregon llynch @darkwing.uoregon.edu (541) 346-1774 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: I'm not the microphone police, but ...
Behalf Of JFC (Jefsey) Morfin This is why I suggest the real danger for the IETF is the collusion of large organisations through external consortia to get a market dominance through de facto excluding IETF standardisation and IANA registry control. And this is why I suggest the best way to address it is simply to ask for the truth, the whole truth. The problem with this approach is that it becomes self-defeating. The work of the IETF gets clogged up by individuals whose sole objective is to block what they see as the encroachments of evil corporations at all costs. Even if they can't see the evil globalization scheme immediately they will block progress anyway just in case. The result is that corporations that want to get work done either go to other forums or craft proposals that are so narrowly drafted that they amount to a rubber stamp. Certainly there are bizare corporations attempting to achieve some sort of stranglehold. Anyone remember digital convergence and the CueCat? That type of behavior tends to come from market entrants rather than established companies. Once you have a stake in the open Internet the probability of success in a closed 'walled garden' scheme isn't high enough to be interesting. Furthermore the people working for those corporations tend to consider themselves advocates for and responsible to their customers and their customer's customers at least as much if not more than their shareholders. Sit at the back of the plenary sessions. Watch the number of people opening up their laptop and starting a telnet session. Less than 5% of the billion plus Internet users interact with their machine in that way. The IETF membership is totally unrepresentative of the billion plus Internet users. Worse still the prevaling attitude is of the 'anyone can become like us only not quite so skilled' type. Most people don't want to have to become computer experts. The IETF does not have a veto over the development of the Internet. There are plenty of standards organizations to choose from. Nor for that matter does IANA. All IANA is is a voluntary arrangement that exists because people choose to recognize it. There is in practice nothing to stop individuals simply declaring that they will use a particular code point. As a thought experiment consider what happens if someone decides they want the DNS RR 88 and just goes and uses it. If they succeed and their standard is used nobody else is going to accept issue of RR #88. And that is all anyone needs from IANA. This total lack of control is actually not such a bad thing. It means that if the International 'Internet Governance' cabal that wants to capture the IANA were to succeed the success it would not matter very much. This is the only way to obtain open, scalable and uniform standards. Are these the right goals? Surely meeting the needs of the users should come somewhere in the list. Uniformity in standards can be a good thing. But there are also disadvantages to insisting on 'consistency' with what are at this point quarter century old designs. Ten years ago I would have thought that the idea of 'disposable' standards whose sole purpose was to effect a transition to some other standard was mad. Today I really don't see any problem with the idea that you write a spec whose sole purpose is to enable a transition. It is pretty hard for any standard to get anywhere unless it is 'open'. It is not exactly in my employer's interest to allow a competitor to gain such a position. Nor is it in my competitor's interest to allow me to achieve such a position. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Internet Draft Process Procedure
Hello folks, Just a quick question about the acceptance of Internet-Drafts. Is there such a term called acceptance about Internet-drafts or they will be anounced anyway as long as being proposed? As I figured that it's like everyone talks about his/her opinions freely in the form of I-D. An I-D is certainly not equal to a journal paper. Looking forward to being clarified. Zhen ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Personal Security Reminder
Please be sure you do not leave any of your belongs unattended anywhere in the meeting venue, including meeting rooms. Your belongs may be picked up by either security or someone else and you may not be able to retrieve them. Several people already have computer bags picked up and they may or maynot be lost. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: I'm not the microphone police, but ...
At 16:23 02/08/2005, Hallam-Baker, Phillip wrote: Behalf Of JFC (Jefsey) Morfin This is why I suggest the real danger for the IETF is the collusion of large organisations through external consortia to get a market dominance through de facto excluding IETF standardisation and IANA registry control. And this is why I suggest the best way to address it is simply to ask for the truth, the whole truth. Hallam, I still must answer you very cute remark on what one could name delta sec. I am giving a lot of thinking. I find it very interesting. So I will be careful about this one :-) The problem with this approach is that it becomes self-defeating. The work of the IETF gets clogged up by individuals whose sole objective is to block what they see as the encroachments of evil corporations at all costs. This is unfortunately what I must do right now. But unfortunately this is not what I see, it is what they demonstrate. Even if they can't see the evil globalization scheme immediately they will block progress anyway just in case. The result is that corporations that want to get work done either go to other forums or craft proposals that are so narrowly drafted that they amount to a rubber stamp. Except if you can grab a BCP. I am not sure you are actually right. You certainly know a few cases. I known one before: I actually partly oppose your company. I gave up as it was my first IETF opposition. Today I see that it would have been tremendously beneficiary to your company if I had hold my position. The problem with IETF is there is no architectural common vision. So you do not know if your rubber stamp is at the proper place. This is why would prefer to have a good evaluation of all the interests supporting a proposition. Having to road map, I could at least understand who supports. If there is a good distribution of support, this is good. If there is only a commercial, or a political, etc. support: warning. This is simply some more sophisticated rough consensus evaluation process. Avoiding consensus by exhaustion organised by affinity groups. Certainly there are bizare corporations attempting to achieve some sort of stranglehold. Anyone remember digital convergence and the CueCat? That type of behavior tends to come from market entrants rather than established companies. Once you have a stake in the open Internet the probability of success in a closed 'walled garden' scheme isn't high enough to be interesting. Unless you are dominant and want to protect that dominance. Furthermore the people working for those corporations tend to consider themselves advocates for and responsible to their customers and their customer's customers at least as much if not more than their shareholders. dominance makes this the same. You have so many customers that their stability seems to be part of the internet. But dominance in an area can be defeated by dominance or greassroots effort in an area which looked orthogonal. The problem is that it may create disruption. Look at Internet balkanisation. Sit at the back of the plenary sessions. Watch the number of people opening up their laptop and starting a telnet session. Less than 5% of the billion plus Internet users interact with their machine in that way. The IETF membership is totally unrepresentative of the billion plus Internet users. Worse still the prevaling attitude is of the 'anyone can become like us only not quite so skilled' type. Most people don't want to have to become computer experts. The IETF does not have a veto over the development of the Internet. There are plenty of standards organizations to choose from. Nor for that matter does IANA. All IANA is is a voluntary arrangement that exists because people choose to recognize it. There is in practice nothing to stop individuals simply declaring that they will use a particular code point. IETF and IANA have a defacto monopoly on the architecture. This architecture must evoluate for years. This only lead to the question: will they make it or who will? Two responses today: ITU or grassroots. If someone believes the ITU is able to do it so it is grassroots. But grassroots is balkanisation, starting by the dominant securing their dominant territory. And grassroots undermining it. This has good and bad effect. At this time I have not yet determined the best way out of IETF. As a thought experiment consider what happens if someone decides they want the DNS RR 88 and just goes and uses it. If they succeed and their standard is used nobody else is going to accept issue of RR #88. And that is all anyone needs from IANA. This total lack of control is actually not such a bad thing. It means that if the International 'Internet Governance' cabal that wants to capture the IANA were to succeed the success it would not matter very much. The IANA time is over. The problem is its consistent replacement. This is the only way to obtain open, scalable and uniform
RE: I'm not the microphone police, but ...
From: JFC (Jefsey) Morfin [mailto:[EMAIL PROTECTED] Except if you can grab a BCP. I am not sure you are actually right. You certainly know a few cases. The lack of an IETF endorsed spec from MARID did not stop Microsoft from holding an industry gala two weeks ago in NYC. Nobody commented or appeared to care that the spec was not ratified. Think of it as a recess appointment. The problem with IETF is there is no architectural common vision. No, that is its strength. The Web was not part of the IETF common vision. SSL was diametrically opposed to the IETF security vision. IETF and IANA have a defacto monopoly on the architecture. No they don't. W3C and OASIS are both more influential as standards bodies at this point, particularly once we get above the session layer. The URI identifier architecture introduced in PICS and since adopted in XML eliminates the need for fixed registries like the IANA. That was the whole point, to eliminate the control point. I did not want a central registry of PICS censorship schemes. Of course other people did, mostly the people who used euphemisms like 'content selection' rather than censorship. For example the whole IPv6 issue is that they did not understand that their current deployement (2001) is disposable. The failure to get the deployment stakeholders round the table to ask the question 'what will it take to make this happen' is in my view the root cause. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Very helpful Parisians (Was: Cautionary tale: Paris pickpockets)
There's been a lot of discussion about petty crime in Paris -- I posted my own story (and if you need to know how to get an emergency passport in Paris, talk to me offline). Let me follow up on my own posting. To recap, my wife's purse was stolen at a restaurant very close to the hotel. Two Parisians found it under a scooter about 1 km from here. They went to a fair amount of trouble to locate me -- my wife and I don't have the same last name, but they found a minor card in the purse that mentioned my name -- and delivered the purse to me here at the hotel. Yes, the money was gone, as was her phone. The credit cards and passports were still there, though of course they'd been canceled. (Obviously, our threat model was too great) The less-critical stuff -- but still a nuisance to replace -- was there. A set of keys was there. (We did not assume a trans-Atlantic burglary ring. And if the opposition really was that competent, they'd have copied the keys, or at least the critical data about them, before discarding them. Not in my threat model) There certainly is a petty crime problem in Paris. See 'CRIME' in http://travel.state.gov/travel/cis_pa_tw/cis/cis_1116.html for the U.S. consulate's opinion. Frankly, though, I'm overwhelmed at the efforts of two people who owed me exactly nothing. Yes, there are good people in the word. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I'm not the microphone police, but ...
My 2 cents: I firmly believe in the individual and voluntary aspects of IETF attendance. I also belong to both categories; sure my employer pays for the expenses, but nobody forced me to come over. (Come on it's Paris after all, although I have gone to all of the Minneapolis meetings, too. ;) I represent many things here -- first and foremost I'm an engineer and an end user. Naturally, my interests may be affected by what I do in my real work. I think that applies to most people here, and I think it would be naive to think otherwise. And whether or not people mention their affiliate at the mic is a much smaller issue IMO to whether they use their company email account. That is a much more visible and relevant label in IETF work that mostly happens on mailing lists anyway. Cheers, Aki ext Spencer Dawkins wrote: That would be fine, if I changed the Newcomer's Orientation :-) Spencer Spencer, However, many people here are not using their 'individual money' to get here in Paris. Our name badges list our employers (in most cases). I think its a different issue if I come to the mic and say, 'We at the ACME company would like to state, for the record, that we support the foo bar proposal and hope it becomes an official RFC as soon as possible. It doesn't bug me one-way or another if folks state their name who pays the bills. ___ 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: Completely out of scope: Restaurant reccomendation
Sounds like something the Tools Team could provide. Should I set up one? Henrik On 2005-08-02 11:13 Clint Chaplin said the following: So, who is going to volunteer to set up said wiki? I'm not technically proficient On 8/2/05, Olaf M. Kolkman [EMAIL PROTECTED] wrote: PS. Somebody suggested that it would be nice to have a meeting Wiki for recommendations on restaurants, stories about pickpockets, and other non process and non technical cruft. signature.asc Description: OpenPGP digital signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
A Complaint to the IETF and IESG (was Re: Please change the Subject: when you change the subject [Re: Sarcarm and intimidation])
I haven't changed the subject. The correct subject is sarcasm and intimidation. I have just provided specific examples of sarcasm and intimidation that have happened while working on spam issues for the IETF. Those specific exmaples fall under the topic of the subject header. Your complaint about subject change is frivolous. Nor am I playing rhetorical games with Noel Chiappa. I asked him a direct, relevant, specific question, and he didn't answer it. Instead he gave me a sarcastic, frivolous, and irrelevant response. The original story Chiappa gave about Parry meets the Doctor is often cited to mean: Did I give you the impression I cared about your feelings?, which means that they don't care what you think. This is sarcasm, and is exactly what Hallam-Baker started to complain about under the topic sarcasm and intimidation. The recent behavior by Carpenter and Chiappa has rather proved the point by Hallam-Baker, myself, and others. The frivolous complaints about message topic give the impression of intimidation. And I feel intimidated by the Chair's insistence on squelching the topic of sarcasm and intimidation and specifically any examples of sarcasm and intimidation involving IETF work on spam. So do others. This is inappropriate behavior by the current Chair, and by former IESG members. It is rather amazing that someone (a former IESG Member!) would be so brazen as to be sarcastic during a complaint about sarcasm and intimidation. Plainly, they seem to feel a right to be sarcastic. But I find no such right in the IETF or ISOC Code of Conduct, nor in the Mission Statement of the IETF. Just the opposite: One is expected to be courteous and respectful, and sarcasm is neither courteous nor respectful. A complaint on this inappropriate behavior is hereby brought to the attention of the IESG. Dean Anderson President Av8 Internet, Inc On Fri, 22 Jul 2005, Brian E Carpenter wrote: ... Does this mean that you think the IETF should disband the ASRG, drop all current I-D's relating to spam, and quit working on spam issues? What I think is that if you change the subject, you should change the Subject:, so that people who might be interested in Sarcarm and intimidation but aren't interested in Spam don't waste their time. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Internet Draft Process Procedure
They are posted if they follow the guidelines, in particular the mandatory text about intellectual property etc. See http://www.ietf.org/ietf/1id-guidelines.html Posting an I-D implies nothing about its status. It simply means it is on line for 6 months. A working group may decide to adopt a draft as a WG draft, and I suppose that could be called acceptance but it does not imply approval. Only a draft that has followed the full process (RFC 2026) can be approved by the IESG. I suggest reading the Tao at http://www.ietf.org/tao.html - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter IETF Chair Distinguished Engineer, Internet Standards Technology, IBM [EMAIL PROTECTED] wrote: Hello folks, Just a quick question about the acceptance of Internet-Drafts. Is there such a term called acceptance about Internet-drafts or they will be anounced anyway as long as being proposed? As I figured that it's like everyone talks about his/her opinions freely in the form of I-D. An I-D is certainly not equal to a journal paper. Looking forward to being clarified. Zhen ___ 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: I'm not the microphone police, but ...
There are cases where it is useful for a group to be able to take notice of first hand experience that comes from employment. For example I am currently reading a somewhat sureal thread in which an individual who clearly has no experience or understanding of running network operations for a large ISP (million plus customers) is lecturing folk on the lack of scalability of a protocol proposed by and already deployed by several ISPs of that type of scale. Another issue that frequently comes up is that people will assert that a proposal to make a new use of DNS will increase load on the system and thus risk bringing down core DNS and thus the Internet. Except in cases where the protocol is catastrophically bad and unnecessarily wasteful of resources these dire predictions have never yet proved true, nor are they likely to - most load on the core DNS is due to attacks and baddly configured DNS systems. Even if the load on the core DNS were to increase the point of the infrastructure is to serve the needs of users, not the other way around. The point I am trying to make here is that we are not dealing with a domain that is entirely academic theory. There are cases where operational experience is significant and affiliation can carry significance. If I hear several major infrastructure providers say that they have examined a proposal and the resource requirements do not cause them concern as far as their operations go I think it is reasonable to give such a statement considerable weight unless there are very good reasons to think otherwise. Likewise I would take a concern raised by several major infrastructure providers that a proposal did have unacceptable resource requirements very seriously, although I would want to see some documentation and explanation of the claim. We do not need to give a veto to major infrastructure providers but there has to be a mechanism that allows companies to raise issues on the record from time to time when they choose. If only to avoid the need to argue at interminable length why a 'scalability issue' is nothing of the sort. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: I'm not the microphone police, but ...
Interesting: I like you piercing spirit. But, I am afraid you are too much legacy intoxicated :-) what I think surprising. I suppose we agree but you have odd ways of seeing it. At 18:58 02/08/2005, Hallam-Baker, Phillip wrote: From: JFC (Jefsey) Morfin [mailto:[EMAIL PROTECTED] Except if you can grab a BCP. I am not sure you are actually right. You certainly know a few cases. The lack of an IETF endorsed spec from MARID did not stop Microsoft from holding an industry gala two weeks ago in NYC. Nobody commented or appeared to care that the spec was not ratified. Think of it as a recess appointment. The problem with IETF is there is no architectural common vision. No, that is its strength. The Web was not part of the IETF common vision. SSL was diametrically opposed to the IETF security vision. I am afraid you speak of details. These are applications. There is no common vision of the reality of the digital ecosystem nature. IETF has fun over layer 8 and 9. Layer 8 to 12 have a precise meaning, as has layer 0. Sharing this meaning would help a common analysis and avoid confusing Multilingual Internet with a bunch of typewritters, using typographer ISO tables to document it. IETF and IANA have a defacto monopoly on the architecture. No they don't. W3C and OASIS are both more influential as standards bodies at this point, particularly once we get above the session layer. Again you speak of details. Of applications. I am speaking of the network architecture. The evolution of the architecture is very very slow. What I say is that in the real world, users are not interested in all that. This is for application providers and applications are decided by the users. Who known the W3C and SGML 10 years ago. Will we still know them 10 years from now? The URI identifier architecture introduced in PICS and since adopted in XML eliminates the need for fixed registries like the IANA. That was the whole point, to eliminate the control point. I did not want a central registry of PICS censorship schemes. Of course other people did, mostly the people who used euphemisms like 'content selection' rather than censorship. Agree. But IMHO this is a way to introduce at application level the very basic root name principle introduced by Robert Tréhin and Joe Rinde in 1977 which founded the International Network, in part the OSI and defaulted to root with the Internet defaulting its architectural parameter to mono from multiple in Tymnet and from separated in OSI. This is what we have to correct now. I would phrase it another way. The IANA is one of the many roots in the International Network forest. But that trunc of that root hidden the forest. The Multilingual Internet is probably the best application to force and fund the necessary effort to look at the forests. But some suspect that the resulting user-centric architecture (each one having its many roots) has a different economical model. And status quo is the best target for dominant one. At ICANN they use to call the stakeholders For example the whole IPv6 issue is that they did not understand that their current deployement (2001) is disposable. The failure to get the deployment stakeholders round the table to ask the question 'what will it take to make this happen' is in my view the root cause. I do not. Because what will make it to happen is the disappearance of stakeholders. Let understand, the current network is made of people who want to organise, to sell, etc. it. The future stable IPv6 network by nature (it would not be an evolution otherwise) will be made of people wanting just want to use it. And the first thing they want to get rid of is the artificial limitations of the stakeholders. Take care. I am quite interested in your security factor in relations. Did you work on that (I did not recall exactly how you termed it: we called delta sec, and people grab the idea quick). I suppose that network security could be discussed in a similar way to network value? jfc ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
missing mouse
I seem to have left a small wireless mouse somewhere, probably the terminal room. Has anybody seen it? --aaron ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: I'm not the microphone police, but ...
--On Tuesday, August 02, 2005 07:23 -0700 Hallam-Baker, Phillip [EMAIL PROTECTED] wrote: Certainly there are bizare corporations attempting to achieve some sort of stranglehold. Anyone remember digital convergence and the CueCat? That type of behavior tends to come from market entrants rather than established companies. Once you have a stake in the open Internet the probability of success in a closed 'walled garden' scheme isn't high enough to be interesting. At the risk of providing an irritating counterexample or two... Please explain this to almost every wireless carrier in the world, especially those offering “3G” or similar Internet-based data services. Established actors, significant stake in the Internet, but business models based on walled gardens. A discussion with, e.g., AOL, might also be of interest.These are, I would suggest, established companies and fairly significant market actors. john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Protocol Action: 'Media Type Specifications and Registration Procedures' to BCP
The IESG has approved the following document: - 'Media Type Specifications and Registration Procedures ' draft-freed-media-type-reg-05.txt as a BCP This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Scott Hollenbeck. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-freed-media-type-reg-05.txt Technical Summary This document defines procedures for the specification and registration of media types for use in MIME and other Internet protocols. Combined with Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures (draft-freed-mime-p4), this draft obsoletes RFC 2048 if approved. Working Group Summary This document is the work of individual submitters. It was subjected to MIME-types review, but it is has not been reviewed by an IETF working group. MIME-type review comments have been incorporated into the document. Most IETF last call comments were also incorporated into the document, but one of the Last Call comments, explicitly allowing text subtypes to be treated differently in the restricted use case, was not accepted. There was rough consensus to support this decision. Protocol Quality Ted Hardie and Scott Hollenbeck have reviewed this specification for the IESG. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'TCP/IP Field Behavior' to Informational RFC
The IESG has approved the following document: - 'TCP/IP Field Behavior ' draft-ietf-rohc-tcp-field-behavior-04.txt as an Informational RFC This document is the product of the Robust Header Compression Working Group. It was also given a review by the TCPM Working Group. The IESG contact persons are Allison Mankin and Jon Peterson. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rohc-tcp-field-behavior-04.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'A Framework for Conferencing with the Session Initiation Protocol' to Informational RFC
The IESG has approved the following document: - 'A Framework for Conferencing with the Session Initiation Protocol ' draft-ietf-sipping-conferencing-framework-05.txt as an Informational RFC This document is the product of the Session Initiation Proposal Investigation Working Group. The IESG contact persons are Allison Mankin and Jon Peterson. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipping-conferencing-framework-05.txt The WG chair shepherd of this document was Gonzalo Camarillo. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'The TLS Protocol Version 1.1' to Proposed Standard
The IESG has approved the following document: - 'The TLS Protocol Version 1.1 ' draft-ietf-tls-rfc2246-bis-13.txt as a Proposed Standard This document is the product of the Transport Layer Security Working Group. The IESG contact persons are Russ Housley and Sam Hartman. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tls-rfc2246-bis-13.txt Technical Summary The Transport Layer Security (TLS) protocol provides secure communications for connection-oriented data. A large number of network protocols operate over TCP or other connection oriented transports. TLS provides a generic security layer which allows these protocols to treat a connection as an authenticated, confidential channel. TLS 1.0 and it's predecessor SSL are widely deployed. TLS 1.1 is an update to TLS 1.0 which clarifies some issues and fixes some known security problems. Working Group Summary This document is a fairly minor update to TLS 1.0. There are only a few technical changes, and they were fairly noncontroversial. No important unresolved issues were raised in Working Group Last Call. Protocol Quality TLS 1.0 is very widely deployed. GnuTLS claims to support TLS 1.1. Some of the changes in TLS 1.0 (reducing the number of different alert types sent) are implemented in standard TLS 1.0 implementations as well. The remaining changes to make TLS 1.1 (the explicit IV) are very minor and have already been implemented in OpenSSL in the context of DTLS, though not TLS. This document was reviewed by Russ Housley for the IESG. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Personal Security Reminder
Please be sure you do not leave any of your belongs unattended anywhere in the meeting venue, including meeting rooms. Your belongs may be picked up by either security or someone else and you may not be able to retrieve them. Several people already have computer bags picked up and they may or maynot be lost. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
PGP Key Signing at IETF63
Once again, we will be holding a PGP Key signing party at the IETF-63 meeting in Paris. We have been scheduled to meet at 1930 on the evening of Wednesday, August 3 in room 322M. As usual, if the plenary runs over, we will start approximately five minutes *after* the plenary session ends. Please note the unusual time, due to the change in the meeting schedule for this week. Note that even though the printed agendas say 2200, we will meet at approximately 1930, as indicated here and in the online agenda. In the unlikely event the agenda should conclude early, we will begin the key-signing approximately five minutes after the plenary, in order to allow people to take advantage of the extra time for dinner or evening social events. The procedure we will use is the following: o People who wish to participate may do so in one of two ways. You may bring slips of paper with your name, e-mail address, key-id, and key fingerprint. (One way of generating this if using gpg is gpg --list-keys --fingerprint [EMAIL PROTECTED]) You should bring enough for everyone who may attend; given recent attendance patterns, around 50 should be more than enough. (You can generally fit 10-12 strips containing your key fingerprint on a single sheet of paper, and then cut out strips to hand out.) o Alternatively, you may email an ASCII extract of their PGP public key to [EMAIL PROTECTED] by noon on Wednesday, August 3(*). Please include a subject line of IETF PGP KEY, and please DO NOT MIME-ENCRYPT your e-mail. Send it to me as plain text, and do NOT base-64 encode things. (My process is not quite as automated as Ted's, so I'll probably be able to notice and fix any problems, but it's better not to take chances). The method of generating the ASCII extract under Unix is: pgp -kxa my_email_address mykey.asc (pgp 2.6.2) pgpk -xa my_email_address mykey.asc (pgp 5.x) gpg --export -a my_email_address mykey.asc (gpg) If you're using Windows or Macintosh, hopefully it will be Intuitively Obvious (tm) using the GUI interface how to generate an ASCII armored key that begins -BEGIN PGP PUBLIC KEY BLOCK-. o By 1700 on Wednesday, you will be able to fetch complete key ring from any of the following locations with all of the keys that were submitted: /afs/grand.central.org/project/ietf-pgp/ietf63/ietf63.pgp http://grand.central.org/dl/ietf-pgp/ietf63/ietf63.pgp ftp://grand.central.org/pub/ietf-pgp/ietf63/ietf63.pgp o At 1930, come prepared with the PGP Key fingerprint of your PGP public key; we will have handouts with all of the key fingerprints of the keys that people have mailed in. o In turn, readers at the front of the room will recite people's keys; as your key fingerprint is read, stand up, and at the end of reading of your PGP key fingerprint, acknowledge that the fingerprint as read was correct. o Later that evening, or perhaps when you get home, you can sign the keys corresponding to the fingerprints which you were able to verify on the handout; note that it is advisable that you only sign keys of people when you have personal knowledge that the person who stood up during the reading of his/her fingerprint really is the person which he/she claimed to be. o Send the signed keys to the owners, and, optionally, to the PGP key servers. Some poeple opt to NOT send the signed keys to the keyservers, but rather choose to send them only to the e-mail address on the key's userid, encrypted for that particular key. This tends to ensures the validity of the e-mail address. Note that you don't have to have a laptop with you; if you don't have any locally trusted computing resources during the key signing party, you can make notes on the handout, and on the strips of papers, and then take these and sign the keys later. Acknowledgement: The bulk of the text of this message was taken from the messages usually sent by Ted Ts'o to announce IETF key signing parties. (*) Normally I'm pretty lax about the noon deadline, accepting things as late as during the plenary. However, in order to keep things running on time with the unusual schedule of this week's meeting, I intend to prepare the photocopied fingerprint lists before the plenary session. So, I'll be applying the deadline more strictly than usual. -- Jeffrey T. Hutzelman (N3NHS) [EMAIL PROTECTED] Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
