Subject: minor clarification on: RE: [NSIS] WG Last Called on draft-ietf-n sis-fw-04.txt

From: "Hancock, Robert" <[email-masked]>
Date: Mon, 13 Oct 2003 09:29:30 +0100

dear all,

some people have asked whether they can still make last call
comments on the mailing list on this draft. the answer is:
yes (in which case I will enter them myself). the tracking
tool is intended to be a convenience for the editor and anyone
else trying to disentangle N parallel conversations, it's not
intended to restrict the discussion in any way.

sorry for any confusion.

robert h.

> -----Original Message-----
> From: Hancock, Robert 
> Sent: Tuesday, October 07, 2003 10:28
> To: [email-masked]'; [email-masked]
> Cc: Lang, Christopher
> Subject: RE: [NSIS] WG Last Called on draft-ietf-nsis-fw-04.txt
> 
> 
> hi john, all,
> 
> we would like to use an issue tracking tool for this process, and
> you can find it at 
> http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-issues/index
> 
> use of the tool should be pretty self explanatory:
> - make sure you browse and add issues for the right document (v4, 
>   not v3!)
> - you can browse issues anonymously, but to take part you have to
>   create yourself a username (the 'Register' link at the left)
> - you will find that once an issue has been created, some changes
>   in status can only be made by the editor (that's me, btw)
> 
> i will poll the tool fairly frequently to see what is going on.
> ideally i'd like to keep the discussion of particular issues
> within the tool (since that's easier for me to decode than N
> interleaved email threads with misleading subject lines).
> 
> the tool is a locally customised version of Roundup, which has
> been/is being used in several other IETF groups. if you have 
> comments or queries about the way the tool is being used, or other
> problems, you can send them to me and chris lang (who set it up), 
> (off the list, I guess). there is more information on roundup at
> http://roundup.sourceforge.net.
> 
> cheers,
> 
> robert h.
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> > Sent: Tuesday, October 07, 2003 04:59
> > To: [email-masked]
> > Subject: [NSIS] WG Last Called on draft-ietf-nsis-fw-04.txt
> > 
> > 
> > Hi all,
> > 
> > I discussed with the editor of the draft, and it was felt that work
> > has been more-or-less complete on this document.  I would like to
> > start a working last call on this draft, starting Wednesday October
> > 8th, running through October 22nd.  I believe Robert has set-up a
> > tracking tool for issues raised; I will let him handle the details
> > for submitting issues, etc.
> > 
> > Thanks,
> > John	
> > 
> > -----Original Message-----
> > From: ext [email-masked] [mailto:[email-masked]]
> > Sent: 29 September, 2003 22:38
> > Cc: [email-masked]
> > Subject: [NSIS] I-D ACTION:draft-ietf-nsis-fw-04.txt
> > 
> > 
> > A New Internet-Draft is available from the on-line 
> > Internet-Drafts directories.
> > This draft is a work item of the Next Steps in Signaling 
> > Working Group of the IETF.
> > 
> > 	Title		: Next Steps in Signaling: Framework
> > 	Author(s)	: R. Hancock et al.
> > 	Filename	: draft-ietf-nsis-fw-04.txt
> > 	Pages		: 47
> > 	Date		: 2003-9-29
> > 	
> > The Next Steps in Signaling working group is considering protocols 
> > for signaling information about a data flow along its path in the 
> > network. Based on existing work on signaling requirements, this 
> > document proposes an architectural framework for such signaling 
> > protocols. 
> > This document provides a model for the network entities that take 
> > part in such signaling, and the relationship between signaling and 
> > the rest of network operation. We decompose the overall signaling 
> > protocol suite into a generic (lower) layer, with a separate upper 
> > layers for each specific signaling application. An initial proposal 
> > for the split between these layers is given, describing the overall 
> > functionality of the lower layer, and discussing the ways 
> that upper 
> > layer behavior can be adapted to specific signaling application 
> > requirements. 
> > This framework also considers the general interactions between 
> > signaling and other network layer functions, specifically 
> routing and 
> > mobility. The different routing and mobility events that impact 
> > signaling operation are described, along with how their handling 
> > should be divided between the generic and application-specific 
> > layers. Finally, an example signaling application (for Quality of 
> > Service) is described in more detail.
> > 
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-ietf-nsis-fw-04.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-ietf-nsis-fw-04.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:
> > 	[email-masked].
> > In the body type:
> > 	"FILE /internet-drafts/draft-ietf-nsis-fw-04.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
> > [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: Roland Bless <[email-masked]>
Date: Thu, 16 Oct 2003 14:23:27 +0200

Hi Robert,

> intended to restrict the discussion in any way.

Mainly an editorial related comment.

The tracking tool lists as open issue:
] Deferred from v3:
]
] References should be split normative and informative
] (according to some criteria, presumably).
]
] We need to decide which in-progress WG documents to refer to
] as background (e.g. midcom and qos NSLP drafts?)

I'd like at least to give a hint to the RFC editor's criteria below.
According to my perception of the distinction between normative and
informative references (from the definition below), there are nearly no 
normative references in the framework (except for the requirements doc).

Quoting from http://www.rfc-editor.org/policy.html#policy.refs:
Normative references specify documents that must be read to understand
or implement the technology in the new RFC, or whose technology must be
present for the technology in the new RFC to work. An informative
reference is not normative; rather, it only provides additional
information. For example, an informative reference might provide
background or historical information. Informative references are not
required to implement the technology in the RFC.

Regards,
 Roland