Fred, I'm not keen on specifically listing _any_ RFCs in the charter. It just doesn't add meaning at this stage of the WG lifecycle, in my opinion.
How about a simpler: 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. This provides the reader of the charter with knowledge that there is a body of work "out there" and points to the RRG as a place to look first. Beyond that we would probably fall into the trap of listing almost every RFC that has (had) anything to do with scaling, EID/LOC split, encapsulation .. .. .. etc. Cheers Terry On 29/09/11 10:16 PM, "Templin, Fred L" <[email protected]> wrote: > Hi Joel, > >> -----Original Message----- >> From: Joel M. Halpern [mailto:[email protected]] >> Sent: Wednesday, September 28, 2011 8:11 PM >> To: Templin, Fred L >> Cc: Terry Manderson; [email protected] >> Subject: Re: [lisp] LISP (re-)Charter discussion >> >> Fred, "Authorized" is I think the wrong word to use to describe the >> publication. Or at least a misleading word. The IRTF >> process is such >> that the RG did not actually approve the publication of any of the >> solutions. The RG Chair sponsored the publication as an >> output of the >> RG. IRTF procedures explicitly recognize and allow for multiple >> minority reports from an RG. >> >> I do agree that we should recognize that a number of ideas have been >> published as RFCs. And we should probably not be too specific about >> what the RG is doing, since that is liable to change. > > OK. How does this look for a rewrite: > > "A number of approaches have been published in parallel in the > IRTF and IETF. In particular, the IRTF Routing Research Group > (RRG) has published recommendations [RFC6115] and design goals > [RFC6227], and has released three solution proposals for > publication in IRON [RFC6179], hIPv4 [RFC6306] and ILNP [ILNP]." > > Thanks - Fred > [email protected] > >> Yours, >> Joel >> >> On 9/28/2011 10:20 PM, Templin, Fred L wrote: >>> Hi Terry, >>> >>> Regarding the 5th paragraph of the Draft Charter: >>> >>>> A number of approaches are being looked at in parallel in >> the IRTF and >>>> IETF. At this time, these proposals are at an early stage. >>> >>> This needs to be updated; here is a proposed rewrite: >>> >>> "A number of approaches have been published in parallel in the >>> IRTF and IETF. In particular, the IRTF Routing Research Group >>> (RRG) has published its recommendations [RFC6115] and design >>> goals [RFC6227], and has authorized the publication of three >>> solution proposals in IRON [RFC6179], hIPv4 [RFC6306] and >>> ILNP [ILNP]." >>> >>> Thanks - Fred >>> [email protected] >>> >>>> -----Original Message----- >>>> From: [email protected] [mailto:[email protected]] On >>>> Behalf Of Terry Manderson >>>> Sent: Wednesday, September 21, 2011 5:05 PM >>>> To: [email protected] >>>> Subject: [lisp] LISP (re-)Charter discussion >>>> >>>> Hi Folks, >>>> >>>> In Prague there was no strong consensus on modifying the LISP >>>> Charter from >>>> what it currently is, perhaps only updating the existing >>>> Goals/Milestones. >>>> >>>> So no clear decision could be made. What I would like to do >>>> is push out a >>>> 'idea generating' draft charter that is _almost_ identical to >>>> what we have >>>> today. >>>> >>>> You can find the existing charter here: >>>> https://datatracker.ietf.org/wg/lisp/charter/ >>>> >>>> The draft is below. >>>> >>>> So in light of such an approach, Joel and I discussed some >>>> work items that >>>> came from what was said at the mic in Prague and to us >> individually. >>>> >>>> They are: >>>> >>>> * Finish the deployment document >>>> * Get the two security documents done >>>> * Get an operational document at least started, which >> should include >>>> cache management and ETR synchronization techniques. >>>> * Either in the second security document, or in complementary >>>> documents we >>>> need to evaluate the security threat to cache maintenance, and >>>> evaluate the applicability and coverage we get from a reuse of SIDR >>>> technology. >>>> >>>> Is anything not represented here that you believe necessary? >>>> and conversely >>>> is there something here that is out of scope in your eyes? >>>> >>>> Are there work areas not covered by the draft below which you >>>> believe should >>>> be? >>>> >>>> Draft Charter >>>> ------------ >>>> >>>> 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 and >> the impending >>>> exhaustion of the IPv4 address space. 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 supports the separation of the IPv4 and IPv6 address space >>>> following a network-based map-and-encapsulate scheme (RFC 1955). In >>>> LISP, both identifiers and locators are IP addresses. In LISP, >>>> identifiers are composed of two parts: a "global" portion >>>> that uniquely >>>> identifies a particular site and a "local" portion that >> identifies an >>>> interface within a site. The "local" portion may be subdivided to >>>> identify a particular network within the site. For a given >> identifier, >>>> LISP maps the "global" portion of the identifier into a set >>>> of locators >>>> that can be used by de-capsulation devices to reach the identified >>>> interface; as a consequence a host would typically change >> identifiers >>>> when it moves from one site to another or whenever it >> moves from one >>>> subnet to another within an site. Typically, the same IP >> address will >>>> not be used as an identifier and locator in LISP. >>>> >>>> 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 >> the IRTF and >>>> IETF. At this time, these proposals are at an early stage. >>>> All proposals >>>> (including LISP) have potentially harmful side-effects to Internet >>>> traffic carried by the involved routers, have parts where >> deployment >>>> incentives may be lacking, and are NOT RECOMMENDED for >>>> deployment beyond >>>> experimental situations at this stage. Many of the proposals have >>>> components (such as the identifier to locator mapping >> system) where it >>>> is not yet known what kind of design alternative is the >> best one among >>>> many. >>>> >>>> However, despite these issues it would be valuable to >> write concrete >>>> protocol specifications and develop implementations that can >>>> be used to >>>> understand the characteristics of these designs. The LISP WG is >>>> chartered to work on the LISP base protocol and any items >>>> which directly >>>> impact LISP. 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 the ALT and/or other 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 >>>> (e.g., the >>>> Routing Research Group) that attempts to understand which type of a >>>> solution is optimal. The LISP WG is NOT chartered to >> develop the final >>>> or standard solution for solving the routing scalability >> problem. Its >>>> specifications 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. >>>> >>>> >>>> Cheers >>>> Terry >>>> >>>> _______________________________________________ >>>> lisp mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/lisp >>>> >>> _______________________________________________ >>> lisp mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/lisp >>> >> _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
