Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Please refer to RFC 3552 [RESCORLA] for guidance on writing a security considerations section. This section is required in all documents, and should not just say “there are no security considerations.” Quoting from the RFC:
“Most people speak of security as if it were a single monolithic property of a protocol or system, however, upon reflection, one realizes that it is clearly not true. Rather, security is a series of related but somewhat independent properties. Not all of these properties are required for every application.
We can loosely divide security goals into those related to protecting communications (COMMUNICATION SECURITY, also known as COMSEC) and those relating to protecting systems (ADMINISTRATIVE SECURITY or SYSTEM SECURITY). Since communications are carried out by systems and access to systems is through communications channels, these goals obviously interlock, but they can also be independently provided.”
Status of This Document
Choose one of: Grid Working Document (GWD) Grid Final Draft (GFD) Grid Recommendation Obsolete. This document is replaced by/obsoleted by GFD-xxx [REFERENCE]. Historical
Obsoletes
This document obsoletes GFD-I.xxx [REFERENCE]. [include If applicable]
Document Change History
(Note this portion of the title page is for short administrative change notices only. Include a separate section after this one as an optional change log if desired.)
This template has been updated to conform to GFD-C.152 [CATLETT]. [include if applicable]
Copyright Notice
Copyright © Open Grid Forum (insert applicable years). Some Rights Reserved. Distribution is unlimited.
Trademark
XXXX is a registered trademark and service mark of the Open Grid Forum. [include if applicable]
Abstract
Informative document abstract of 1-2 paragraphs.
This document provides information to the Grid community [topic]. It addresses [main issues] and presents [outcome]. This document does not define any standards or technical recommendations[include if applicable]
Contents
(It is recommended that the initial page include an index as below with links to the appropriate sections as an aid to navigating the printed version of the document. Note this is in addition to the GitBook and/or GitHub summary indices and is a convenience, not a requirement. The section structure indicated below includes sections required for all OGF documents as well as some example substructure. Long documetns are best organized with chapters and optionally long sections split into separate GitBook pages and/or groups. Refer to GFD.152 for complete information on the Open Grid Forum document process and requirements.)
Abstract Contents 1. Introduction 2. Notational Conventions 3. Chapter 3.1 Header Level Two 3.1.1 Header Level Three (Repeat as needed, incrementing subsequent section numbers as necessary.) 4. Security Considerations 5. Glossary 6. Contributors 7. Acknowledgments 8. Intellectual Property Statement 9. Disclaimer 10. Full Copyright Notice 11. References
Body of the document. (The word "Chapter" does not have to appear in the section title and is just used as a placeholder here.)
The file naming convention Group working Drafts (GWD) is as follows:
draft-<doctype>-<submitter>-<nickname>-<version>.doc.
E.g. draft-gwdi-example-template-v1.pdf
<doctype> is “gwdi” (Informational GWD), “gwde” (Experimental GWD), “gwdc” (Communicty Practice GWD), or “gwdrp” (candidate recommendation GWD).
<submitter> is either the name of the submitting OGF group or the family name of the submitting document author.
<version> is an integer version number proceeded by the letter v, such as v1 or v2.
Contact information for authors. You can also use this section to recognize contributions by other people who are not listed as authors, but made a useful contribution.
The title page should list the Corresponding Authors (or Editors), who are committed to taking permanent stewardship for this document – receiving communication in the future and otherwise being responsive to its content. Corresponding authors will be sought to process any error reports. The title page should contain at least one and at most three (Corresponding) Author/Editors, unless there are compelling reasons to list more.
Corresponding authors must be indicated as part of the Contributors or Authors section.
Contributors are individuals who assisted with a document’s preparation, and whose contributions are recognized in the document.
The OGF prefers the use of full first names (not initials). Complete contact information for authors must be included. Contributors are listed after authors, and do not need to have complete contact information. The nature of the contribution may be recognized.
John M. Doe Institution1 Address Country Email: jdoe@example.com
Jane Foo-Bar (Corresponding Author) Open Grid Forum Office 2515 15th Street Lubbock, Texas USA Email: jane.foobar@example.net
An overview of the document. Be as concise or as detailed as necessary, concentrating on the overall goals and features of the document as an aid to the reader.
Only include this section if applicable.
The key words ‘MUST,” “MUST NOT,” “REQUIRED,” “SHALL,” “SHALL NOT,” “SHOULD,” “SHOULD NOT,” “RECOMMENDED,” “MAY,” and “OPTIONAL” are to be interpreted as described in RFC 2119 [BRADNER], except that the words do not appear in uppercase.
The OGF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the OGF Secretariat.
The OGF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights, which may cover technology that may be required to practice this recommendation. Please address the information to the OGF Executive Director.
Include a glossary of terms to establish their specific meanings if necessary. Recommended but not required.
Copyright (c) Open Grid Forum (insert applicable years). Some Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included as references to the derived portions on all such copies and derivative works. The published OGF document from which such works are derived, however, may not be modified in any way, such as by removing the copyright notice or references to the OGF or other organizations, except as needed for the purpose of developing new or updated OGF documents in conformance with the procedures defined in the OGF Document Process, or as required to translate it into languages other than English. OGF, with the approval of its board, may remove this restriction for inclusion of OGF document content for the purpose of producing standards in cooperation with other international standards bodies.
The limited permissions granted above are perpetual and will not be revoked by the OGF or its successors or assignees.
This document and the information contained herein is provided on an “As Is” basis and the OGF disclaims all warranties, express or implied, including but not limited to any warranty that the use of the information herein will not infringe any rights or any implied warranties of merchantability or fitness for a particular purpose.
Include if desired. Contributors to the document may also be listed in the previous section.
Note that only permanent documents should be cited as references. Other items, such as Web pages or working groups, should be cited inline (i.e., see the Open Grid Forum, https://www.ogf.org) or as a footnote. In-text citations can refer to work in progress. To refer to a current working draft, an inline citation might simply read, (the XYZ working group has a draft in progress to address this topic. It may be found via the WG’s Web page at www.example.org). Hyperlinks to transient documents should be avoided (for example, a link to a current draft of a document should not be used, if the document is likely to be replaced in the near future)
References should conform to a standard such as used by IEEE[1], ACM[2], MLA[3], Chicago[4] or similar. Include an author, year, title, publisher, place of publication. For online materials, also add a URL and an access date. It may be useful, but is not required to separate out “normative references,” as described in [BUSH].
Some sample citations:
[2] https://www.acm.org/publications/authors/reference-formatting
[3] https://library.concordia.ca/help/citing/mla.php
[4] https://www.chicagomanualofstyle.org/tools_citationguide.html
Abbreviation
Reference
[BRADNER]
Scott Bradner. Key Words for Use in RFCs to Indicate Requirement Levels, RFC 2119. The Internet Society. March 1997. https://tools.ietf.org/html/rfc2026
[BUSH]
Randy Bush, Thomas Narten. Clarifying when Standards Track Documents may Refer Normatively to Documents at a Lower Level. RFC 3967. The Internet Society. December 2004. https://tools.ietf.org/html/rfc3967
[CATLETT]
Charlie Catlett, Cees de Laat, David Martin, Gregory B. Newby, Dane Skow. GFD-C.152: Open Grid Forum Document Process and Requirements. Open Grid Forum. June 2009. https://www.ogf.org/documents/GFD.152.pdf
[RESCORLA]
Eric Rescorla, Brian Korver, Internet Architectures Board, Guidelines for Writing RFC Text on Security Considerations. RFC 3552. The Internet Society. July 2003. https://tools.ietf.org/html/rfc3552