Joel, On Tue, Mar 31, 2015 at 12:02 PM, Joel M. Halpern <[email protected]> wrote:
> Actually Ray, IETF process, as described by the IESG, happily allows for > Downref with suitable approval and notice to the community. So, as far as > I can tell, homenet could indeed reference and mandate Babel in a Proposed > Standard RFC. I would agree that homenet choosing to do that would be a > strong impetus for moving the document to Standards track. But that does > not have to be gating. > > https://trac.tools.ietf.org/group/iesg/trac/wiki/DownrefRegistry RFC 6126 is both experimental and through the ISE. The experience with it is not equivalent to that with standardized protocols. As I said in Dallas, if the mandatory-to-implement protocol for homenet is babel, it will need to be standardized through the IETF consensus process. Ideally, with motivation, that would be quick. Regards, Alia > Yours, > Joel > > > On 3/31/15 11:54 AM, Ray Bellis wrote: > >> >> On 31 Mar 2015, at 16:35, Dave Taht <[email protected]> wrote: >>> >>> I don't see any point in starting up a new working group[1] whatsoever >>> based on the events of the last ietf homenet meeting, particularly >>> with the arrival of a new written from-spec version of babel in under >>> 15 hours, (which I am still chortling about. I am tempted to write one >>> in rust). >>> >> >> Whilst full standardisation of Babel may end up happening in a WG anyway, >> some of this design team's job will be to establish whether it's more >> expedient to bring Babel up to "proposed standard" levels of specification >> than to add Homenet-related features (per your list below) to existing IETF >> endorsed standards. >> >> It is just punting the question and more delay when stuff that is more >>> than sufficiently stable is done, already, and shipping, with a 5 year >>> long productization pipeline left to fill. >>> >> >> For better or worse, IETF process dictates that we cannot use what is >> officially an _experimental_ protocol in a standards track document. >> Markus' work was very impressive, but not sufficient to overcome that >> hurdle. >> >> However this _should_ be a very short-lived punt - less than one IETF >> cycle. The WG was unable to reach consensus over three full IETF cycles, >> and this structured design team approach _should_ clear this log jam. >> >> (If it helps any (which I doubt) I have never thought that homenet >>> must settle on one routing protocol, and certainly the from the ISP >>> part of the link is underspecified) >>> >>> At least one routing protocol must be available, however to turn back >>> the tide of the current situation where none are commonly available in >>> most consumer routing gear. More than one IS available. >>> >> >> We are arguing on the choice of one _mandatory to implement_ protocol. >> For interoperability's sake, this will be the one that "must be available". >> >> Nothing can (nor will) prevent additional protocols from being >> implemented, and perhaps even operate simultaneously. >> >> Aside from that my major two requirements have only been >>> >>> 0) Must support source specific routing >>> 1) A homenet capable routing protocol MUST work well over wifi and >>> wireless links in addition to conventional ethernet and other mac >>> layers >>> >>> My minor requirements were: >>> >>> 0) Binary and memory sizes must be small enough to fit into teeny routers >>> 1) should be wildly available in every off the shelf OS that might be >>> used for routing >>> 2) should be extensively tested in environments ranging from homes, to >>> battlemesh, to small business campus networks >>> 3) Should have a good spec, must have at least one open sourced and >>> liberally licensed implementation >>> >> >> These requirements are all very well understood. >> >> So to me, y'all are wasting time that could be better spent into A) >>> pouring resources into making hnetd less the monster than it became, >>> >> >> please elaborate (in a separate thread, please!) >> >> B) dogfooding what exists and C) developing better tests and D) >>> developing better metrics >>> >>> PS However. >>> >>> [1] I would not mind a working group that took the outputs of the >>> battlemesh folk (babel, olsr-ETX, batman, bmx) and stacked them up >>> against the outputs of the ietf working groups (like RPL, olsrv2, and >>> others from manet and elsewhere) - and the IEEE (like all the layer 2 >>> isis stuff) and that wg BOTH tackled them in the working group AND in >>> the real world - and worked to sort out the mess of academic code and >>> real world requirements in the hope, that one day, maybe before I die >>> of old age and/or apoplexy, the one true routing protocol and metrics >>> emerged from the chaos. >>> >> >> If enough people backed that and a suitable charter was agreed that could >> happen. >> >> kind regards, >> >> Ray >> >> _______________________________________________ >> homenet mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/homenet >> >>
_______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
