Re: Transport level multihoming

[smd@ebone.net (Sean Doran)]

I think that if a draft comes forward which is explicit in how
it meets the present requirements work, or is explicit in WHY it
obviates the present requirements work (a la Randy's question), 
that not even I am too stubborn to insist that we ignore it.

Put another way - the obvious next step after we have the reqs out
the door is to do a detailed comparison of the various individual
proposals that are on the table now (and the ones that aren't yet),
and try to come up with a rough consensus on which one(s) we propose.

It's rather hard to validate one's belief in a given architecture
without understanding what it is you're trying to accomplish, and
frankly from my perspective as a netwok operator, that lack of
understanding is commonplace.

Ignorance is neither shameful nor incurable - what we're
trying to do with the first two drafts is to demonstrate
that the elephant is not a kite, a snake, or a tree.

I realize that this is slower than some people would like,
but frankly, if anything, I regret to say that *every* proposal
may obviously "need more work" when compared to the reqs draft.

Please do not take that as a cheap shot at the authors
and potential authors.  This is not a trivial problem
to solve and it is beyond the ability of any single
writer to draw up a complete solution.   That's hopefully
why we're trying to engineer in committee anyway, and while
we're here we can make it easier on authors by pushing them
into treating the reqs document as a series of FAQs that ultimately
need to be answered.

Obvious valid answers are "we do X",  "we don't do X but...".
On the other hand "we think X is stupid" is something that
should really be dealt with in advance (i.e., NOW) so that
we don't have to keep rewriting the reqs when we discover
they're wrong in some way. :-)

	Sean.