From 0131b0ff7607cebdce2c60f83c302c72d1420fe2 Mon Sep 17 00:00:00 2001 From: Alexandre Dulaunoy Date: Thu, 9 Feb 2012 21:50:30 +0100 Subject: [PATCH] Revert "RFC XML Skeleton added." This reverts commit 1b8e9334377a4dda27b45c239e9e3c916cb58c09. --- git/pdns-qof/i-d/pdns-qof.txt | 362 ------------------------------ git/pdns-qof/i-d/pdns-qof.xml | 401 ---------------------------------- 2 files changed, 763 deletions(-) delete mode 100644 git/pdns-qof/i-d/pdns-qof.txt delete mode 100644 git/pdns-qof/i-d/pdns-qof.xml diff --git a/git/pdns-qof/i-d/pdns-qof.txt b/git/pdns-qof/i-d/pdns-qof.txt deleted file mode 100644 index d3ee989..0000000 --- a/git/pdns-qof/i-d/pdns-qof.txt +++ /dev/null @@ -1,362 +0,0 @@ - - - -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/git/pdns-qof/i-d/pdns-qof.xml b/git/pdns-qof/i-d/pdns-qof.xml deleted file mode 100644 index 47a6e10..0000000 --- a/git/pdns-qof/i-d/pdns-qof.xml +++ /dev/null @@ -1,401 +0,0 @@ - - - - - - - - -]> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 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. -
- - - -