INTERNET-DRAFT N. Elkins Network Working Group Inside Products Intended Status: Informational Expires: June 17, 2016 December 15, 2015 Unwritten Rules and Values of the IETF draft-elkins-ietf-unwritten-rules-values-00 Table of Contents 1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1 IETF and the Internet ecosystem . . . . . . . . . . . . . . 4 1.2 The shared vision of the IETF . . . . . . . . . . . . . . . 5 1.3 The IETF is not just an RFC mill . . . . . . . . . . . . . . 5 1.4 The IETF works . . . . . . . . . . . . . . . . . . . . . . . 6 1.5 The IETF is a community . . . . . . . . . . . . . . . . . . 6 2 The IETF has values . . . . . . . . . . . . . . . . . . . . . . 6 2.1 Do your own work . . . . . . . . . . . . . . . . . . . . . . 7 2.1.1 Steal ideas politely . . . . . . . . . . . . . . . . . . 7 2.1.2 Don't try to manipulate others . . . . . . . . . . . . . 7 2.1.3 Build your own small cottage . . . . . . . . . . . . . . 7 2.2 Do really good work . . . . . . . . . . . . . . . . . . . . 8 2.2.1 Don't present drafts just to get time on the agenda . . 8 2.2.2 How to do really good work? . . . . . . . . . . . . . . 8 2.2.3 A possible path to doing really good work . . . . . . . 10 2.2.4 How to get started in a new WG . . . . . . . . . . . . . 10 2.2.5 How to get started contributing on the email lists . . . 11 2.2.6 Start a study group . . . . . . . . . . . . . . . . . . 11 2.2.7 Don't be afraid to have bad ideas . . . . . . . . . . . 11 2.3 Have it work in reality, not just theory . . . . . . . . . . 12 2.4 Have it work for everybody . . . . . . . . . . . . . . . . . 12 2.5 Work with others for the good of the community and shared vision . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.5.1 Listen to others . . . . . . . . . . . . . . . . . . . . 12 2.5.2 Admit mistakes . . . . . . . . . . . . . . . . . . . . . 13 2.5.3 Ask for help or clarification . . . . . . . . . . . . . 13 2.5.3 Be a team player . . . . . . . . . . . . . . . . . . . . 13 2.5.4 Notable results of collaboration . . . . . . . . . . . . 13 2.5.5 Don't try to game the system - false collaboration . . . 14 2.5.6 Collaboration and inner circles . . . . . . . . . . . . 14 2.5.7 Help out . . . . . . . . . . . . . . . . . . . . . . . . 14 2.6 Be honest . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.7 Be transparent . . . . . . . . . . . . . . . . . . . . . . . 15 2.8 Have integrity . . . . . . . . . . . . . . . . . . . . . . . 16 2.9 We are equal . . . . . . . . . . . . . . . . . . . . . . . . 16 Elkins Expires June 17, 2016 [Page 1] INTERNET DRAFT elkins-ietf-unwritten-rules-values-00 December 15, 2015 2.10 Care an awful lot about what you are doing . . . . . . . . 16 2.11 You represent yourself, not your company . . . . . . . . . 16 3 Social aspects . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.1 The "Old Boys' Club" . . . . . . . . . . . . . . . . . . . . 16 3.2 Finding your "people" . . . . . . . . . . . . . . . . . . . 17 3.3 Disagreeing with people . . . . . . . . . . . . . . . . . . 17 3.4 Social aspects which don't matter . . . . . . . . . . . . . 18 3.5 Social aspects which probably matter . . . . . . . . . . . . 18 4 Cultural aspects . . . . . . . . . . . . . . . . . . . . . . . . 19 4.1 Logical fallacies . . . . . . . . . . . . . . . . . . . . . 19 4.2 For cultures that value group harmony . . . . . . . . . . . 19 4.3 For cultures that respect their elders . . . . . . . . . . . 19 4.4 For cultures that value structure . . . . . . . . . . . . . 19 4.5 For cultures that value individual achievement . . . . . . . 20 4.6 Community and rough consensus . . . . . . . . . . . . . . . 20 4.7 Collaboration for individualistic cultures . . . . . . . . . 20 5 Collaborative Innovation Network (COIN) . . . . . . . . . . . . 20 6 Final thoughts . . . . . . . . . . . . . . . . . . . . . . . . . 21 7 Security Considerations . . . . . . . . . . . . . . . . . . . . 21 8 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 21 9 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 21 9.2 Informative References . . . . . . . . . . . . . . . . . . . 21 10 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 Elkins Expires June 17, 2016 [Page 2] INTERNET DRAFT elkins-ietf-unwritten-rules-values-00 December 15, 2015 Abstract The intent of this document is to speed up the process by which someone new to the IETF, can understand the objectives, fathom the environment, comprehend the culture, learn to navigate the problems, overcome the obstacles, and become a more productive IETF participant, in a shorter amount of time. Further, this document is intended to pass along the learning and experiences of people who have absorbed these values, perhaps in a much longer amount of time and with much greater effort and even hardship. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright and License Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License Elkins Expires June 17, 2016 [Page 3] INTERNET DRAFT elkins-ietf-unwritten-rules-values-00 December 15, 2015 1 Background This work came about as a result of work with the IETF mentoring program. There were a number of incidents where there appeared to be a misunderstanding of what might be called "values" or "unwritten rules". For example, one person (American male-white) felt that his Internet- Draft (I-D) was not proceeding because he did not attend (or know about) a private drinking party which is often held at the IETF and that many decisions were made because one belonged to an "inner circle". The author assured him that she fell asleep and forgot to go to the private drinking party and that has not in any way impeded the progress of her work at the IETF (that she knows of!). The other issues are with the way that people talk to each other on the email lists and at Working Group sessions. The current (sometimes brutally) frank interchange at the IETF is in the range of normal (if at the extreme range) for some people but off the spectrum for others. In the coming years, as the Internet permeates every corner of the earth, we need to have as many people of good will, intelligence and commitment involved to help solve the problems of the Internet and do the work of the IETF. So, it seemed to the author that making explicit some of the ways that the IETF operates and why would help relative newcomers understand more about the IETF and be able to become productive in a shorter amount of time. As this document progressed, it became clear that another important purpose of this document is to serve as a positive vision of an organization that IETFers can be proud to belong to -- a group whose function is critical in the world we live today and the foreseeable future. 1.1 IETF and the Internet ecosystem The IETF creates the innovation that is needed to make the complex system that is the Internet adapt to its environment. If an organism does not adapt to its environment, it will become extinct. In biological systems, nature via evolution serves the function of gradual adaptation. Nature, however, is not able to make computer networks and protocols adapt. But, such a facility is needed, hence the need for an entity which will help the Internet adapt to its ever-changing environment. The IETF is evolution for the Internet. Another way to say this may be: "The IETF exists to solve problems in the Internet." [Baker] Elkins Expires June 17, 2016 [Page 4] INTERNET DRAFT elkins-ietf-unwritten-rules-values-00 December 15, 2015 This purpose will become key in the later sections. It is easy to say "we will innovate" but the environment needed to truly innovate is a very special one. Another point which is sometimes forgotten is that in order to adapt, it is important to have a very accurate assessment of the environment. As the Internet permeates every corner of the globe, the environment is more and more complex. We need, more than ever, to represent as many view points as possible so that the innovations are effective. [Cite other RFCs] 1.2 The shared vision of the IETF The Internet, what it means, and collaborating (working together) to have it adapt to the environment is the shared vision of the IETF. What the Internet means is the free and open exchange of ideas between as many people as possible. So, as an unwritten rule, if something is seen as threatening this shared vision it will be seen as a core threat to the group. On the other hand, if something supports the effectiveness of the IETF and supports the vision, then even if what you do is "radical", in the sense that it has not been done before, then there will be support for your ideas. 1.3 The IETF is not just an RFC mill There is no question that in the end, a document called an RFC which represents community consensus on a problem or how to resolve a problem will often be created. Having said that, the IETF does not just churn out RFCs. That is an overly simplistic view of what actually happens. There are ongoing conversations between people, via email, on the email lists, by conversations over lunch or at a bar. Some of these will end up changing a point of view which may result a year later in a published document. What happens on the email lists is very important. These are ongoing conversations about various topics and have the thinking about why certain problems are solved a certain way. These are public -- for a reason. Then, the deliberations are transparent. Hallway conversations at IETF meetings are also very important. If you can at all do it, attend IETF in person. Work is being done in various geographic regions to have remote hubs. This may be a good way to start collaborations with others in your geographic region. People want to be involved in the IETF because they see it as having Elkins Expires June 17, 2016 [Page 5] INTERNET DRAFT elkins-ietf-unwritten-rules-values-00 December 15, 2015 prestige and importance. This is a bit misguided because it leads people to do things that are visible to the outside but not really helpful to the core mission and community. The actual reason that IETF has prestige and importance is that it creates the new ideas and innovations that are needed for the Internet. This is the shared vision of the IETF. People are working for something that is bigger than themselves and collaborating with others to do it. 1.4 The IETF works Whatever you may say are faults in the IETF (and there are a number which many of us are trying to fix), it works. A small number of people have created and continue to create innovations that affect the entire world through the Internet. How? The unspoken rules and values of the IETF are a fundamental reason for why this works. 1.5 The IETF is a community There was once a story told by a wise man about a Russian physicist who had been trying unsuccessfully to resolve a research problem for a long time. One night, he had dinner with some of his friends and talked openly about things that he had not been able to talk about for many years. The next day, he had the breakthrough idea for his research. Something about honesty, trust and community allows us to innovate in ways that we don't know how to even describe. But, it happens. The IETF is proof of that. 2 The IETF has values What are these values? -Do your own work -Do really good work -Have it work in reality not just theory -Have it work for everybody -Work with others for the good of the community and shared vision -Be honest -Be transparent -Have integrity -We are equal -Care an awful lot about what you are doing -You represent yourself, not your company Elkins Expires June 17, 2016 [Page 6] INTERNET DRAFT elkins-ietf-unwritten-rules-values-00 December 15, 2015 2.1 Do your own work 2.1.1 Steal ideas politely Here is a case showing what not to do. A team authoring an I-D was found to have knowingly taken their work from someone else who had a patent (IPR) on that idea. This can be done but "careful acknowledgement and citation of sources and references" [Carpenter] must also be done. The IPR holder was contacted and the issue was resolved but that is not the point. The point is that the people on that team were now seen as "stealing ideas" from others. So, what happens? Some IETFers will not co-author papers with members of that team. When people from that team present, there is often silence in the room. If there is silence in the room, this is very bad. IETFers are not quiet and they feel passionately about ideas. If no one is commenting, this is because either your idea is so bad that no one is going to waste their breath or because you have violated a rule of the group very badly. (Such as this one.) 2.1.2 Don't try to manipulate others Here is a technique not to follow. Writing an I-D that parallels an existing WG doc and then asking strongly and repeatedly to merge the new I-D with the existing document so as to get names added to the original document is not doing your own work, honest or transparent. People will remember that you tried to do this. As Abraham Lincoln said: "You can fool all the people some of the time, and some of the people all the time, but you cannot fool all the people all the time." In this case, you are not fooling any of the people any of the time. 2.1.3 Build your own small cottage If you do your own work and it turns out to be a small, honest, well- built cottage and not the Taj Mahal, it is fine. If it is your own idea, you have developed it well, listened to the feedback of others, built consensus, and have had it adopted by a Working Group, then before you know it, the people building the Taj Mahal may turn to you. They will likely ask you if you want to help with planning the garden or something else at the Taj Mahal. You don't need to try to Elkins Expires June 17, 2016 [Page 7] INTERNET DRAFT elkins-ietf-unwritten-rules-values-00 December 15, 2015 manipulate or steal from others. Many people stay involved with the IETF for many years. They will remember both the good and the bad that you do. It is like living in a small village. 2.2 Do really good work 2.2.1 Don't present drafts just to get time on the agenda Here is a case study of what not to do. A team authoring a draft has ideas that are not well thought out, not based on any real experience or even good theory. Such a team works for a company known to give promotions, awards or money based on number of RFCs published. The team is seen to be self serving and putting out ideas not for the greater good or for the betterment of the shared vision but only for themselves. So, what happens? When people from that team present, there is often silence in the room. The silence is from people authoring in that WG who care passionately about the topic and have items of their own that they would like the group to discuss. They feel that valuable agenda time is going to people who do not really deserve it and are not going to give more time to these people by asking questions. Some experienced IETFers are very kind and will comment to the effect that the idea or presentation is fundamentally flawed. If someone who is an "icon" of the IETF says something to you like that, listen. They are being very generous to you. If they actually point out flaws, listen even more carefully. The fact that they even read and commented on your work means that they are trying to help you. Doing good work, if you have even the germ of a good idea, is actually one of the easier things to achieve. 2.2.2 How to do really good work? It will take years of experience, study, and hard work. There are no short cuts. If you are not willing to put in the work and have the commitment, then you probably don't belong at the IETF. If you are willing to put in the work and have the commitment, then try to form a group of people who can work with you. This can be really helpful. A team of people with average intelligence will often be better than a solitary genius. (Of course, if you can have Elkins Expires June 17, 2016 [Page 8] INTERNET DRAFT elkins-ietf-unwritten-rules-values-00 December 15, 2015 geniuses collaborate...then you get some REALLY great results) Work hard. Research your ideas really well. See how they work in practice. Get feedback from others. Elkins Expires June 17, 2016 [Page 9] INTERNET DRAFT elkins-ietf-unwritten-rules-values-00 December 15, 2015 2.2.3 A possible path to doing really good work -Talk with the WG chair or experienced person about if your idea fits in the WG charter and may be worth exploring -Work on a draft with a team -Each person can work on a portion -Review the draft together -Present to a small audience -You may want to do all of this in your local language, if that is more comfortable for you -You may want to do this 2 or 3 times -Ask for a review from a WG chair or experienced person, in a private session. -Ask for review of the draft from a number of trusted, experienced people (maybe you met them at mentoring events!) -Go to the email list for your WG for comments -Ask for agenda time 2.2.4 How to get started in a new WG Before you get started on the path, you want to understand what is going in whatever Working Group you are interested in. You may want to do the following steps: - Watch the email list for about 6 months to a year. Try to make sure that you understand everything that people are talking about. Don't say anything - just read and watch what others are talking about. Look to see who are the most respected contributors and what they are thinking. You don't have to agree with them, it is just good to know the "lay of the land", if you will. Each group has core contributors. - Read the core RFCs for that group (every group has them). Make sure that you understand all the terms and concepts that people are discussing. - Look at packet traces using Wireshark of the protocols under question. Some people have hundreds that show different aspects of the protocol. - Look at the drafts the WG has adopted and what problem they are trying to solve. Read and understand the drafts and the discussion around them. If you have to, create a sheet per draft for each discussion item, pros and cons of the argument. - Look at the charter for the WG, the documents it wants to produce and the timeline. Elkins Expires June 17, 2016 [Page 10] INTERNET DRAFT elkins-ietf-unwritten-rules-values-00 December 15, 2015 - Then, look at the individual submissions. Make your own decisions about how closely you want to look at these. Some are raising some very interesting points and highlighting problems that you may not have considered. - This all takes quite a bit of time and energy. But, if you want to be taken seriously, then you will be a serious person. Others who have 20+ years in the industry and teach protocols also do the above steps to join a new Working Group. 2.2.5 How to get started contributing on the email lists Be careful about what you say on the email list and how you start contributing. Again, be serious. This is a very serious thing we are doing. The IETF supports the Internet. Many of the people here have been working on networks and protocols for much of their working lives. When you say something, think hard about what you are saying before you say it. People will remember it and you do not want to be seen as someone who talks without knowing what they are talking about. If you get that reputation, it will be very hard for you to overcome. Best not to say anything for a while. 2.2.6 Start a study group If you need to form a study group with others, great. Do it. The author has a small private group for each of the WGs that she is involved with. We talk over what happens on the email list and in the WG sessions. You may want to practice doing presentations to each other of what is being discussed or different interesting protocol problems. We try to do this in a lab setting as well so that we can have hands-on experience. Of course, for protocols that are not yet implemented by anyone, this is not possible to do 2.2.7 Don't be afraid to have bad ideas Sometimes, in order to learn, you have to take risks. That means that you may propose an idea or an I-D that is really a bad idea. Having bad ideas is a part of the process of having good ideas. What this really means is that making mistakes and figuring out why you failed, is a part of the path to success. In particular, when we are talking about innovation, playing it too safe means that the ideas you have may not be really creative. Make mistakes, learn from them, have more ideas. Soon, your ideas will start actually start solving real problems. The community will tell Elkins Expires June 17, 2016 [Page 11] INTERNET DRAFT elkins-ietf-unwritten-rules-values-00 December 15, 2015 you. 2.3 Have it work in reality, not just theory That means writing code if you possibly can, and testing it. Try to use multiple platforms and operating systems. You will learn a lot. You may end up revising your design. You cannot design protocols in a vacuum. 2.4 Have it work for everybody If you want network devices to inter-operate over the Internet, then you have to work together with others. This can be slow. In fact, some people complain that the IETF process is too slow. There is no question that improvements can be made. But, it is important that others who may be impacted by the decision be heard. Definitely, it is easier and faster to just work within one company. But, if the goal is interoperability, then you have to work together with others. Without interoperability, the Internet as we know it would not exist. There is a proverb which some say is from Africa and others from China: "If you want to go fast, go alone. If you want to go far, go together." 2.5 Work with others for the good of the community and shared vision 2.5.1 Listen to others No one knows the whole truth. But by working together and listening, we can approach the truth. The fable of the Blind Men and the Elephant may be helpful: Six blind men were asked to determine what an elephant looked like by feeling different parts of the elephant's body. The blind man who feels a leg says the elephant is like a pillar; the one who feels the tail says the elephant is like a rope; the one who feels the trunk says the elephant is like a tree branch; the one who feels the ear says the elephant is like a hand fan; the one who feels the belly says the elephant is like a wall; and the one who feels the tusk says the elephant is like a solid pipe. How does this apply to the IETF? Some people only look at how middle boxes view the network, others look only at the end user Elkins Expires June 17, 2016 [Page 12] INTERNET DRAFT elkins-ietf-unwritten-rules-values-00 December 15, 2015 viewpoint, others have the stack developer perspective, some have the chip vendor perspective, still others focus on an academic perspective, etc. When you have an idea or an I-D, actively seek written feedback from others, read it carefully, and change things accordingly. The first version of a design or document is never correct. Also, if one reader misunderstands a sentence, so will many others. Fix the sentence, because you can't fix the readers. 2.5.2 Admit mistakes If you make a mistake, admit it. If you are wrong, say it. It is easy to get passionate about something and get carried away. Here is an example of a mature way to deal with a mistake from an experienced contributor: "(From) my own message from last Friday, I realized after clicking send that I was out of line and want to apologize to John for the tone of the note. John knows and understands the community WiFi service use case in ways that I do not, so it was inappropriate for me to profess knowledge of the use case that I do not have". 2.5.3 Ask for help or clarification This is from an email exchange "I may be being stupid, but I think I'm still not following. Do you think you could provide a ladder diagram showing the messages that demonstrate the attack you are concerned about?" This is from a person who wrote some of the seminal RFCs of the IETF. He is far from stupid. But, one of the reasons that he is not stupid is that he asks for clarification until he understands. You may want to ask privately when you are a newcomer. Many people at the IETF are very kind and generous, they will often be happy to help you. 2.5.3 Be a team player For example, everyone wants agenda time. Don't try to push your way in front of others. Don't ask for more time than you need. When the chair says that you are running short of time, sit down quickly. If your work is interesting, then people will come and talk to you. 2.5.4 Notable results of collaboration DHCP, TLS and many other efforts in the IETF are a result of a wonderful collaboration. Elkins Expires June 17, 2016 [Page 13] INTERNET DRAFT elkins-ietf-unwritten-rules-values-00 December 15, 2015 This work is also a collaboration. See the Section on Acknowledgements. 2.5.5 Don't try to game the system - false collaboration When you get consensus calls on the email lists and people who almost never participate respond with support with almost the same words, this is gaming the system. People will remember you. 2.5.6 Collaboration and inner circles On the other hand, asking the most active participants to review your work is probably smart. They will be able to see the most flaws. This is what you want. Are these people the inner circle? Probably. But they generally got to be the inner circle by doing the most good work and caring an awful lot about what they do. Can you become a part of the inner circle? Yes. How? Do really good work and care passionately about what you are doing. 2.5.7 Help out Every organization needs things done. The IETF is a volunteer organization. Help others and you will find that others will help you. This is how you do things in your own community - your church, synagogue, mosque, temple, Parent-Teacher Association (PTA), or any other volunteer organization that you may belong to. 2.6 Be honest If you want to be accepted, try not to be seen as having a private agenda. That is, your work is only for the benefit of your company or to get a promotion for yourself. It is important that people think of you as someone where "What you see is what you get". That is, you say what you really think. Your word is good. Your handshake is good. A typical IETFer can be almost brutally honest in his / her interchanges. This can sometimes seem quite rude. People can do Elkins Expires June 17, 2016 [Page 14] INTERNET DRAFT elkins-ietf-unwritten-rules-values-00 December 15, 2015 better in this but in a heated exchange of opinions, sometimes people say things badly. If you are not honest, it is hard for people to trust you. Having said that, remember that what you say may be heard around the world. You are being recorded at a meeting. The email lists will live forever on the Internet. Be honest but have some discretion 2.7 Be transparent Transparency means that you share what you know with the group. You don't hide the mistakes. You don't leave out stuff. You don't whitewash (pretend something is white when it is actually gray). Just share everything - the good and the bad. If it works, it is great. It is to the credit of the group and the community. This transparency also applies to the people who are watching the email lists. The decisions made by the IETF are important and people need to know why they were made. Elkins Expires June 17, 2016 [Page 15] INTERNET DRAFT elkins-ietf-unwritten-rules-values-00 December 15, 2015 2.8 Have integrity Your opinion should be your considered technical opinion and not just that of the company you currently happen to work for. Flip-flopping (changing your opinion) when you change companies will be seen and remembered. This is called having integrity. 2.9 We are equal Everyone can voice their opinion This does not mean everyone is the same. Some people know more about some things than others. But everyone has the right to a voice and to be heard. The best engineering solution should, of course, win. At the IETF, there is very little hierarchy. The motto is "We reject: kings, presidents and voting. We believe in: rough consensus and running code." [Clark] I have heard of some companies who tell their people not to disagree in public. Especially, not to contradict senior members of the company. This is not in the true spirit of honest debate over engineering principles. 2.10 Care an awful lot about what you are doing Loving what you are doing and being passionate about it is very important in doing good work. People can tell when you really care about the work and care about doing good work. Many of the people at the IETF care very much. That is why they are here. 2.11 You represent yourself, not your company At the IETF, you are an individual. This has a long history. You represent your own opinions, not those of your company. 3 Social aspects 3.1 The "Old Boys' Club" Some people think there is an "old boys club" at the IETF. Every community has people who have been there a long time. One of the reasons for this paper is to show you how to break into the "old boys club" while not being old or a male! Elkins Expires June 17, 2016 [Page 16] INTERNET DRAFT elkins-ietf-unwritten-rules-values-00 December 15, 2015 Quite a few IETFers live to read protocols. For many, it is one of the most enjoyable things in the world. It is not actually hard work. But, even such people have to work very hard at the IETF. In fact, many are appreciative of the opportunity to HAVE to work hard, to collaborate with people who are their intellectual peers, have a shared vision in something greater than themselves, believe in what they do, and a personality structure similar to theirs. When we hear a "You did a good job" or have support from one of the "icons" of the IETF, we appreciate this immensely. Being able to contribute to the group and have the respect of people that you yourself admire and respect, is the personal motivation to work for the betterment of the IETF. Of course, the responsibility and privilege of supporting the Internet which has become an integral part of life for many in the world, is the larger reason and vision. 3.2 Finding your "people" So, if you feel that there is an "Old Boys Club", it is in some ways relief at actually having found "your people". People who fit in very well at the IETF sometimes cannot be quite as frank in their interchanges in "real world". So, many IETFers, find it a relief to be with a large group of people that you can trust, who will not hold it against you if they are brutally honest about how your idea (which you believe in passionately) will not work (and are actually right), and in fact, will be extremely glad for your comments and see it as an opportunity to work even harder. Such people may be called "anti-fragile". If you take the example of some weeds, for example, dandelions, which are very hard to eradicate and actually thrive when you try to cut them down, then you will understand the concept of "anti-fragile". It is rare that you can be quite that honest in a group. But that very honesty is one of the ways that really good engineering happens. 3.3 Disagreeing with people Can you disagree with people? This question often comes up when the person involved is a superior in your own organization or from your own culture. The short answer to this is: yes But do it kindly and respectfully. Sometimes people get passionate and forget. Then, they can be harsh. But they may be right. Elkins Expires June 17, 2016 [Page 17] INTERNET DRAFT elkins-ietf-unwritten-rules-values-00 December 15, 2015 3.4 Social aspects which don't matter Going out drinking with people and staying out really late do not matter. Going to "private parties" does not matter. Some people don't want to drink a lot of alcohol for religious reasons or health reasons, or just want to go to bed early because they have done plenty of partying in their life and they are tired. They prefer to get up early in the morning and exercise or go for a walk to watch the sun rise. It does not matter. It will not make a bit of difference in your WG or any work that you do. Just do really good work that helps the core vision Your race, culture, political system, the company you work for, gender, what you wear, or your age do not matter. Just do really good work that helps the core vision. There is no question that in the world that we live in, white privilege, gender privilege, age-ism, social class privilege, cultural privilege and many other privileges that we wish did not exist, do exist. Unfortunately, we have imbibed these with our mother's milk. Having said that, we have an opportunity at the IETF to bypass all of these because computer systems and protocols do not care who developed them. They will not work better because of who you are. Protocols work, do not work or work sub-optimally. The best way to overcome the "isms" of the world is to do absolutely outstanding technical work and be able to prove it. (See Section 2.2 on Doing Really Good Work). 3.5 Social aspects which probably matter Don't be seen as "stand-offish" or arrogant or hang out only with people from your own company or culture. This makes people feel that you don't like them. How to do this : if there is an excursion going somewhere, join it. People will often say, "Does anyone want to go see Mt. Fuji with me?" Do it. You could even initiate an activity yourself. It is a way to get to know people and build trust. Don't take yourself that seriously. Have some fun with people. Be helpful to the group in ways that clearly do not promote your own interests. See what the group needs, what the problems are, and try to help fix them. As John Kennedy said, "Ask not what your country can do for you, but what you can do for your country." Review other people's draft with constructive criticisms. Ask the WG chair how you can help. Take minutes. Elkins Expires June 17, 2016 [Page 18] INTERNET DRAFT elkins-ietf-unwritten-rules-values-00 December 15, 2015 4 Cultural aspects We are each products of our culture. We absorb the modes of being and values of our culture as we grow. At the IETF, we need to work with others who come from very different cultures with very different values. 4.1 Logical fallacies Some cultures value authority and tradition which is, of course, admirable. But, sometimes, it can lead to what are called logical fallacies. That is, using something to support an argument which is not valid. Some of these follow: Appeal to authority: Something is right because of who said it Appeal to tradition: Something is right because that is how we have always done it Bandwagon fallacy: Something is right because many people support it If you find yourself doing any of these, step back and reconsider 4.2 For cultures that value group harmony It is OK to disagree. We are trying to find the best engineering solution to a problem -- that is what matters 4.3 For cultures that respect their elders It is not disrespectful to disagree with your elders. My daughter sometimes sees things that I don't. I am glad she tells me. The best engineering solution is what matters. We are a community. We have a responsibility to the vision we share. 4.4 For cultures that value structure Some cultures value knowing your place in the overall scheme of things. Hierarchy and respect are important. The IETF may seem very non-hierarchical but this does not mean it is chaotic. There are WG chairs, Area Directors, and a process for if you think you have not been treated appropriately. There are also people who have a LOT of experience and whose opinion counts. Too much structure can stifle innovation. Elkins Expires June 17, 2016 [Page 19] INTERNET DRAFT elkins-ietf-unwritten-rules-values-00 December 15, 2015 4.5 For cultures that value individual achievement Some cultures put a high value (overly high value?) on the freedom and creativity of the individual. Some even have a romantic image of the lone cowboy riding off into the range. Indeed, it is good to value the individual. But, more often than not, a group will do a much better job than an individual. The drawback of individualistic cultures is that the more aggressive individuals may dominate. Their ideas may not be the best. They may intimidate others from participation because they criticize others harshly. Even if they are right, the attitude is "Let the best win and the devil take the hindmost." If this seems like an experience that you may see in some IETF Working Groups - try to take the high road and disagree with kindness. 4.6 Community and rough consensus The community is the ultimate decider of what we do. You are a part of the community Rough consensus is good because if all these people with all these backgrounds and experiences pretty much agree on something, then it is probably good. How do you know they agree? For example, after you have a draft or a posting which has had a LOT of discussion and you have made revisions, and no one is jumping up and down, then you know you have it right. If some of the known leaders or WG chairs tell you that you are doing a good job or they like your work, then you have it right. This is not easy but it is worth it. 4.7 Collaboration for individualistic cultures Very often, the best engineering solution comes from a collaboration. Sometimes it is the quiet individual in the back, who if he / she felt safe enough to speak, could add a great deal to the conversation. They may not want to speak in such a harsh environment. When doing truly creative innovation, you need to be able to be vulnerable with each other. If the environment harshly rejects mistakes or incomplete thoughts, much is lost. More communal cultures have the strength that (at their best) the leadership concentrates on group achievement rather than individual achievement. 5 Collaborative Innovation Network (COIN) Elkins Expires June 17, 2016 [Page 20] INTERNET DRAFT elkins-ietf-unwritten-rules-values-00 December 15, 2015 There is a social science term called COIN [COIN] which may describe what happens at IETF. "COINs feature internal transparency and direct communication. Members of a COIN collaborate and share knowledge directly with each other, rather than through hierarchies. They come together with a shared vision because they are intrinsically motivated to do so and seek to collaborate in some way to advance an idea." The features of COIN are: -Ethical principles -Trust and self-organization -Knowledge accessible to everyone -Internal honesty and transparency 6 Final thoughts Things don't always work this way at the IETF. There are private agendas, overly aggressive individuals, poor judgment, and just plain mistakes. But, it is worth fighting to make it work according to our core values The IETF has to approach being a meritocracy. The technical solutions have to approach being the best. Otherwise, this whole thing would fall apart And, clearly, it hasn't 7 Security Considerations There are no security considerations. 8 IANA Considerations There are no IANA considerations. 9 References 9.1 Normative References 9.2 Informative References [Baker] Baker, F. "Journey from I-D to RFC", Work In Progress, November 2015 Elkins Expires June 17, 2016 [Page 21] INTERNET DRAFT elkins-ietf-unwritten-rules-values-00 December 15, 2015 [Carpenter] Carpenter, B. "What is an Author of an IETF Stream Draft?", draft-carpenter-whats-an-author-02, Work In Progress, June 2015 [Clark] Clark, D. "A Cloudy Crystal Ball -- Visions of the Future", http://groups.csail.mit.edu/ana/People/DDC/future_ietf_92.pdf, July 1992 [COIN] https://en.wikipedia.org/wiki/Collaborative_innovation_network 10 Acknowledgments The author would like to thank (in alphabetical order) Mike Ackermann, Fred Baker, Brian Carpenter, Ralph Droms, Marius Georgescu, Vinayak Hegde, William Jouris, Victor Kuarsingh, Mirjam Kuehne, Carlos Martinez, Christian O'Flaherty, Gowri Visweswaran and Greg Wood for their comments and review. Authors' Addresses Nalini Elkins Inside Products, Inc. 36A Upper Circle Carmel Valley, CA 93924 United States Phone: +1 831 659 8360 Email: nalini.elkins@insidethestack.com http://www.insidethestack.com Elkins Expires June 17, 2016 [Page 22]