Subject: RE: [NSIS] "split layers"

From: [email-masked]
Date: Wed, 4 Dec 2002 18:32:11 +0200

Hi Michael,

> I think it would be a lot more productive to
> instead devive requirements given the RSVP
> experience and label them in a non-prejudicial way
> like, oh say, Transport Requirements which says
> what the protocol needs to achieve rather than a
> particular design methodology which lends itself
> to fulfilling those requirements.
> 
> Melinda brought up a couple issues earlier
> relating to transport (flat namespace, required
> QoS-related objects). To my mind, abstracting
> requirements from those kinds of issues and
> placing them in a general transport requirements
> section would be a lot more sensible at this point
> than trying to say how RSVP should be teased apart
> if we started over again; it seem quite possible
> to me to acheive these sorts of requirements in an
> RSVPbis, after all.
> 
> The long and short of this is that requirements
> should not be prejudicing the outcome in any way.
> Requirements should not read like a judicial
> indictment. If overhauling RSVP given the
> requirements becomes untenable, it will become
> readily apparent in the design phase. Until then,
> we need to keep all options explicitly open.

I think we'd all appreciate if folks had requirements
to add, they'd suggest them.  Noone has been suggesting
new requirements for many months - which seemed to point
to the document being quite stable.

thanks,
John
_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: Michael Thomas <[email-masked]>
Date: Wed, 4 Dec 2002 09:05:41 -0800 (PST)

> to the document being quite stable.

John,

An alternatate explanation is that the mailing
list has been a very confusing mishmash of culture
clash, problem scoping, requirements (some), along
with a huge volume of solution space which makes
it very difficult to track what the actual problem
scope/requirements are in all of the noise. Or at
least that's *my* problem.

I think it would be really helpful to quash any
talk of solutions on the main list for now. For my
part, I think the requirements draft needs a lot
of work. More later.

	Mike