Dimitri, > > > 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.
Agreed that its complex, though you dismiss SCTP without
explanation. In addition, I don't see the relevance of
SCTP coming from outside the IETF. In any event, you
might make the same claim for LISP (that its coming from
outside the IETF).
> 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,
Not really. First, you didn't answer my question. Second,
what you are arguing can be applied to say, OSPF (v1-n),
EGP->BGP, ..... Essentially any protocol that has ever
been rev'ed.
Just to be clear: I understand the concern to further
understand the properties of loc/id split. If fact, to
the best of my knowledge no one in the current RRG cycle
has written about this except for me and Darrel
(draft-meyer-loc-id-implications-00.txt). That, however,
shouldn't stop us from developing protocols. If it did,
we'd never develop any protocol (since obviously the set
of such questions is clearly *not* recursively
enumerable).
Finally, what happens if the properties you want to study
are in some sense "emergent" (e.g., the Internet's
heavy-tailed robustness-complexity curve). The point here
is that you won't see those properties until you have a
system to study, so in our case (the Internet) the
approach you are advocating would not have revealed the
deepest and most fundamental (and hence most interesting)
properties of "the architecture" (check out
http://www.cds.caltech.edu/~doyle/SFI_robustness/rigor_robust.htm
or any of Doyle's work on this topic).
Dave
signature.asc
Description: Digital signature
_______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
