[NSIS] RE: I-D ACTION:draft-hancock-nsis-sender-receiver-00.txt

["Hancock, Robert" <[e-mail]>]

hi all,

I'd just like to re-affirm the existence of the draft below. 

It's basically an attempt to review the overall issue of sender/receiver orientation (what is it? which do we need? which do we really need?) and to outline perceived pros & cons of some very broad categories of approach to the problem. It therefore has a sort of requirementsy/frameworky feel.

A particular issue is how these concepts apply to which layer (called nbp/asap in the draft, what we might soon call ntlp/nslp or even itlp/islp), which we have not really considered in this w.g. up to now.

Comments welcome, of course.

Cheers,

Robert H.

ps. For those interested in path-decoupled issues, there is a quick discussion at the end. Interestingly (for me), the conclusion - that the coupled/decoupled difference should be handled in the ntlp, with signalling applications unchanged - seems to be the complete opposite of what Bob & John have suggested recently. So I guess there's scope for exploration there, at some point.

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: 30 October 2002 11:19
> Cc: [e-mail]
> Subject: I-D ACTION:draft-hancock-nsis-sender-receiver-00.txt
> 
> 
> A New Internet-Draft is available from the on-line 
> Internet-Drafts directories.
> 
> 
> 	Title		: Sender and Receiver Orientation Issues in NSIS
> 	Author(s)	: R. Hancock et al.
> 	Filename	: draft-hancock-nsis-sender-receiver-00.txt
> 	Pages		: 16
> 	Date		: 2002-10-29
> 	
> The NSIS working group is considering protocols for signaling for 
> resources for a traffic flow along its path in the network. The 
> requirements for such signaling are being developed in [2] and a 
> framework in [3]. 
> It is clear from existing work that there are many interrelated 
> issues with NSIS signaling, concerning the respective roles of the 
> two ends of the communication path. These issues include route 
> finding, authorisation, state management requirements, localization 
> of negotiation, and so on. The wide variety of problems involved 
> hinders progress in deciding what approach NSIS should adopt. This 
> Internet Draft attempts to provide a summary of these issues and 
> suggests a way of structuring further analysis. It is not expected 
> that this document should have a long term existence.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-hancock-nsis-sender-
receiver-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-hancock-nsis-sender-receiver-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-hancock-nsis-sender-receiver-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
nsis mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/nsis