Mass Update

Mass Move

My mistake - this should be GFD.040 (as mentioned below).  We'll change this...  gbn

I have had further email correspondence with the authors, and expect the final copy of this document shortly.  Once it is uploaded to the tracker, we 
will go ahead and publish it.
  -- gbn

Per email from Piers: Yes, please go ahead and make the minor change to the IPv6 address size:

>>>Regarding the IP version independence guidelines doc, the longest possible
>>>IPv6 address is not 39 characters like
>>>
>>>0000:0000:0000:0000:0000:0000:0000:0000
>>>
>>>rather it can be 
>>>
>>>0000:0000:0000:0000:0000:0000:ffff:123.123.123.123
>>>
>>>which is 50 characters.

Other changes to apply (these are all minor):
- Insert current date in p1 header

- Work through the document looking at all occurrences of the word "should."  Generally, this should be changed to a different word or phrase ("the 
authors recommend..." or "for compatibility, developers might..."). This is to make sure "should" is not ambiguous compared to its use in a 
specifications document.  You don't need to change every "should," but please change those that can without needing to perform verbal gymnastics.

- since the table of contents spans pages, go ahead and start it at the top of the 2nd page (leaving blank space after the abstract on the first page)

- spell out IPv6 and IPv4 on first use, i.e., "the Internet Protocol version 6 (IPv6)".  Also spell out GGF, WG, IETF and any other acronyms on first 
use.

- remove extra hard return prior to 5.6

- Section 7, security: I think it's worthwhile mentioning at least two items here.  One is the role of IPsec, which is mentioned earlier.  Seems to me
 that security-conscious developers might choose IPv6 in order to use IPsec.  Second is to mention the possible dangers of failure by developers to 
account for the possibility of either protocol being used.  Whether to mention these or other security items is up to you, but from my point of view 
these are security considerations that are worth mentioning.

Thanks for your work on this document!   Once you have addressed the above (either by responding or going ahead with changes), upload the final 
document as a .doc and it will be published.

Per email from Piers, I will provide a little editorial feedback, then will go ahead and approve these information documents for publication (tracker 
#981 & 982).

Document will now enter 30 day public comment period.

Due date: 9-13-04

This draft has completed the necessary steps prior to
being made available for public comment.  Authors, 
working group / research group chairs, and Area
Directors should encourage individuals to participate
in the public comment process and should announce
the public comment availability to appropriate
communities and groups.

Public comments can be viewed and submitted via
the GridForge Editor pages (see Forums) or:

http://www.ggf.org/documents

Public comments play an important part in the advancement
of a GGF draft and publication as a document in the 
GGF document series.

An active public comment period strengthens the case
that the document is a useful and desired work product
for some community of consumers.