From 5e51f24181779b8a47a8bf306d382cb7c3338f68 Mon Sep 17 00:00:00 2001 From: Alexandre Dulaunoy Date: Fri, 23 Dec 2011 15:50:58 +0100 Subject: [PATCH] First skeleton of the document (based on XML RFC sample) --- i-d/pdns-qof.txt | 362 ++++++++++++++++++++++++++++++++++++++++++ i-d/pdns-qof.xml | 401 +++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 763 insertions(+) create mode 100644 i-d/pdns-qof.txt create mode 100644 i-d/pdns-qof.xml diff --git a/i-d/pdns-qof.txt b/i-d/pdns-qof.txt new file mode 100644 index 0000000..d3ee989 --- /dev/null +++ b/i-d/pdns-qof.txt @@ -0,0 +1,362 @@ + + + +Internet Engineering Task Force A.D. Dulaunoy +Internet-Draft CIRCL +Intended status: Informational L.A. Kaplan +Expires: April 13, 2012 CERT.at + October 2011 + + Passive DNS - qos + draft-ietf-xml2rfc-template-05 + +Abstract + + This document describes the output format used between Passive DNS + query interface. The output format description includes also a + common meaning per Passive DNS system. + +Status of this Memo + + This Internet-Draft will expire on April 13, 2012. + +Copyright Notice + + Copyright (c) 2011 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents (http://trustee.ietf.org/ + license-info) in effect on the date of publication of this document. + Please review these documents carefully, as they describe your rights + and restrictions with respect to this document. 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. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 + 2. Simple List . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 3. Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 4. Subsections and Tables . . . . . . . . . . . . . . . . . . . . 2 + 4.1. A Subsection . . . . . . . . . . . . . . . . . . . . . . . 2 + 4.2. Tables . . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 5. More about Lists . . . . . . . . . . . . . . . . . . . . . . . 3 + 5.1. Numbering Lists across Lists and Sections . . . . . . . . 3 + 5.2. Where the List Numbering Continues . . . . . . . . . . . . 4 + 6. Example of Code or MIB Module To Be Extracted . . . . . . . . 4 + 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 + 9. Security Considerations . . . . . . . . . . . . . . . . . . . 5 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 + 10.1. Normative References . . . . . . . . . . . . . . . . . . 5 + 10.2. Informative References . . . . . . . . . . . . . . . . . 5 + +Dulaunoy & Kaplan info [Page 1] + +Internet-Draft Abbreviated Title October 2011 + + Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . . 6 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 + +1. Introduction + + Passive DNS is a technique described by Florian Weimer in 2005 in + Passive DNS replication, F Weimer - 17th Annual FIRST Conference on + Computer Security. + +1.1. Requirements Language + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [RFC2119]. + +2. Simple List + + List styles: 'empty', 'symbols', 'letters', 'numbers', 'hanging', + 'format'. + + o First bullet + + o Second bullet + + You can write text here as well. + +3. Figures + + Figures should not exceed 69 characters wide to allow for the indent + of sections. + + Preamble text - can be omitted or empty. + + +-----------------------+ + | Use XML, be Happy :-) | + |_______________________| + + Cross-references allowed in pre- and postamble. [min_ref]. + + The CDATA means you don't need to escape meta-characters (especially + < (<) and & (&)) but is not essential. Figures may also have + a title attribute but it won't be displayed unless there is also an + anchor. White space, both horizontal and vertical, is significant in + figures even if you don't use CDATA. + +4. Subsections and Tables + +4.1. A Subsection + + By default 3 levels of nesting show in table of contents but that can + be adjusted with the value of the "tocdepth" processing instruction. + +4.2. Tables + + .. are very similar to figures: + + +Dulaunoy & Kaplan info [Page 2] + +Internet-Draft Abbreviated Title October 2011 + + + Tables use ttcol to define column headers and widths. Every cell + then has a "c" element for its content. + + +----------+----------+ + | ttcol #1 | ttcol #2 | + +----------+----------+ + | c #1 | c #2 | + | c #3 | c #4 | + | c #5 | c #6 | + +----------+----------+ + + which is a very simple example. + +5. More about Lists + + Lists with 'hanging labels': the list item is indented the amount of + the hangIndent: + + short With a label shorter than the hangIndent. + + fantastically long label With a label longer than the hangIndent. + + vspace_trick + Forces the new item to start on a new line. + + Simulating more than one paragraph in a list item using : + + a. First, a short item. + + b. Second, a longer list item. + + And something that looks like a separate pararaph.. + + Simple indented paragraph using the "empty" style: + + The quick, brown fox jumped over the lazy dog and lived to fool + many another hunter in the great wood in the west. + +5.1. Numbering Lists across Lists and Sections + + Numbering items continuously although they are in separate + elements, maybe in separate sections using the "format" style and a + "counter" variable. + + First list: + + R11 #1 + + R12 #2 + + R13 #3 + + Specify the indent explicitly so that all the items line up nicely. + + Second list: + +Dulaunoy & Kaplan info [Page 3] + +Internet-Draft Abbreviated Title October 2011 + + + R14 #4 + + R15 #5 + + R16 #6 + +5.2. Where the List Numbering Continues + + List continues here. + + Third list: + + R17 #7 + + R18 #8 + + R19 #9 + + R20 #10 + + The end of the list. + +6. Example of Code or MIB Module To Be Extracted + + The element has a number of extra attributes that can be + used to substitute a more aesthetically pleasing rendition into HTML + output while continuing to use the ASCII art version in the text and + nroff outputs (see the xml2rfc README for details). It also has a + "type" attribute. This is currently ignored except in the case + 'type="abnf"'. In this case the "artwork" is expected to contain a + piece of valid Augmented Backus-Naur Format (ABNF) grammar. This + will be syntax checked by xml2rfc and any errors will cause a fatal + error if the "strict" processing instruction is set to "yes". The + ABNF will also be colorized in HTML output to highlight the syntactic + components. Checking of additional "types" may be provided in future + versions of xml2rfc. + + + + + + + + + + + + + + + + + + + + +Dulaunoy & Kaplan info [Page 4] + +Internet-Draft Abbreviated Title October 2011 + + + + /**** an example C program */ + + #include + + void + main(int argc, char *argv[]) + { + int i; + + printf("program arguments are:\n"); + for (i = 0; i < argc; i++) { + printf("%d: \"%s\"\n", i, argv[i]); + } + + exit(0); + } /* main */ + + /* end of file */ + + +7. Acknowledgements + + This template was derived from an initial version written by Pekka + Savola and contributed by him to the xml2rfc project. + + This document is part of a plan to make xml2rfc indispensable + [DOMINATION]. + +8. IANA Considerations + + This memo includes no request to IANA. + + All drafts are required to have an IANA considerations section (see + the update of RFC 2434 [I-D.narten-iana-considerations-rfc2434bis] + for a guide). If the draft does not require IANA to do anything, the + section contains an explicit statement that this is the case (as + above). If there are no requirements for IANA, the section will be + removed during conversion into an RFC by the RFC Editor. + +9. Security Considerations + + All drafts are required to have a security considerations section. + See RFC 3552 [RFC3552] for a guide. + +10. References + +10.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [min_ref] authSurName, authInitials, "Minimal Reference", 2006. + +10.2. Informative References + +Dulaunoy & Kaplan info [Page 5] + +Internet-Draft Abbreviated Title October 2011 + + + [DOMINATION] + Mad Dominators, Inc., "Ultimate Plan for Taking Over the + World", 1984, . + + [I-D.narten-iana-considerations-rfc2434bis] + Narten, T and H Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", Internet-Draft + draft-narten-iana-considerations-rfc2434bis-09, March + 2008. + + [RFC2629] Rose, M.T., "Writing I-Ds and RFCs using XML", RFC 2629, + June 1999. + + [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC + Text on Security Considerations", BCP 72, RFC 3552, July + 2003. + +Appendix A. Additional Stuff + + This becomes an Appendix. + +Authors' Addresses + + Alexandre Dulaunoy + CIRCL + 6, rue de l'Etang + Contern, L-5326 + LU + + Phone: (+352) 247 88444 + Email: alexandre.dulaunoy@circl.lu + URI: http://www.circl.lu/ + + + Leon Aaron Kaplan + CERT.at + Karlsplatz 1/2/9 + Wien, A-1010 + AT + + Phone: +43 1 5056416 78 + Email: kaplan@cert.at + URI: http://www.cert.at/ + + + + + + + + + + + + + +Dulaunoy & Kaplan info [Page 6] diff --git a/i-d/pdns-qof.xml b/i-d/pdns-qof.xml new file mode 100644 index 0000000..47a6e10 --- /dev/null +++ b/i-d/pdns-qof.xml @@ -0,0 +1,401 @@ + + + + + + + + +]> + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Passive DNS - qos + + CIRCL +
+ + 6, rue de l'Etang + Contern + + L-5326 + LU + + (+352) 247 88444 + alexandre.dulaunoy@circl.lu + http://www.circl.lu/ + +
+ + + + + CERT.at +
+ + Karlsplatz 1/2/9 + Wien + + A-1010 + AT + + +43 1 5056416 78 + kaplan@cert.at + http://www.cert.at/ +
+ + + + General + + Internet Engineering Task Force + + template + + + + This document describes the output format used between Passive DNS query interface. The output format description includes also a common meaning per Passive DNS system. + + + + +
+ Passive DNS is a technique described by Florian Weimer in 2005 in Passive DNS replication, F Weimer - 17th Annual FIRST Conference on Computer Security. + +
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119. +
+
+ +
+ List styles: 'empty', 'symbols', 'letters', 'numbers', 'hanging', + 'format'. + + + First bullet + + Second bullet + You can write text here as well. +
+ +
+ Figures should not exceed 69 characters wide to allow for the indent + of sections. + +
+ Preamble text - can be omitted or empty. + + + + Cross-references allowed in pre- and postamble. . +
+ + The CDATA means you don't need to escape meta-characters (especially + < (&lt;) and & (&amp;)) but is not essential. + Figures may also have a title attribute but it won't be displayed unless + there is also an anchor. White space, both horizontal and vertical, is + significant in figures even if you don't use CDATA. +
+ + + + + +
+
+ By default 3 levels of nesting show in table of contents but that + can be adjusted with the value of the "tocdepth" processing + instruction. +
+ +
+ .. are very similar to figures: + + + Tables use ttcol to define column headers and widths. + Every cell then has a "c" element for its content. + + ttcol #1 + + ttcol #2 + + c #1 + + c #2 + + c #3 + + c #4 + + c #5 + + c #6 + + which is a very simple example. + +
+
+ +
+ Lists with 'hanging labels': the list item is indented the amount of + the hangIndent: + With a label shorter than the hangIndent. + + With a label longer than the + hangIndent. + + Forces the new + item to start on a new line. + + + + + + + Simulating more than one paragraph in a list item using + <vspace>: + First, a short item. + + Second, a longer list item. And + something that looks like a separate pararaph.. + + + Simple indented paragraph using the "empty" style: + The quick, brown fox jumped over the lazy dog and lived to fool + many another hunter in the great wood in the west. + + +
+ Numbering items continuously although they are in separate + <list> elements, maybe in separate sections using the "format" + style and a "counter" variable. + + First list: + #1 + + #2 + + #3 + Specify the indent explicitly so that all the items line up + nicely. + + Second list: + #4 + + #5 + + #6 + +
+ +
+ List continues here. + + Third list: + #7 + + #8 + + #9 + + #10 + The end of the list. +
+
+ +
+
+ The <artwork> element has a number of extra attributes + that can be used to substitute a more aesthetically pleasing rendition + into HTML output while continuing to use the ASCII art version in the + text and nroff outputs (see the xml2rfc README for details). It also + has a "type" attribute. This is currently ignored except in the case + 'type="abnf"'. In this case the "artwork" is expected to contain a + piece of valid Augmented Backus-Naur Format (ABNF) grammar. This will + be syntax checked by xml2rfc and any errors will cause a fatal error + if the "strict" processing instruction is set to "yes". The ABNF will + also be colorized in HTML output to highlight the syntactic + components. Checking of additional "types" may be provided in future + versions of xml2rfc. + + + +void +main(int argc, char *argv[]) +{ + int i; + + printf("program arguments are:\n"); + for (i = 0; i < argc; i++) { + printf("%d: \"%s\"\n", i, argv[i]); + } + + exit(0); +} /* main */ + +/* end of file */ + + ]]> +
+
+ +
+ This template was derived from an initial version written by Pekka + Savola and contributed by him to the xml2rfc project. + + This document is part of a plan to make xml2rfc indispensable . +
+ + + +
+ This memo includes no request to IANA. + + All drafts are required to have an IANA considerations section (see + the update of + RFC 2434 for a guide). If the draft does not require IANA to do + anything, the section contains an explicit statement that this is the + case (as above). If there are no requirements for IANA, the section will + be removed during conversion into an RFC by the RFC Editor. +
+ +
+ All drafts are required to have a security considerations section. + See RFC 3552 for a guide. +
+ + + + + + + + + + + + &RFC2119; + + + + + + Minimal Reference + + + + + + + + + + + + + + &RFC2629; + + &RFC3552; + + &I-D.narten-iana-considerations-rfc2434bis; + + + + + + Ultimate Plan for Taking Over the World + + + Mad Dominators, Inc. + + + + + + + +
+ This becomes an Appendix. +
+ + + +