GIST: General Internet Signalling Transport
draft-ietf-nsis-ntlp-20

Approval announcement
Draft of message to be sent after approval:

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>,
    RFC Editor <rfc-editor@rfc-editor.org>, 
    nsis mailing list <nsis@ietf.org>, 
    nsis chair <nsis-chairs@tools.ietf.org>
Subject: Document Action: 'GIST: General Internet Signalling Transport' to Experimental RFC

The IESG has approved the following document:

- 'GIST: General Internet Signalling Transport '
   <draft-ietf-nsis-ntlp-20.txt> as an Experimental RFC


This document is the product of the Next Steps in Signaling Working Group. 

The IESG contact persons are Magnus Westerlund and Lars Eggert.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-nsis-ntlp-20.txt

Technical Summary
 
This draft proposes a general signaling transport protocol. It is based
on the use of existing transport and security protocols under a common
messaging layer. GIST does not handle signaling application state
itself; in that crucial respect, it differs from application signaling
protocols such as SIP, RTSP, and the control component of FTP, but this
follows the basic NSIS 2-layer signaling model defined in RFC 4080.
 
Working Group Summary

This document was previously sent back from the IESG. The WG has now
addressed the issue raised by the IESG review and thinks it ready to
progress.  

Protocol Quality
 
Magnus Westerlund was the responsible AD. This document was reviewed by
the working group chair as well as the WG. There are 6 or more independent
implementations of GIST, and there was an interop event prior to the
Paris IETF meeting. IETF Last call comments was received and has been
incorporated. Then it was sent back to the WG to take care of a number of
important to resolve issues. It has now gone through the WG process, and a
second IETF last call.

RFC-editor Note

Section 5.1, third paragraph:

OLD:
 
                 Messages with missing, duplicate or invalid objects
   for the message type MUST be rejected with an "Object Type Error"
   message with the appropriate subcode (Appendix A.4.4.9).


NEW:

                 Messages with missing, duplicate or invalid objects
   for the message type MUST be rejected with an "Object Type Error"
   message with the appropriate subcode (Appendix A.4.4.9). Note that
   unknown objects indicate explicitly how they should be treated and 
   are not covered by the above statement.