On Tue, Mar 31, 2015 at 12:58 PM, Joel M. Halpern <[email protected]> wrote:
> As I read the rules, if Alia does not want to allow the downref, it can't > happen. But if she and the working group both want it, and the IETF last > call accepts it, then it can happen. This is an example of the rules > allowing us to do what we as a community think is best. > As I said in the meeting, my concern is not because of the process requirements - but because of the experience and improvements found during the standardization and interoperability process. Even the partial implementation that was done brought up a couple different issues in either documentation or code. Regards, Alia > Yours, > Joel > > On 3/31/15 12:25 PM, Margaret Wasserman wrote: > >> >> 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] >> <mailto:[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
