Re: [homenet] actual requirements for standardization of an ietf protocol?
Regards Brian Carpenter http://orcid.org/-0001-7924-6182 On 26/03/2015 05:37, Juliusz Chroboczek wrote: >> The yak we are shaving here, is whether two inter-operable implementations >> leveraging the same mit-licensed source code base (as in the base babeld >> daemon and the quagga implementation) are acceptable to this wg. > > Dave, > > Alia is right -- there do not at the current time exist two independent > implementations of Babel. > > We can argue about whether that is a reasonable requirement, but we cannot > argue about the above, which is a fact. But she also said, or rather logically implied, that if there was a babel WG it could decide that two strictly independent implementations were *not* required for Proposed Standard. Of course the AD and the IESG would have to agree, but it is perfectly allowed by the current IETF rules. BTW there is also no rule that WGs must hold meetings. Reaching rough consensus on the WG list is necessary and sufficient under the rules. It's rare but entirely possible. Brian ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] actual requirements for standardization of an ietf protocol?
> The yak we are shaving here, is whether two inter-operable implementations > leveraging the same mit-licensed source code base (as in the base babeld > daemon and the quagga implementation) are acceptable to this wg. Dave, Alia is right -- there do not at the current time exist two independent implementations of Babel. We can argue about whether that is a reasonable requirement, but we cannot argue about the above, which is a fact. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] actual requirements for standardization of an ietf protocol?
On Wed, Mar 25, 2015 at 8:58 AM, Alia Atlas wrote: > In the Routing Area, it depends upon the WG as to whether 2 interoperable > implementations are required. This is always the case in, for example , > IDR. For a new routing protocol, I think it would be appropriate to be > comfortable that others can implement it and it works well. The yak we are shaving here, is whether two inter-operable implementations leveraging the same mit-licensed source code base (as in the base babeld daemon and the quagga implementation) are acceptable to this wg. > > Regards, > Alia > > On Mar 25, 2015 7:43 AM, "Brian E Carpenter" > wrote: >> >> > 1) I don't know where the "2 separate implementation" concept is >> > embedded formally in the ietf structures for approval. >> >> It isn't, for Proposed Standard status, although historically the >> Routing Area has been tougher than the rest of the IETF because of >> reasonable concern that a faulty routing protocol can produce more >> horrible failure modes than pretty much anything else. >> >> http://tools.ietf.org/html/rfc4794 may clarify a bit. >> >> For advancement to Internet Standard there is a requirement >> for 2 implementations but that is not germane to the current >> discussion. (http://tools.ietf.org/html/rfc6410) >> >> Sigh. It's embarassing how baroque the IETF process documents >> have become, but it would be a lot of uninspiring work to >> clean them up. That's why I've been maintaining this page for >> a few years now: http://www.ietf.org/about/process-docs.html >> (And yes, I'm aware it's overdue for an update.) >> >> Brian >> >> ___ >> homenet mailing list >> homenet@ietf.org >> https://www.ietf.org/mailman/listinfo/homenet -- Dave Täht Let's make wifi fast, less jittery and reliable again! https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] actual requirements for standardization of an ietf protocol?
In the Routing Area, it depends upon the WG as to whether 2 interoperable implementations are required. This is always the case in, for example , IDR. For a new routing protocol, I think it would be appropriate to be comfortable that others can implement it and it works well. Regards, Alia On Mar 25, 2015 7:43 AM, "Brian E Carpenter" wrote: > > 1) I don't know where the "2 separate implementation" concept is > > embedded formally in the ietf structures for approval. > > It isn't, for Proposed Standard status, although historically the > Routing Area has been tougher than the rest of the IETF because of > reasonable concern that a faulty routing protocol can produce more > horrible failure modes than pretty much anything else. > > http://tools.ietf.org/html/rfc4794 may clarify a bit. > > For advancement to Internet Standard there is a requirement > for 2 implementations but that is not germane to the current > discussion. (http://tools.ietf.org/html/rfc6410) > > Sigh. It's embarassing how baroque the IETF process documents > have become, but it would be a lot of uninspiring work to > clean them up. That's why I've been maintaining this page for > a few years now: http://www.ietf.org/about/process-docs.html > (And yes, I'm aware it's overdue for an update.) > > Brian > > ___ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] actual requirements for standardization of an ietf protocol?
> 1) I don't know where the "2 separate implementation" concept is > embedded formally in the ietf structures for approval. It isn't, for Proposed Standard status, although historically the Routing Area has been tougher than the rest of the IETF because of reasonable concern that a faulty routing protocol can produce more horrible failure modes than pretty much anything else. http://tools.ietf.org/html/rfc4794 may clarify a bit. For advancement to Internet Standard there is a requirement for 2 implementations but that is not germane to the current discussion. (http://tools.ietf.org/html/rfc6410) Sigh. It's embarassing how baroque the IETF process documents have become, but it would be a lot of uninspiring work to clean them up. That's why I've been maintaining this page for a few years now: http://www.ietf.org/about/process-docs.html (And yes, I'm aware it's overdue for an update.) Brian ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
[homenet] actual requirements for standardization of an ietf protocol?
I saw this message go by today: http://www.ietf.org/mail-archive/web/homenet/current/msg05073.html where the author stated: "If there were a solid specification and second implementation of babel, babel would win on the basis of functionality." A) As for the first, babel is pretty fully documented in a multiplicity of individual submissions and a pair of formal (to-me) looking RFCs. Certainly could use more eyeballs! Does it really need a dedicated working group? B) As for the second part of that statement, there is a second implementation in quagga, but it is indeed from the same people. I have LONG believed in the need for two or more implementations from a specification in order for it to be a good spec. However: 0) Modern protocols are really hard to write down in english. Open C code is generally more clear (at least to me!), as are accompanying documents that can actually incorporate graphs and math. Plain text does not cut it. The IEEE does a bit better job in this regard than the ietf, IMHO. 1) I don't know where the "2 separate implementation" concept is embedded formally in the ietf structures for approval. So far as I know that was an old requirement, long dropped. What rfcs mandate this? Was it mandated for http 2/0, for example? Did that happen? Is it mandated for RPL? Has anyone ever produced an interoperable version of ospf or ISIS solely from the spec? 2) Given the ready availability of very open (MIT licensed source code) I think doing independent code from scratch is a waste of time and a waste of what few valuable resources exist for furthering better routing protocols and routing/kernel software in general. (I would certainly, ultimately, like a version of babel that could be poured into gates and run with a much tighter update interval at 100GigE, but I can leverage the C code for that also. I don´t think an in-kernel version is needed, either. Would a ns3 version of a given routing protocol meet the requirement for a competing implementation? Back in the days when we had to write stuff in assembly, or gates, I tend to think that the two separate implementation requirement made sense, but not in an age where source is so freely available. 3) In the upcoming babel 1.6 release, I hope to see support for atomic route updates, (not present in any linux routing daemon I know of besides olsrd - and I do hope that code gets into quagga bgp in particular when it stablizes), support for openwrt procd init replacement (reliable restarts in case of failure), autodetection of IPV6_SUBTREES at runtime, and a few other features. After babeld-1.6 released, I expect it to be quickly taken up by the entire linux (debian/fedora) ecosystem, as well as bsd, as well as (if it stabilizes soon enough) openwrt chaos calmer, it´s deriviates, buildroot, and yocto. Basic babeld already being available as a standard - and universally identical - package in so many parts of the ecosystem is one of the basic babeld´s advantages over quagga, which has a good dozen competing forks with different behavior and interfaces, and a mess of competing implementations and feature sets in isis, ospf, and bgp. An analogy I would use to favor babel is much like the one that let firefox take over from mozilla - that a small team, no committee, strong maintainer, makes for better software. in babeld 1.7: A) I would hope to see the currently quagga-only https://tools.ietf.org/html/rfc7298 authentication extensions pushed into babel using a modern, safe, well debugged crypto toolkit like nacl, if needed... and some ideas towards partially authenticated routes explored. B) Given the issues with configuring hnetd + dhcp + babel + firewall + dnsmasq, I would like to see all that gain a configuration bus much like dbus, kdbus, or ubus. C) I personally hope to gain the time to finally come up with an RTT based availability, capacity, utilization metric leveraging the unique characteristics of fq_codel (which is the current de-facto queue type for openwrt, and thus homenet, and more or less what is going into make-wifi-fast). What I think I got here will distinguish - without using BFD - between wifi, wireless, homeplug, ethernet, and other forms of connectivity pretty cleanly, I hope, without explicit configuration. But I am unwilling to promise that (been a goal of mine for 18 years!), and certainly there are other things on my plate taking priority. (the math will work out fine for other routing protocols that want to take advantage of the same assumptions) And after that (or during), I would like to see work towards getting ECMP and multicast to work, speedups on solving for wider diameter networks, ability to take advantage of more wireless statistics, etc. All this is stuff building on what already exists, and exhausts what few developers are available *already* on what little funding exists. As I have long noted, it would be awesome to gain more developers working on quagga, babeld, olsr, manet, rpl, etc to
