Dave: > > So the question - that is not administrative - boils down > > imho to: can we exclusively concentrate on the LISP protocol(s) > > specifics leaving the issue of our confidence on the Loc/ID > > split and associated challenges open. That question deserves > > imho a specific discussion that should happen in the context > > of a BoF. > > It would seem that one could apply the same argument to > SHIM6, HIP, SCTP, and several other protocols that have > been or are being standardized. > > So my question to you is: > > (i). Given your argument above, do you believe that > say, the SHIM6 WG should not have been chartered > (or perhaps that the SIGTRAN WG, which produced > RFCs 4960 and 3286) should not have been > chartered? Clearly they did not have such an > analysis, or we wouldn't be talking about doing > it now (and again, that is not to say there isn't > a ton of literature on loc/id split). > > (ii). If on the other hand you believe that, say SHIM6 > should have been chartered, the question is why > (again, given your argument above)?
Applying that approach (SCTP had foundations coming from outside IETF) may work with relatively simpler problems/protocols. The level of complexity of the task to reach a certain objective drives the approach. In the present case, some of the main challenges are known beforehand and they are certainly not limited yet to protocol implementation specific aspects. One may certainly initiate a cycle of experiments using experimental protocol specs together with a specific set of eval.objective and criteria. This said, the approach in spiral (LISPv1->experiment->analysis->LISPv2-> ...) works iff proto-development takes these elements into account (otherwise any experimentation is hardly useful as it will not deliver the expected outcomes in order to make real progress) and outcomes/analysis are documented accordingly before moving to the next iteration. Here, the problem in understanding stems because: LISP WG focus on experimental specification to resolve only protocol engineering problems leaving actual challenges outside of its own protocol work but at the same time acknowledges that such experimentation are complementary to achieve real progress on its own protocols. However, at this point in time, I do not see how the protocol engineering problem can be decoupled from the purpose of the experimental effort in spiral. Hope this clarifies my concern, -dimitri. > -----Original Message----- > From: David Meyer [mailto:[email protected]] > Sent: Wednesday, January 21, 2009 5:18 PM > To: PAPADIMITRIOU Dimitri > Cc: [email protected]; [email protected]; [email protected] > Subject: Re: [Int-area] Please respond: Questions from the > IESG as towhether aWG forming BOF is necessary for LISP > > Dimitri, > > > The task consisting in discovering by experimentation > architectural fit > > (wrt initial objectives) and complement understanding wrt known > > challenges (mapping, caching, loc.reachability, impact on traffic > > spatio-temporal properties) is very different in nature > than ensuring > > interoperability among protocols, minimize operational impact, and > > facilitate integration/deployability -> so requiring > different type of > > efforts with different timelines. As a matter of fact, both types of > > activities are still required imho. > > > > So the question - that is not administrative - boils down > imho to: can > > we exclusively concentrate on the LISP protocol(s) > specifics leaving the > > issue of our confidence on the Loc/ID split and associated > challenges > > open. That question deserves imho a specific discussion that should > > happen in the context of a BoF. > > The purpose of this WG would be to take the *LISP* > documents to EXPERIMENTAL. That is what I had in mind > when I wrote the charter, and I believe that it is pretty > clear on this point. That is not to say it the charter > can't be further tightened (I'm sure it can). > > A you know, WGs need to be tightly focused, especially in > the case of protocol groups. I'll grant you that my > experience with WGs in the OPs area are somewhat more > open-ended (at least mine have been), but it seems > unlikely that an IETF WG could successfully produce both > tight protocol specs and broad architectural surveys and > analyzes. In fact, I can't think of a case in which this > has been done in the IETF (perhaps there is one, but it > doesn't readily come to mind). Add to that that LISP is > clearly in an engineering and deployment phase, coupled > with the fact that producing engineering specs what the > IETF is good at (well, that is the IETF does), and one > sees that finishing up the LISP specs in the IETF seems > only natural. > > That said, it is a fine thing for the RRG to continue to > do what its doing, and further, the document you've been > describing on the RRG list should continue to progress > (IMO of course). In fact, these activities are completely > complementary. So keep up the good work. > > Just one point on your argument: > > > So the question - that is not administrative - boils down > imho to: can > > we exclusively concentrate on the LISP protocol(s) > specifics leaving the > > issue of our confidence on the Loc/ID split and associated > challenges > > open. That question deserves imho a specific discussion that should > > happen in the context of a BoF. > > It would seem that one could apply the same argument to > SHIM6, HIP, SCTP, and several other protocols that have > been or are being standardized. > > So my question to you is: > > (i). Given your argument above, do you believe that > say, the SHIM6 WG should not have been chartered > (or perhaps that the SIGTRAN WG, which produced > RFCs 4960 and 3286) should not have been > chartered? Clearly they did not have such an > analysis, or we wouldn't be talking about doing > it now (and again, that is not to say there isn't > a ton of literature on loc/id split). > > (ii). If on the other hand you believe that, say SHIM6 > should have been chartered, the question is why > (again, given your argument above)? > > > Note that I'm not taking a stand on this either > way. Rather, I'm just following the logic of your > argument. > > Dave > > > > _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
