From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-iy0-f171.google.com (mail-iy0-f171.google.com [209.85.210.171]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 80706200ABA for ; Thu, 22 Sep 2011 14:57:08 -0700 (PDT) Received: by iagv1 with SMTP id v1so5843796iag.16 for ; Thu, 22 Sep 2011 14:57:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=TQoC8f1+0AQZo15fcZ9jkHlO7CDtqnJeM5XyDI1ce7c=; b=cQycnaiIzooEqV16fzJ0zY17wBU8OrSyD2E2oEgrp74tYtleH0gifEJ5KcBZma3AsT uRBdD1XuWx9SnZMEUmKOg0MvOq1dpVKFJYUKoViykGBOsa5m3VFDMR9KayQOzZme+oMm 9KPU8KJzbv+8gStMWOlD2GDjnz9AEtbc19mag= MIME-Version: 1.0 Received: by 10.42.156.3 with SMTP id x3mr2975276icw.212.1316728627614; Thu, 22 Sep 2011 14:57:07 -0700 (PDT) Received: by 10.43.132.8 with HTTP; Thu, 22 Sep 2011 14:57:07 -0700 (PDT) Date: Thu, 22 Sep 2011 14:57:07 -0700 Message-ID: From: Dave Taht To: debloat-proposals@lists.bufferbloat.net Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: [Debloat-proposals] Comments on the ISC deliverable section X-BeenThere: debloat-proposals@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2011 21:57:08 -0000 A) Explore the elements needed to build an economically sustainable open source CPE/Home Gateway that would be operationally used throughout Comcast and the world. Cool! B) Explore and deliver a functional requirement document for a initial generation of open source CPE/Home Gateway. This is really, really difficult, and an example of the problem we face in developing specifications in our over-complex world. Functional requirements documents can be kept short, say, 3 pages, or made unbelievably long - say, for example, the DOCSIS specs, which last I looked weighed in at well over 1000 pages. An example of this sort of rat-hole: "Must have IPv6". Well, how much of IPv6 do you want? Do you need IPsec? How about HIPL? SCTP? Secure send? etc? To take on another rat-hole: Does Prefix delegation count? does PD have to integrate with bind9, downstream with autoconfig clients, upstream with dhcpv6, and if so what other parts of dhcpv6 are needed? To read more on just this one problem see the current features list of dibbler[1], and note that there's only one guy working on that. I would suggest limiting the scope of this to 'short, high-level functional requirements document' to avoid sinking into specification hell. I do note that using "IPv6" as a checkbox item hasn't worked yet, however, despite years of the government trying, and the current set of "IPv6 certified" products is disappointing, to say the least. Feeding back into that certification process would be good. A point I tried to make at the meeting was that I wanted to separate the 'feature development' from the 'end product'. dibbler and isc-dhcp need features developed and tested - which can then, later, make it into products. radvd needs love, as does ipsec in general, and there are too many other packages to list, here, that in the end will make or break a successful deployment, when finally integrated by the vendor. So, in conclusion I would like to replace this bullet point entirely with something like: "Assess the health of various required-for-good-cpe projects (number of developers, development activity, end-user usage, funding level) and provide a plan for moving them in the directions needed". Which is far, far, far easier and more useful than a functional specificati= on. C) Perform a risk assessment of open source licenses to insure the structure of the license will support a sustainable ecosystem particular to BSD/GPL open source licenses. As I noted in the meeting it was my hope that 14+ years after the phrase 'open source' was coined that most companies would have developed a strategy for dealing with this that we could crib from. That said, I concluded, days later, that some assessment is needed. I can provide a list of packages and licenses to all that are used in the openwrt project - but the point to remember is that most of the license conflicts have been resolved over the last decade, and the vast majority of software in *userspace* allows for *non-viral linking*. I'm hard pressed to think of anything left, anymore, that we link to, that doesn't have a permissive license. And there are far more licenses than merely BSD/GPL in use - there are apache licenses, free beer licenses, the isc license, the sun license etc. What is a risk assessment, exactly, in this context? Revised wording: "Perform an assessment of open source licenses to insure the structure of the licenses will support a sustainable ecosystem." 4) Build a business plan enabling fund raising/partnerships and building a formal =93home=94 for the project as it progresses. If it were up to me, this would be number 1. This is a task too big for any one company or developer group. 5) Preliminary assessment, with rough timelines and budgets, for additional development of a specific OS (if available), or ground up development (if no appropriate OS is found) to a level suitable for deployment as an R&D or production platform, including initial requirements for necessary management and testing tools. As for this last one, I'm going to take it on in the next email. [1] http://klub.com.pl/dhcpv6/#ROADMAP --=20 Dave T=E4ht SKYPE: davetaht US Tel: 1-239-829-5608 http://the-edge.blogspot.com