That works for me in both cases of wearing/not wearing WG hat. Cheers Terry
On 20/12/11 9:52 PM, "Jari Arkko" <[email protected]> wrote: > I have looked at the latest version of the new charter. We've made progress > (e.g., I liked the changes Dino suggested on removing some of the inaccurate > definitions) and I'm generally happy, except with three aspects: > > o v4 runout is no longer "impending" > > o the removal of the VPN etc wording has made the draft vague about what work > is exactly in scope. > > o some editorial things > > I have tried to fix these in the version below. > > In any case, I have taken the recharter of the working group to the next IESG > telechat which IIRC is on the first Thursday in 2012. I'm sure some editing of > the version below will be needed, hopefully we can complete this before the > IESG call. > > Jari > > Locator/ID Separation Protocol (lisp) > ------------------------------------- > > Charter > > Current Status: Active > > Chairs: > Joel Halpern <[email protected]> > Terry Manderson <[email protected]> > > Internet Area Directors: > Ralph Droms <[email protected]> > Jari Arkko <[email protected]> > > Internet Area Advisor: > Jari Arkko <[email protected]> > > Secretaries: > Wassim Haddad <[email protected]> > Luigi Iannone <[email protected]> > > Mailing Lists: > General Discussion: [email protected] > To Subscribe: https://www.ietf.org/mailman/listinfo/lisp > Archive: > http://www.ietf.org/mail-archive/web/lisp/current/maillist.html > > Description of Working Group: > > The IAB's October 2006 Routing and Addressing Workshop (RFC 4984) > rekindled interest in scalable routing and addressing architectures for > the Internet. Among the many issues driving this renewed interest are > concerns about the scalability of the routing system. Since the IAB workshop, > several > proposals have emerged which attempt to address the concerns expressed > there and elsewhere. In general, these proposals are based on the > "locator/identifier separation". > > The basic idea behind the separation is that the Internet architecture > combines two functions, routing locators, (where you are attached to the > network) and identifiers (who you are) in one number space: The IP > address. Proponents of the separation architecture postulate that > splitting these functions apart will yield several advantages, including > improved scalability for the routing system. The separation aims to > decouple locators and identifiers, thus allowing for efficient > aggregation of the routing locator space and providing persistent > identifiers in the identifier space. > > LISP requires no changes to end-systems or to most routers. LISP aims > for an incrementally deployable protocol. > > A number of approaches are being looked at in parallel in other > contexts. The IRTF RRG examined several proposals, some of which were > published as IRTF-track Experimental RFCs. > > The LISP WG is chartered to work on the LISP base protocol, completing the > ongoing work, > and any items which directly impact LISP protocol structures and are related > to using LISP for improving Internet routing scalability. Specifically, the > group will > work on: > > - LISP security threats and solutions > - MIBs > - deployment models > - allocation of EID space > - alternate mapping system designs > > In addition, if work chartered in some other IETF WG requires changes > in the LISP base protocol or any items which directly impact LISP > protocol structures, then the LISP WG is chartered to work on such > changes. > > The working group will encourage and support interoperable LISP > implementations as well as defining requirements for alternate mapping > systems. The Working Group will also develop security profiles for LISP > and the various LISP mapping systems. > > It is expected that the results of specifying, implementing, and testing > LISP will be fed to the general efforts at the IETF and IRTF to understand > which > type of a solution is optimal. The LISP WG is not chartered to develop a > standard > solution for solving the routing scalability problem at this time. The > specifications developed by the WG are Experimental and labeled with > accurate disclaimers about their limitations and not fully understood > implications > for Internet traffic. In addition, as these issues are understood, the > working group will analyze and document the implications of LISP on > Internet traffic, applications, routers, and security. This analysis > will explain what role LISP can play in scalable routing. The analysis > should also look at scalability and levels of state required for > encapsulation, decapsulation, liveness, and so on as well as the > manageability and operability of LISP. Specifically, the group will work on: > > - documenting areas that need experimentation > - summarizing the results of implementation, experiments, and deployment > experience > - describing the implications of employing LISP > - operational guidance for using LISP > > Goals and Milestones > > Jun 2012 Forward draft-ietf-lisp-mib to the IESG > Jun 2012 Forward draft-ietf-lisp-sec to the IESG > Jun 2012 Forward to the IESG an operational document which should > include cache management and ETR synchronization > techniques (draft-ietf-lisp-deployment). > Dec 2013 Publish an example cache management specification. > Dec 2013 Forward to the IESG an evaluation of the security threat to > cache maintenance (draft-ietf-lisp-threats) > Dec 2013 Forward to the IESG a document addressing the areas which > require further experimentation. > Jun 2014 Evaluate the applicability and coverage for LISP from a > reuse of SIDR technology. > Jun 2014 Summarize results of specifying, implementing, and testing > LISP and forward to IESG and/or IRTF. > Jun 2014 Analyze and document the implications of LISP deployments in > Internet topologies and forward to IESG for publication. > Dec 2014 Re-charter or close _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
