Subject: [NSIS] "split layers"

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

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

---

From: "Geib, Ruediger" <[email-masked]>
Date: Thu, 5 Dec 2002 10:47:25 +0100

Marcus,

Given that there's one requirements doc only,
Mike is certainly right in demanding that the 
"layered requirements" get clearly visible 
there. The "two layers" are no requirement in 
themselves. They are a definition (or a basic 
design assumption). Any requirements must be 
classified as "Transport", "Service" or 
"General" (if applicable). In cases like 
security, both layers may have different 
requirements on the same subject (like e.g. 
message integrity and authentication between 
peers).

Regards, Rüdiger

> Marcus Brunner writes:
>  > 
>  > >  > 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.
>  > 
>  > 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.
> 
> 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

---

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Thu, 5 Dec 2002 11:03:54 +0100

Hi Rudiger

I think that the layered functionality could be emphasized 
in the framework draft.

Best Regards,
Georgios

-----Original Message-----
From: Geib, Ruediger [mailto:[email-masked]]
Sent: donderdag 5 december 2002 10:47
To: [email-masked]
Cc: [email-masked]
Subject: RE: [NSIS] "split layers"

Marcus,

Regards, Rüdiger

---

From: [email-masked]
Date: Thu, 5 Dec 2002 12:03:25 +0200

Rüdiger,

> message integrity and authentication between 

What I'd like to encourage folks to do is make recommendations
on how to improve the current set of requirements, if they
feel thre is some need. So, if you think that some current
requirements could be better worded to cover possible functionality
split, then please suggest.

Please note that currently, we do not have a functionality
split determined, so I feel trying to make requirements specifically
discussing a fictitious split to be wrong.  That does not mean,
however, that I don't think that the current set could be improved,
so please make some suggestions, if you have any.

thanks,
John

---

From: "Geib, Ruediger" <[email-masked]>
Date: Thu, 5 Dec 2002 11:41:10 +0100

John,

> so please make some suggestions, if you have any.

You want to say that first we will determine the the functionality 
split and then we will formulate the requirements for each 
functionality? 

Regards, Rüdiger

---

From: "Geib, Ruediger" <[email-masked]>
Date: Thu, 5 Dec 2002 15:16:20 +0100

Thanks Melinda. I share your point of view. 

Regards, Rüdiger

> > John:
> > No, I am actually trying to say the reverse. The 
> > requirements should be general requirements. We
> > should handle the layer split in a seperate
> > document, which then specifies the more layer-specific 
> > requirements.

> Melinda: 
> I think I disagree with that - it's certainly not going to
> speed up the process, and the layer split almost certainly
> imposes its own requirements, even if its as simple as "The
> protocol must support the transmission of blobs of data that
> are opaque to it."

---

From: [email-masked]
Date: Thu, 5 Dec 2002 16:26:17 +0200

Hi Melinda,

> protocol must support the transmission of blobs of data that

I agree.  What I am saying, though, is that the requirements
document is not specifying the protocol split.  Do you want
the requirements doc to do this?  

I see this as 2 seperate documents, otherwise one document will
be very large.

John

---

From: "Hancock, Robert" <[email-masked]>
Date: Thu, 5 Dec 2002 14:51:10 -0000

Dear all,

FWIW my past experience in similar activities to this is that there are unavoidably bound to be many levels of things that could be called "requirements", starting from 
a) "we would like the world to be a better place"
all the way to 
z) "a foo MUST set the bar flag in baz messages"
Different communities are producers and consumers of the requirements at each stage of the lifecycle, and commonly don't have much in common from one stage to the next. Trying to define a single point at which all things called "requirements" are gathered together and agreed in one document is therefore IMHO bound to fail (although I have seen several large scale projects collapse while trying).

In particular, I think we have a requirements document which is currently pitched around stage (c) - i.e. "what the rest of the Internet community (certainly outside NSIS w.g., and probably outside the transport area) would like NSIS to achieve". They don't care about things like layer splitting, except in the abstract sense of wanting a 'quality' result. That amount of information clearly isn't enough to design a protocol suite on, but I don't think we were tasked to produce that level of detail as our *first* output anyway.

My personal feeling is that - given a limited target as proposed above - the requirements are basically done. To follow up on one of Mike's earlier comments, I wouldn't expect to be able to do protocol design work without being familiar with the requirements and the framework and analysis documents and also most of the RSVP standards, as well as the implications of mobility support protocols (MIP and seamoby), key management and other security protocols, and knowing how routing works. (This is not an ironic comment: protocol design is hard.)

It might be that it would be worth gathering all the constraints from these sources into protocol specific requirements documents which we could also check for internal consistency (I don't have a feeling for that), but let's not try to do that as a first step. (Please.)

Cheers,

Robert H.

PS i promise not to send any more emails on this subject (at least until the subject line changes).

> From: [email-masked] [mailto:[email-masked]]
> Sent: 05 December 2002 14:26
> To: [email-masked]
> Cc: [email-masked]; [email-masked]

---

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Thu, 5 Dec 2002 15:56:19 +0100

Hi John

I agree with your proposal! First we will have to 
define the required functionality split and only then we could 
produce a document that is specifying the protocol split. This document
does not have to be the requirements document.

Best regards,
Georgios

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: donderdag 5 december 2002 15:26
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [NSIS] "split layers" 

Hi Melinda,

John

---

From: [email-masked]
Date: Fri, 6 Dec 2002 08:22:33 +0200

Hi Robert,

> My personal feeling is that - given a limited target as 
> proposed above - the requirements are basically done. To 
> follow up on one of Mike's earlier comments, I wouldn't 
> expect to be able to do protocol design work without being 
> familiar with the requirements and the framework and analysis 
> documents and also most of the RSVP standards, as well as the 
> implications of mobility support protocols (MIP and seamoby), 
> key management and other security protocols, and knowing how 
> routing works. (This is not an ironic comment: protocol 
> design is hard.)
> 
> It might be that it would be worth gathering all the 
> constraints from these sources into protocol specific 
> requirements documents which we could also check for internal 
> consistency (I don't have a feeling for that), but let's not 
> try to do that as a first step. (Please.)

Thanks for the proposal, it more crisply states what I was
indending to say.  My worry about trying has been that we
get into an endless loop in defining the requirements 
(the requirements are dependent on how we break down the layer
functionality which are dependent on what we require which are
dependent on ...)

Does anyone have any suggests, comments or feedback on this
approach?

John