> On Oct 7, 2022, at 02:31, Alvaro Retana <[email protected]> wrote: > > On October 6, 2022 at 12:55:28 PM, Dino Farinacci wrote: > > > Hi! > >>> I think that is the place to say that we will also work on relevant >>> Informational and Experimental work. >> >> I definitely agree with this statement. > > > This version of the charter is basically the same as the current > charter -- minus the multicast work item, plus some wordsmithing. I > don't see much value in going through the rechartering process without > significant changes to the charter. IOW, if the work items are the > same then let's just keep working! :-) >
It is very conservative if we stick to providing connectivity, connecting machines rather than applications.. By definition of overlays there is already connectivity. The opportunity can be in extending what lisp identity/mobile/ephemeral routing can do.. which underlays cant, or cant do well and leave too much for applications to do again and again. > > Joel's full proposal was: > >> Second, the first part of the charter says we will only work on standards >> track documents. I think that is the place to say that we will also work on >> relevant Informational and Experimental work. Probably with some verbiage >> that says Informational would be drafts which talk about how to use the LISP >> tools, and Experimental would be for things which need further evaluation >> (success or failure of the experiment) that add to the LISP protocol suite. > > Instead of opening the charter to "relevant" things, I rather include > a known list. Note that even if the intent is to work on Standards > Track documents the WG may decide later that a specific (listed) work > item requires further evaluation and make it Experimental. We don't > need the charter to say that. > > So...are there specific work items that (a) talk about how to use > LISP, or (b) should be added to the list (where the status can be > determined later), or (c) should be taken off the list? > In my opinion there are, specifically in application routing. Good wording can open the charter just enough to include application design patterns which leverage lisp w/o a flood of phrasing every application as a lisp draft. Drafts are a big overhead which take years and burden wgs, so such a balance is important. Charter wording can open lisp-routing specifications for: - distributed multi-vendor eco sys apps - leveraging next-gen mobile/green compute - scattered all over but function as a network - w/o the traditional CSP/MSP concentration - w/o impossible chatty centralized resolutions - based on the strengths of lisp aggregation: o eid logical algorithmic flexible addressing o mapping cached-(in)coherency balance o mass multicast, channels as mainstream Each such generic factoring of application routing saves industry time and money re-inventing wheels, figuring out proper layering, building wasteful inefficient api integrations. I have in mind automotive/geospatial, network cyber-security/AI sampling coin, and edge-iot / geo-distributed map-reduce, map using lisp-mapping, and reduce to lisp multicast channels/eid-topics. > > Thanks! > > Alvaro. > > _______________________________________________ > lisp mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lisp _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
