Subject: RE: [NSIS] NSIS Analysis

From: [email-masked]
Date: Tue, 3 Dec 2002 15:56:35 +0200

Hi all,

> > *) are we going to say 'this is what rsvp is'? (impractical, i think
> > there are about 600 pages of related standards track RFCs 
> to consider.
> > however, the introduction seems to imply this.)
> 
> No, RSVP is documented elsewhere, that is why we have a very long list of 
> references (same goes with all other protocols reviewed) - still, from an 
> editorial pov we need to write a short overview of the basic 
> functionality.

Exactly.

> > *) are we just going to say 'this is what we don't like about rsvp'?
> > (unfair, provocative?)
> 
> I would say "no" here and "yes" to the following bullet.

This would not be the place to say this.
 
> > *) are we going to say 'we don't like this but fundamentally it comes
> > with the territory'? (i.e. analyse the signalling problem in general as
> > well as specific protocols)
> 
> Yes, it is part of the review, to say what is not working properly, eg. 
> related to mobility and RSVP - it comes with the territory.

But if there are key conclusions to draw, then we should at least include
them.

> > *) are we going to say 'this is what we do like and there's no need to
> > change' (i guess it's easy to say yes to that one)
> 
> Yes. (although, see below...)

Agreed.

> > *) are we going to say 'this can be changed and here is the reasoning
> > about the way to change it' (or is that straying into next stages?)
> 
> No, no suggestions for changes in any of the protocols (at 
> least not in this doc).

I think that we should outline the things that SHOULD be changed.  For
example, issues of Multicast could be handled here.

Mobility is another issue - I think we still need to figure out if
Michael Thomas' draft should be a standalone draft or included with
this work.

> I wouldn't like to take sides in the document about whether
> sender/receiver orientation is best, or should the signalling go
> in/out-of-path, or (this is provocative, I know) is the mechanism scalable
> or not. Each protocol works in its own way and therefore what I'd like to
> have is a review of the functionality, the good and bad points. 

Perhaps we could have some text on this though.
 
> Naturally, this does require us to take sides on what is "good"  and "bad"
> operation, but still I'd like to be as neutral as possible - and really
> not compare against the requirements doc.

Exactly.  However, we could say that if you do x, then y comes along with
x.

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

---

From: Michael Thomas <[email-masked]>
Date: Tue, 3 Dec 2002 09:37:57 -0800 (PST)

> Michael Thomas' draft should be a standalone draft or included with

That's my question too.. when I wrote my draft
originally, it was mainly to show that as
currently instantiated RSVP had some issues with
mobility and interdomain policy. It was aimed
mostly as a "heads up" kind of draft to illustrate
what was still left unanswered with the current
crop of RSVP RFC's. I really didn't have any
intention one way or the other about publishing it
permanently, etc as it was mainly intended to give
some fodder to instigate work to find solutions.

It's not entirely clear to me how that fits in
with this wg too. Having some background is still
useful, I think, but it might make more sense to
do it in terms of a more terse problem statement
which feeds into requirements which then allows us
to have a guide for ultimate protocol selection.

As a corollary, I think until we figure this all
out, it's probably premature to last call the
requirements.

	Mike

---

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

> to have a guide for ultimate protocol selection.

I would think most of your analysis work fits very well in the analysuis 
draft.

> out, it's probably premature to last call the

If you think this way, we will finish the requierment draft after the 
protocol specification :-)

Marcus

--------------------------------------
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