On Mon, Apr 14, 2014 at 9:56 AM, Andy Bierman <andy@xxxxxxxxxxxxx> wrote: > > > > On Mon, Apr 14, 2014 at 9:07 AM, Alia Atlas <akatlas@xxxxxxxxx> wrote: >> >> On Mon, Apr 14, 2014 at 11:57 AM, David Meyer <dmm@xxxxxxxxx> wrote: >> > On Mon, Apr 14, 2014 at 8:08 AM, George, Wes <wesley.george@xxxxxxxxxxx> >> > wrote: >> >> I’m surprised that no one has sent this out yet: >> >> http://gigaom.com/2014/04/12/why-i-quit-writing-internet-standards/ >> >> >> >> "Summary: After contributing to standards organizations for more than >> >> seven >> >> years, engineer Vidya Narayanan decided it was time to move on. >> >> Although she >> >> still believes that these organizations make the Internet a better >> >> place, >> >> she wonders about the pace of change versus the pace of organizations." >> >> >> >> My thoughts- >> >> >> >> There are some nuggets of truth in what she says in this article, and >> >> in >> >> some of the comments. I think that the problems are real, so there’s >> >> value >> >> in taking the criticism constructively, despite the fact that the >> >> author >> >> chose to focus on the problems without any suggestions of solutions. >> >> >> >> "while the pace at which standards are written hasn’t changed in many >> >> years, >> >> the pace at which the real world adopts software has become orders of >> >> magnitude faster." >> >> … >> >> "Running code and rough consensus, the motto of the IETF, used to be >> >> realizable at some point. … In the name of consensus, we debate >> >> frivolous >> >> details forever. In the name of patents, we never finish.” >> >> … >> >> "Unless these standards organizations make radical shifts towards >> >> practicality, their relevance will soon be questionable.” >> >> >> >> I don’t have too many big ideas how to fix these problems, but I’ll at >> >> least >> >> take a crack at it in order to spur discussion. My paraphrase of the >> >> problem >> >> and some discussion follows. >> >> >> >> - We’ve lost sight of consensus and are too often derailed by a vocal >> >> minority of those willing to endlessly debate a point. >> >> >> >> Part of the solution to that is reiterating what consensus is and is >> >> not, >> >> such as draft-resnick-on-consensus so that we don’t confuse a need for >> >> consensus with a need for unanimity. Part of the solution is IETF >> >> leadership >> >> helping to identify when we have rough consensus encumbered by a debate >> >> that >> >> will never resolve itself, without quieting actual disagreement that >> >> needs >> >> continued discussion in order to find a compromise. I don’t have good >> >> suggestions on how to make that second half better. >> >> >> >> - We don’t have nearly enough focus on running code as the thing that >> >> helps >> >> to ensure that we’re using our limited cycles on getting the right >> >> things >> >> out expediently, and either getting the design right the first time, or >> >> failing quickly and iterating to improve >> >> >> >> The solution here may be that we need to be much more aggressive at >> >> expecting any standards track documents to have running code much >> >> earlier in >> >> the process. The other part of that is to renew our focus on actual >> >> interop >> >> standards work, probably by charter or in-group feedback, shift focus >> >> away >> >> from BCP and info documents. Perhaps when considering whether to >> >> proceed >> >> with a given document, we need test as to whether it’s actively >> >> helpful/needed and ensure that we know what audience would be looking >> >> at it, >> >> rather than simply ensuring that it is “not harmful” and mostly within >> >> the >> >> WG’s chartered focus. >> > >> > My friend @colin_dixon pointed this out to me yesterday, and I've been >> > giving it quite a bit of thought since then (I have a nascent blog on >> > the topic of how open source and standards orgs might >> > productively/efficiently work together; follow up to >> > >> > http://www.sdncentral.com/education/david-meyer-reflections-opendaylight-open-source-project-brocade/2014/03). >> > >> > What I can say is that after seeing the kind of progress that several >> > open source communities make (they do epitomize the best of the IETF's >> > running code/rough consensus ethic), one does have to wonder if >> > traditional standards making is either obsolete or in dire need of a >> > make over. What is needed, IMO, is a reimagining of how the standards >> > process interacts with the open source movement specifically focused >> > on how they can compliment one another. >> >> [Alia] It would be very useful to have a functional model for how the >> two can compliment each other. We also tend to talk about open-source >> as a single monolith - when it can have very different models for >> accepting in changes, how and who runs the community, who is really >> participating (open source doesn't mean non-corporate) etc. Some of >> what the IETF does is the architecture and requirements thinking about >> how the solution should fit in - while some of the open-source is >> about getting a solution implemented ASAP. IMHO, a spiral is useful >> with an easy way of interaction. With I2RS, as a WG chair, I >> suggested having experimental drafts describing solutions that were >> being implemented - but haven't seen any. A question is what is >> needed to encourage the interactions. >> > > > +1 > > I was going to mention OpenDaylight as a cooperation model. > I think their goal is to provide implementation feedback to > the I2RS, NETMOD, and other WGs. > > The corporate acceptance of open-source software is the key trend. > I would not characterize any of these well-funded projects as > quick-and-dirty, or "solution implemented ASAP" (any more than > every commercial project I've worked on in my career. :-) > > >> [Alia] Diversity of implementation is important as is stability of a >> standard and it being understood how to change/upgrade for different >> versions. These don't come automatically via open-source. BTW, this is one area where the open source development methodology (and communities) doesn't operate in the same way traditional standards orgs do (e.g., IETF). Code diversity arises *inside the project* (in the same way consensus does). Note that this is fundamentally different than the black box model that we have at the IETF, and is one of the key reasons while multiple implementations are important; we can't see anything but what's on the wire. Obviously this is (fundamentally) not the case with open source. In addition, if all we can see is what's on the wire then it makes very good sense to also want to be able to verify whether a protocol is sufficiently specified to enable interoperable implementations. A question one might ask to try to elucidate the difference is whether it makes sense to ask if there are multiple interoperable implementations of say, OpenStack? Equivalently, does it make sense to ask what interoperates with OpenStack? --dmm >> > > Right. Vendors have to decide to contribute engineering hours to a project, > similar to the decision to let engineers contribute to SDOs. > > Open-source software can move the "standards boundary" > and achieve multi-vendor support at the north-bound API only. > For example, a vendor can provide a proprietary Python plug-in > (e.g. OpenStack Neutron) for an open-source platform, without > standardizing the south-bound protocols. > >> Regards, >> Alia >> > > Andy >