Subject: RE: [NSIS] "split layers"

From: "Hancock, Robert" <[email-masked]>
Date: Wed, 4 Dec 2002 16:51:15 -0000

Mike,

someone will doubtless correct me if i'm wrong, but I
don't think it is proposed to split the requirements 
document by layer. (This has been proposed in the past, 
but isn't any more.)

one the other hand, I have been operating under the 
belief that the w.g. had converged on having a 2 layer 
solution for the protocol, and therefore at some stage
we should actually define the split. (i personally 
would like to define that split as one end product of
the framework activity.) if we are not agreed on this,
there is some more discussion to go through...

am i labouring under a misapprehension?

robert h.

> -----Original Message-----
> From: Michael Thomas [mailto:[email-masked]]
> Sent: 04 December 2002 16:06
> To: [email-masked]
> Subject: [NSIS] "split layers"
> 
> 
> 
> Hi again,
> 
> It occurs to me that requirements centered around
> the term "split layer" unnecessarily prejudice the
> requirements: the subtext is that this is
> something that RSVP got really wrong and needs to
> be redesigned -- most likely from the ground up
> -- which is not a particular accurate assessment
> of the state of affairs.
> 
> 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.
> 
> 	   Mike
> _______________________________________________
> nsis mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nsis
> 
_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

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

> document by layer. (This has been proposed in the past, 

My suggestion was more along the lines of grouping
requirements based on some overall characteristic.
There might be transport related requirements,
mobility related requirements, application
separability related requirements, initiation
related requirements, and so forth.

 > am i labouring under a misapprehension?

Reading through the requirements document it isn't
immediately clear to me what "2 layer" actually
means in practice. I could easily claim that RSVP
is two layer right now, and the current
requirements doesn't guide me as to why somebody
else might have a different opinion. Right now,
there's way too much motherhood in the draft and
not enough concrete design criterion.

This is particularly important as we already have
a working signaling protocol to compare and
contrast. If there are additional things that RSVP
should have done, for example, or does poorly I
think we should be very explicit about those
things so long as we keep the tone requirements
based rather than a polemic.

	     Mike

---

From: Marcus Brunner <[email-masked]>
Date: Wed, 04 Dec 2002 18:29:00 +0100

> else might have a different opinion.

The requierments stays on an abstraction level above and is talking about 
e.g. modularity, which can be achieved by 2 layers or 5 layers or other 
means. The document does not requiere a 2 layer appraoch. And everything in 
the requirement draft must not be new compared to RSVP. What the problem of 
RSVP is should be covered in the analysis draft.

From a requirement perspective there is much more scoping requirements then 
protocol design requirements.

Marcus
--------------------------------------
Dr. Marcus Brunner
Network Laboratories
NEC Europe Ltd.

E-Mail: [email-masked]
WWW:    http://www.ccrle.nec.de/
Phone: +49 (0) 6221 905 11 29
personal home page: http://www.brubers.org/marcus

---

From: Michael Thomas <[email-masked]>
Date: Wed, 4 Dec 2002 10:58:42 -0800 (PST)

> RSVP is should be covered in the analysis draft.

Again, modularity doesn't mean very much in the
abstract; we need more concrete requirements. For
example: does the protocol need to be able to
transport more than one "application" at a time?
Does it need to provide name space hierarchy? Are
the auth/authz requirements for one application
transported required to be identical for other
applications?

I'm afraid that these kinds of issues need to be
clear in the requirements because they greatly
either expand or contract the design space.

	      Mike