Sean,
> | Before the IETF will attack the engineering side of the problem,
> | they will need to have a single set of requirements.
> I respectfully disagree. Before the IETF will attack the
> engineering side of the problem, they should and perhaps
> must be presented with an architecture against which to
> standardize.
Right. However, even if presented with an architecture,
the IETF will face a number of engineering trade-offs,
and this is where a consistent requirements set becomes
useful to make sure that those requirements are still
satisfied.
> I base this on my own personal experiences in watching
> ideas arrive out of other RGs into the IETF. Some are
> quickly standardized, and some live on forever. Well,
> lots live on forever, and suffer essentially zero deployment
> at the same time.
> This is not a good state of affairs.
> The "n-napkin protocol" approach works well in the
> area of routing, but has suffered from having an opaque history
> wrt the design, and a failure to meet some real requirements.
> I think this RG can act as a filter for several n-napkin
> protocols, and let the IETF do to them what it did to BGP
> and diff-serv. :-)
It's interesting how many possible architectures can multiple
requirement sets spring... Do you expect only one architecture
to finally come out of the RG or multiple?
> | To me, the question is: is there a good reason NOT to have
> | a single document, i.e., are the requirements sets you're seeing
> | so much different from each other
> You've read both reqs drafts, right? Do you have a personal opinion?
> I'm collecting them...
Still catching up on the latest updates. I'll send a more detailed
note when I'm done. So far I vote for one set.
Alex
This archive was generated by hypermail 2b29 : Mon Aug 04 2003 - 04:10:04 EDT