Subject: [NSIS] NSIS Analysis

From: [email-masked]
Date: Tue, 3 Dec 2002 11:07:24 +0200

Hi all,

Jukka Manner has editted an analysis doc:

http://www.ietf.org/internet-drafts/draft-ietf-nsis-signalling-analysis-00.txt

We need to capture some additional material for this document and then see how much more work is needed.

In Atlanta, there were a number of voices suggesting that some basic functionality is not broken, so does not need to be changed.  If there are folks looking new and novel ways to perform signaling that is not in keeping with the RSVP model, then they must provide some analysis why what RSVP is doing, is broken.  Otherwise, we will start with some basic assumptions for the NSIS protocol from RSVP.  I don't think that basing some mechanisms on RSVP is a bad thing, that is why there needs to be documented reasons if we choose to do something else.

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

---

From: Jukka MJ Manner <[email-masked]>
Date: Tue, 3 Dec 2002 12:09:16 +0200 (EET)

Hi all,

For the next "01" version of the document, I propose the following 
editorial/conceptual changes:

- Divide the document into
	1) pure signalling protocols, like RSVP, INSIGNIA and YESSIR
	2) larger architectural frameworks with some signalling 
	   mechanisms, eg. currently ITSUMO

- Keep the main focus on the signalling protocols: Part 1 would be around
80% of the text, part 2 the rest 20%

- Any _architecture_ review must be kept short, just to point out original 
new ideas that might benefit our work.

Thus, I am open for input from people regarding analysis of different 
sig. prots and architectures. Send your suggestions for text to the list 
and I will take the text once the WG has had time to comment on it - 
please don't send me text outside the list.

Any additional text or changes to current text are more than welcome. 
Also, me and Xiaoming don't intend to do a thorough review of all 
protocols ourselves, so please contribute text to the existing analysis.

Regards,

Jukka

On Tue, 3 Dec 2002 [email-masked] wrote:

> In Atlanta, there were a number of voices suggesting that some basic
> functionality is not broken, so does not need to be changed.  If there
> are folks looking new and novel ways to perform signaling that is not in
> keeping with the RSVP model, then they must provide some analysis why
> what RSVP is doing, is broken.  Otherwise, we will start with some basic
> assumptions for the NSIS protocol from RSVP.  I don't think that basing
> some mechanisms on RSVP is a bad thing, that is why there needs to be
> documented reasons if we choose to do something else.
> 
> John