On 3/31/15 9:25 AM, 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.
The concern about labels is offputting, the downref policy is about exception handling, and the mechanics of reviewing and approving it has a lot to do with the necessity of making the normative reference, since it's already been established that the status is a problem. > 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? my own .02 is that I don't think we're really forging new ground here. if you can refer to rfc 3174 which is pretty foundational then this has already been considered... > 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 >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
