Hi guys, |> > My understanding/summary of what I heard this week |> > (Tuesday, IIRC) is that the RRG will *not* recommend any |> > of the proposed solutions (or any other?) but rather will |> > recommend "concepts". What exactly constitutes a |> > "concept" wasn't clear (at least to me), even though it |> > was briefly discussed. |> |> OK - I haven't yet listened to the earlier part of the Tuesday |> meeting, or the Friday meeting. |> |> I guess the RRG would recommend development of a set of technical |> concepts which would (ideally) fit together to create the complete |> solution, or perhaps recommend some parts of the solution for |> engineering development while leaving other parts up for further |> research and discussion. | | I think I understand what you're saying, Check me on | this: So the RRG should recommend a sort of | meta-recommendation, i.e., that the IETF should develop | "a set of technical concepts" that others (the IESG?) | would use to what, evaluate proposed working group | charters for WGs that do the protocol development for | some proposal that fits the "set of technical concepts"? | Is that close?
Close, but one level off. Again, we are chartered to deliver an architecture. Not do protocol development work. Our job is to look at the full broad solution space and attempt to narrow it down, starting from the top and understand the full spectrum that is available. Then to look at the different segments within the solution space and continue to whittle those down until we can partition the solution into particular functions and describe the properties of those functions. Thus, it's up to the RRG to deliver "a set of technical concepts" that, integrated, form the architecture. In essence, we should be staying at a level of abstraction well above the protocol work, where we are effectively providing a functional specification of the various protocols, but not fill in the bits and bytes. We should stop entirely when we have an adequate definiton of the functionality. Now, Dino will immediately respond that "the devil is in the details". ;-) This is certainly true. However, this does NOT imply that we necessarily need to work out all of the details to provide the functional specification. In particular, where there is some question about the feasibility or tractability of a particular approach, we should certainly be willing to go off and perform some experiments (possibly even coding) to determine tractability. That does NOT mean that we need to fully flesh out a prototype of all parts of our recommendation. | Do you envision these principles as being at the level | like "It is recommended that the IETF develop protocols | based on Locator/ID split", or more fine-grained like "It is | recommend that the IETF develop protocols based on | address rewriting"? Or something even more fine-grained? It should definitely get more fine-grained. Again, it should be specific enough, with enough rationale so that a set of WG's in the IETF can simply sit down with it as their problem statement and quickly and directly sit down to the task of protocol design. They shouldn't have to ask how the big pieces fit together or what it is that their particular function should do. Again, please refer to the list of properties that we put together this week for the mapping function. We should be able to characterize all of these down to some reasonable extent. Exactly how much detail is necessary? To borrow some legalese, someone "skilled in the art" should have no problem sitting down and cranking out something that just works, assuming that they do a reasonable job meeting the specific recommendations and functional requirements. At the same time, the implementor shouldn't feel overly constrained. Again, folks who are practiced in writing software functional specifications should have a fair understanding of the feel of this level of detail. | Also, do you envision that a recommendation could be | something unrelated to what the RRG has been focusing on, | say, like "It is recommended that the IETF develop | protocols based on the NIMROD architecture"? It's certainly possible that we might turn up a new sector in the solution space in our discussions. Handley's proposal, for example, was a segment that was not previously discussed. I would not discount that there are other segments that are unexplored -- we have not made a systematic search of the solution space. However, making a recommendation of NIMROD would be precisely what I'm suggesting that we don't do: refer to a specific proposal. |> > The LISP BOF proposal has nothing to do with any other |> > proposal. Moreover, the BOF proposal is outside of the scope of the RRG and is, frankly, off topic for the mailing list. I do realize that there is some commonality of interest in the audience, but holding the BOF is *not* forwarding our work within the RRG, and discussing holding the BOF is simply a level of indirection on a tangential subject. Tony -- to unsubscribe send a message to [EMAIL PROTECTED] with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg
