Hi Joel, As I understand it, the downref policy is intended to allow references to Informational or Experimental documents in specific cases. The page you referenced says: "Exceptions to this rule are sometimes needed as the IETF uses informational RFCs to describe non-IETF standards or IETF-specific modes of use of such standards."
I don't think it is intended to allow a downref to a protocol defined in a non-IETF RFC. Babel was published as an Independent Submission Experimental RFC. We have already been told by at least one AD that they wouldn't approve that sort of downref, but that may not represent a final decision of the IESG. If this is something the Homenet WG may want to do (even though we didn't have consensus to do this during the meeting), would it be possible for us to get an answer from the IESG about whether they would approve this, as part of our selection process? Margaret On 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 > > 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
_______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
