<p dir="ltr">Hello,</p>
<p dir="ltr">nice to hear the there are intentions to make a openwrt/lede solution. We are now using a freecwmp fork ( EasyCwmp ) to configure our devices. Freecwmo was mit maintained anymore. We extend the parameter set with the openwrt parameter which are not in the standard.</p>
<p dir="ltr">Will the Meeting online (irc) for everyone?</p>
<p dir="ltr">Regards</p>
<p dir="ltr">Flo<br></p>
<p dir="ltr">Am 28.05.2016 1:34 nachm. schrieb "Hauke Mehrtens" <<a href="mailto:hauke@hauke-m.de">hauke@hauke-m.de</a>>:<br>
><br>
> On 05/27/2016 12:43 PM, David Lang wrote:<br>
> > On Thu, 26 May 2016, Delbar Jos wrote:<br>
> ><br>
> >> We are conscious of the fact that together with the proposals made by<br>
> >> Felix, Luka and Wojtek we are now looking at many "competing"<br>
> >> proposals. As a next step, we recommend to organize a workshop, at a<br>
> >> practical location and time, where we put everything on the table and<br>
> >> define the most appropriate path forward to the benefit of OpenWrt as<br>
> >> a whole.<br>
> ><br>
> > nothing wrong with supporting many different remote management daemons.<br>
> ><br>
> >> TR-069 is a complicated remote management system and in order to make<br>
> >> this initiative a success, we must ensure that the complexity is<br>
> >> handled in an elegant way and with respect for OpenWrt's core<br>
> >> architecture. More than on the protocol itself, we believe that we<br>
> >> should focus on the architectural enhancements required to support<br>
> >> remote management in general.<br>
> ><br>
> > What is it that you think is needed to "support remote management in<br>
> > general"?<br>
> ><br>
> > It's worth pointing out that many people are remotely managing OpenWRT<br>
> > devices, Ansible/Salt/Puppet/Chef/etc are all common tools for the job.<br>
> ><br>
> > now, those are all tools aimed at managing Linux Servers, not networking<br>
> > gear, but OpenWRT is a server.<br>
> ><br>
> > So I'd suggest starting off by creating a daemon that talks <your<br>
> > protocol> and just stores the stuff it's sent in some simple files so<br>
> > that it can return the info when queried.<br>
> ><br>
> > Once you have something that talks the network protocol correctly,<br>
> > modifying it to change the real files, make uci calls, etc for different<br>
> > distros is much easier (just write your daemon with the expectation that<br>
> > the input and output details are going to change, so don't get fancy<br>
> > with them).<br>
> ><br>
> > David Lang<br>
><br>
> The TR-069 family is currently wildly used by ISPs controlling the (DSL)<br>
> CPE devices of their customers. There are probably more than 100 million<br>
> device controlled by standards from the TR-069 family out there.  When<br>
> you get a DSL router from your ISP or buy one in the retail store it is<br>
> very likely it supports the standards from the TR-069 family, as a<br>
> vendor in this area you basically need support for this to sell your<br>
> devices.<br>
><br>
> In other technologies you have different protocols to manage your<br>
> devices, like cable often uses something different and EPON and GPON<br>
> even have all their own management standards. Then there are also some<br>
> technology independent standards and so on. It makes sense to build such<br>
> a solution in a way to make it easily to expendable for new protocols.<br>
><br>
> Hauke<br>
> _______________________________________________<br>
> openwrt-devel mailing list<br>
> <a href="mailto:openwrt-devel@lists.openwrt.org">openwrt-devel@lists.openwrt.org</a><br>
> <a href="https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel">https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel</a><br>
</p>