update header (GWD -> GFD)

This is the document with the new copyright statement, for Joel to do a final header/footer if needed and publish.  Thanks to the authors/editors for 
effort on this document!

Per the May 22 standards council telecon, this is approved for publication as GFD-R-P.196.  However, there is a slightly revised OGF copyright 
statement we will need to put into the document.

Final version 4.6 is now available

Richard sent follow-up email.  Next status will be confirmed by the Standards Council at their next telecon.

Still waiting for ADs (status from telecon March 27)

Status from standards council meeting March 12: Richard and Alan will touch base on this, to confirm readiness for publication.

The new document.  This is the final version, and will go to standards council final review, either at OGF or soon thereafter.

Per the 2012/02/14 standards council telecon, Richard is asked to check with the group to confirm they know the next step is in their hands.

Comments on Firewall Traversal Protocol (FiTP)
2011-12-13, Freek Dijkstra

1. I would strongly recommend to add a section on related work. While this is -as far as I know- the only Firewall traversal protocol, there certainly
 are existing NAT traversal protocols (the process is often called "NAT hole punching"). Some of these protocols are stateless (which is unrelated to 
this protocol), but some have explicit control signals, and some explicitly mention firewalls as well. The introduction section of RFC 5128 gives a 
good overview of the different protocols (even though the rest of that RFC is focussed on stateless solutions, unlike FiTP).

The related work section should at least mention:
* Stiemerling, M., Tschofenig, H., Aoun, C., and E. Davies, "NAT/Firewall NSIS Signaling Layer Protocol (NSLP)", RFC 5973, October 2010. http://tools.
ietf.org/html/rfc5973

As well as related RFCs by the NSIS working group (http://www.ietf.org/wg/concluded/nsis.html): RFC 4080, RFC 5971, and RFC 5981 

(Note: I've only just become aware of this work after following some references, but it seems similar to FiTP!)

The following standards may or may not be applicable (I leave it up to the authors to decide on that):
* Cheshire, S., Krochmal, M., and K. Sekar, "NAT Port Mapping Protocol (NAT-PMP)", Work in Progress (?), April 2008. http://tools.ietf.org/html/draft-
cheshire-nat-pmp
* Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address 
Translators (NATs)", RFC 3489, March 2003. http://tools.ietf.org/html/rfc3489
* UPnP Forum, "Internet Gateway Device (IGD) Standardized Device Control Protocol V 1.0", November 2001. http://www.upnp.org/standardizeddcps/igd.asp

2. I would like to see some pictures in the document. In particular two pictures on the two deployment scenarios (with and without a FiTP-aware 
firewall) would be helpful, showing the FiTP control connection, some (proprietary) protocol between host and firewall and the data flow through the 
firewall.

3. A (picture of) a state diagram might be useful, although I have to say that the description of result codes is already pretty extensive. At least, 
it would give the reader a quick idea on the different states.

4. Section 8 registers port number 4711 for the FiTP protocol. Please register this protocol with IANA at http://www.iana.org/cgi-bin/usr-port-number.
pl (note that IANA has changed their procedure in Summer 2011 to accommodate for SRV registrations without specific port number, this is still the old
 form. It still seems to work though.)

Port 4711 is still unassigned according to http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.txt

5. The abstract mentions a "smooth transistion" from a scenario with the end point of an FiTP control connection at (a) a external host to (b) the 
firewall itself. It is unclear to me how this is "smooth": does the initiator of a FiTP control connection need to know about the end-point? If it is 
aware of this, and the end-point changes, then this does not seem transparent to me. Perhaps I missed the transition scenario, but otherwise, it may 
be useful to elaborate on this issue.

6. Please specify the license for the Perl program in chapter 7. 
For example, all IETF documents contain the following note:

   Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Also, the Perl sample program uses a "FiTP" perl module, as mentioned in section 2.4. Is that module also available, and if so, where and under what 
license?

7. The front page does not follow the guidelines as set forward by GFD.152 (Unfortunately, most GFD documents fail in this respect). Please see the 
updated templates at http://forge.gridforum.org/sf/docman/do/listDocuments/projects.ggf-editor/docman.root.author_guidelines_and_templates
- The Status should be or "Grid Working Document (GWD) Recommendations track (RP)" or "Grid Final Draft (GFD) Recommendations track (RP)". (don't ask 
me what RP really means; I've also seem other terms for GWD and GFD.)
- The Copyright Notices should be "Copyright © Open Grid Forum (2008-2011).  Some Rights Reserved.  Distribution is unlimited." In chapter 17, the "
All Rights Reserved." should be changed to "Some Rights Reserved."
- The Trademark is not applicable to this document and should be removed.

8. There are some minor layout issues, e.g. the indentation in section 5.6.

9. Some sentences could perhaps be improved. If you have the Word source, I am happy to go through the Abstract and Introduction for some suggestions.

Entered public comment on the OGF web site on 2011-10-18. 
Comment URL is: 
http://www.ogf.org/gf/docs/comment.php?id=381

Thanks, this is looking fine.  The Standards Council will discuss it, either at OGF in Lyons, or the next meeting afterwards.  Then, it will move to 
the next step (public comment).