Subject: RE: [NSIS] NSIS Analysis

From: "Hancock, Robert" <[email-masked]>
Date: Tue, 3 Dec 2002 10:54:33 -0000

jukka, all,

i still find myself slightly confused about what the end result of this analysis is going to be, and how it might/might not lead in to other activities. i restrict myself to rsvp for some example questions:

*) 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.)
*) are we just going to say 'this is what we don't like about rsvp'? (unfair, provocative?)
*) 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)
*) 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)
*) 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?)

clarification welcome. as an example, i'd like to capture some thinking about the signalling/data path divergence issues and also sender/receiver issues, which [to be useful] would cover all the above questions. but i'm not clear how much would come under the heading 'analysis'.

cheers,

robert h.

> -----Original Message-----
> From: Jukka MJ Manner [mailto:[email-masked]]
> Sent: 03 December 2002 10:09
> To: [email-masked]
> Subject: Re: [NSIS] NSIS Analysis
> 
> 
> 
> 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:
> 
> > 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
> 

_______________________________________________
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: Jukka MJ Manner <[email-masked]>
Date: Tue, 3 Dec 2002 13:28:15 +0200 (EET)

Hi, below my view of the work.

On Tue, 3 Dec 2002, Hancock, Robert wrote:

> jukka, all,
> 
> i still find myself slightly confused about what the end result of this
> analysis is going to be, and how it might/might not lead in to other
> activities. i restrict myself to rsvp for some example questions:
> 
> *) 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.

> *) are we just going to say 'this is what we don't like about rsvp'?

I would say "no" here and "yes" to the following bullet.

> *) 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.

> *) 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...)

> *) 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).

> 
> clarification welcome. as an example, i'd like to capture some thinking
> about the signalling/data path divergence issues and also
> sender/receiver issues, which [to be useful] would cover all the above
> questions. but i'm not clear how much would come under the heading
> 'analysis'.

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. 

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.

Regards, Jim