diff --git a/acknowledgements.md b/acknowledgements.md
new file mode 100644
index 0000000..a2d374d
--- /dev/null
+++ b/acknowledgements.md
@@ -0,0 +1,11 @@
+---
+title: Acknowledgements
+description: 
+published: true
+date: 2021-08-16T23:26:27.911Z
+tags: 
+editor: markdown
+dateCreated: 2021-08-16T23:26:26.352Z
+---
+
+This site is based heavily on the work of Russ Housley, Ben Kaduk, Murray Kucherawy, Alvaro Retana, and the members of many IESGs.
\ No newline at end of file
diff --git a/choosing-your-tools.md b/choosing-your-tools.md
new file mode 100644
index 0000000..6ad504a
--- /dev/null
+++ b/choosing-your-tools.md
@@ -0,0 +1,59 @@
+---
+title: Choosing your format and tools
+description: 
+published: true
+date: 2021-10-10T22:15:29.825Z
+tags: 
+editor: markdown
+dateCreated: 2021-08-17T23:57:12.813Z
+---
+
+Writing Internet-Drafts is complex and time consuming and careful choice of authoring format and authoring tools can make this task much easier.
+
+## Understanding your options
+Your choice of format and tools is likely to depend on what markup languages and document editing tools you are familiar with, and how you intend to work.  Your options are:
+  1. The most popular choice is RFC XML as it is the markup language used for published RFCs and can be used end-to-end throughout the authoring process. However, RFC XML is also the most complex and best suits an author or group of co-authors who are very familiar with XML and who all have access to XML editing tools. Ideally these XML tools will support collaborative editing (more below).
+  1. After RFC XML the next most popular choice is Markdown, a simplified text markup language, used with one of the tools that converts Markdown to RFC XML.  
+  1. If you are very familiar with one of the less well known text markup languages and their normal editors, for example LaTeX, nroff or Org Mode in Emacs, then this may be a good choice for you.  A number of these markup languages are supported by tools that can convert your text to I-D format, though they may not be as well maintained or fully featured as the Markdown tools.
+  1.  Finally, there are a couple of tools that support WYSIWYG editors such as Microsoft Word, converting their output to RFC XML.
+
+## The authoring stages and different formats and tools
+To help with your choice, the diagram below deconstructs the authoring process into stages to show how the different formats and tools come in:
+
+```mermaid
+graph TD  
+  A("Initial drafting<br/>(Any format)") --> B("Collaborative editing<br/>(Any format")
+  A -.-> D
+  B -.-> D
+  B -- Optional --> C("Document validation<br/>(XML or plain text only)")
+  C -.-> D([Rendered output])
+  C --> E("Datatracker submission with document validation<br/>(XML or plain text only)")
+  E -.-> D
+  B -- Required --> E
+  E --> F("RFC Pre-publication review<br/>(XML only)")
+  F --> G([RFC Publication])
+```
+
+- **Initial drafting** 
+At this stage, you have all the options above though we recommend reading through all the stages below before you make a decision. New authors often report that they used a format and tool recommended by a fellow author and then later had to put in significant effort to convert it into something they could use more productively.
+
+- **Collaborative editing**
+It is common for a group of authors to work on an I-D and so it is important to consider if all of your co-authors can work with your chosen format and have access to and familiarity with the same tools. Additionally, you need to consider if your I-Ds will be worked on using an integrated issue tracker and source control system such as GitHub. 
+
+- **Document validation** 
+Validation is an important step for a document to ensure that it is correctly formatted and for it to successfully pass the next steps of submission as an Internet-Draft or output rendering, though many authors rely on the submission process to validate their I-D. The two supported formats for document validation tools are RFC XML and plain text.  If you have used a different format then you will need to ensure it is supported by a tool that can convert it into either plain text or XML for validation.
+
+- **Rendered output**
+It is common for authors to render their documents into a easily read format such as PDF, HTML or plain text.
+
+- **Datatracker submission with document validation**
+Datatracker only accepts documents in XML or plain text, not in any lightweight text markup language such as Markdown. All drafts are automatically validated as part of the submission process and so must be submitted as either RFC XML or plain text. If you have used a different format for authoring then you will need to ensure that it is supported by a tool that can convert it into either plain text or XML for submission.
+
+- **RFC Pre-publication review**
+If your document is chosen to become an RFC then it will need to go through the [AUTH48 pre-publication review process](https://www.rfc-editor.org/pubprocess/auth48/), which uses XML only.  If up to this point you have used plain text or a markup language that is converted into plain text for validation and submission, then the [id2xml] tool will be used to convert it into XML, which may not produce an identical looking result. At this stage you will need to work with XML to address any issues raised by the editors in order for the RFC to be published.
+
+- **RFC Publication**
+The canonical format for published RFCs is XML and the other published formats, PDF, HTML and plain text, are derived from this XML. The published XML differs from Internet-Draft XML as it has been passed through the 'prep' tool which makes it work better as a standalone document. 
+
+## Running the tools
+Be aware that some tools only work in specific editors, some only work from the command line and some require unusual runtimes to be installed to suport them. If you are not comfortable with installing and running command line tools then there are options that make this easier.
diff --git a/collaborative-editing.md b/collaborative-editing.md
new file mode 100644
index 0000000..dfc515b
--- /dev/null
+++ b/collaborative-editing.md
@@ -0,0 +1,19 @@
+---
+title: Collaborative editing
+description: 
+published: true
+date: 2021-09-01T04:06:00.191Z
+tags: 
+editor: markdown
+dateCreated: 2021-08-25T04:21:06.810Z
+---
+
+Collaborative editing is generally the hardest part of authoring an I-D as you will need to keep on top of multiple changes from multiple sources.
+
+### 1. Comparing two I-Ds with rfcdiff
+[rfcdiff](https://tools.ietf.org/rfcdiff) is a web service that provides a side-by-side comparison of two documents.  It is generally used to show the differences between two version of the same I-D to see what has changed, or between a submitted I-D and a working draft.
+
+### 2. Using GitHub with i-d-template and internet-draft-template
+GitHub is commonly used for collaborative editing of I-Ds.  Two community tools have been written to support this:
+* [i-d-template](https://github.com/martinthomson/i-d-template) uses GitHub to automate multiple aspects of the authoring process.
+* [internet-draft-template](https://github.com/martinthomson/internet-draft-template) is a GitHub repository template that works with i-d-template by creating a GitHub repository, which includes all of the automation of i-d-template. This newly created repository includes a template Markdown file.
\ No newline at end of file
diff --git a/content-considerations.md b/content-considerations.md
new file mode 100644
index 0000000..ff94342
--- /dev/null
+++ b/content-considerations.md
@@ -0,0 +1,117 @@
+---
+title: Content Considerations
+description: 
+published: true
+date: 2021-09-01T20:52:28.743Z
+tags: 
+editor: markdown
+dateCreated: 2021-08-16T23:46:37.851Z
+---
+
+#### Internet-Drafts Are Not RFCs
+
+* [ ] Verify that the I-D does not refer to itself as an RFC or a draft RFC.
+
+* [ ] Verify that the I-D neither states nor implies that it has any standards-like status.
+
+To do so conflicts with the roles of the RFC Editor and the IESG. The title of the document should not imply a status. Avoid the use of the terms Standard, Proposed, Draft, Experimental, Historic, Required, Recommended, Elective, or Restricted in the I-D title. An I-D may indicate its intended status, if it were to be published as an RFC, by setting the `status` attribute of the `seriesInfo` XML element (see [RFC 7322](https://rfc-editor.org/info/rfc7322)) or by placing the words "Intended status: \<status\>" on the left side of the headers in the first page if preparing a plaintext submission.
+
+#### Use of BCP 14 Terms
+
+If [BCP 14](https://www.rfc-editor.org/info/bcp14) language (MUST, SHOULD, etc.) is used, the guidelines in [RFC 2119](https://rfc-editor.org/info/rfc2119), especially those in Sections 6 and 7, should be followed. SHOULD is especially problematic: it needs to be clear why SHOULD is used rather than MUST, and what the implications are of varying from the recommendation.
+
+#### Programing Languages
+
+When programming languages are used in Internet-Drafts, it is necessary to include as a reference the formal definition of that coding language (e.g., C87, C99, etc.).
+
+#### Formal Languages
+
+* [ ] Verify that any use of formal languages conforms with the [IESG statement on the use of formal languages](https://www.ietf.org/about/groups/iesg/statements/formal-languages-use/).
+
+Some particular points to observe are enumerated below.
+
+##### MIB modules
+
+All MIB modules should have correct syntax, so they should compile cleanly using the `smilint` tool, e.g.:
+
+          smilint -m -s -l 6 -i namelength-32
+
+An [online service is available for MIB syntax checking](https://www.ibr.cs.tu-bs.de/projects/libsmi/tools/). This allows you to extract the MIB module from a document for your own local use, but you can also directly run a syntax check.
+
+You can also download the [`libsmi`](https://www.ibr.cs.tu-bs.de/projects/libsmi/tools/) tools for local use. In most cases, there should be no errors or warnings present in the report. Please evaluate all diagnostic messages before assuming that they are OK. If in doubt, feel free to check on the [ietfmibs mailing list](https://www.ietf.org/mailman/listinfo/IETFMIBS) or with the [OPS ADs](mailto:ops-ads@ietf.org).
+
+* [ ] Ensure that MIB modules compile cleanly
+
+* [ ] Verify that the I-D follows the guidelines in [RFC 4181](https://rfc-editor.org/info/rfc4181) as updated by [RFC 4841](https://www.rfc-editor.org/info/rfc4841).
+
+##### Augmented Backus-Naur Form (ABNF)
+
+* [ ] Ensure all Augmented Backus-Naur Form (ABNF) in the I-D compiles cleanly; [a tool is available](https://tools.ietf.org/tools/bap/). See [RFC 5234](https://rfc-editor.org/info/rfc5234) for information about IETF ABNF.
+
+* [ ] If ABNF is used, ensure the I-D contains a normative reference to RFC5234.
+
+
+##### XML
+
+Protocol specifications that use XML should always use well-formed XML at a minimum. Sample XML instances included in a specification have to be well-formed, and if the XML is supposed to be valid (according to the current W3C definition of validity), the samples must reference and be validated using an appropriate XML Schema, DTD, or another standard validation mechanism that is structurally and syntactically correct.
+
+Other guidelines for the use of XML in IETF protocols can be found in [RFC 3470](https://rfc-editor.org/info/rfc3470).  Internet-Drafts that include an XML Schema should include a normative reference to either the W3C XML Schema Definition Language 1.1 [Part1](https://www.w3.org/TR/xmlschema11-1/) or [Part 2](https://www.w3.org/TR/xmlschema11-2/) .
+
+* [ ] Verify that any XML in the I-D is well-formed, and if it is intended to be valid, confirm that it validates against the appropriate definition.
+
+XML provides structures, such as the "`<any>`" element information item in XML Schema, to allow element extensions.
+
+* [ ] Ensure the I-D contains clear guidance on how, when, and where any extension structures, such as versioning, can be used.
+
+* [ ] Check that any new or updated XML Schemas, Namespaces, and Resource Description Framework (RDF) Schemas are being registered with IANA using the procedures described in [RFC 3688](https://rfc-editor.org/info/rfc3688).
+
+##### YANG
+
+YANG (Yet Another Next Generation) is a data modeling language for data sent over network management protocols such as NETCONF and RESTCONF. Specifications that present a YANG module should test, review, and format them using [these tools and guidance](https://trac.ietf.org/trac/ops/wiki/yang-review-tools).
+
+Other useful references when considering inclusion of a YANG module include [RFC 8340](https://rfc-editor.org/info/rfc8340), [RFC 8407](https://rfc-editor.org/info/rfc8407), and the [YANG module security considerations](https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines).
+
+#### Example Addresses
+
+* [ ] Verify that examples use example FQDNs whenever possible.
+
+Addresses used in examples should use fully qualified domain names instead of literal IP addresses, and should use example FQDNs such as "foo.example.com" instead of real-world FQDNs. See [RFC 2606](https://rfc-editor.org/info/rfc2606) for example domain names that can be used. Note that the entire “.example” TLD is reserved, allowing for arbitrary subdomains (in particular, ones that are not considered same-origin on the Web.
+
+* [ ] Verify that literal IP addresses are from the example ranges.
+
+There are also ranges of IP addresses set aside for this purpose. For IPv4, these are defined in [RFC 6890](https://rfc-editor.org/info/rfc6890); for IPv6, see [RFC 3849](https://rfc-editor.org/info/rfc3849). Per the [IAB Statement on IPv6](https://www.iab.org/2016/11/07/iab-statement-on-ipv6), IPv6 examples should be used.
+
+* [ ] Verify that private addresses that would be used in the real world are not used in examples.
+
+* [ ] Verify that real telephone numbers are not used in examples.
+
+Use those numbers that were reserved for examples or fictitious use. Available numbers for use in examples are:
+
+          UK: +44-<geographic-area-code>-496-<0000-0999>
+          USA: +1-<area code>-555-<0100-0199> 
+
+For USA examples, also see [ATIS-0300115](https://www.nationalnanpa.com/pdf/NRUF/ATIS-0300115.pdf).
+
+#### Stale Text
+
+Avoid text that will become outdated after the I-D is published. Examples include non-permanent URLs, mentions of specific mailing lists as places to send comments on a document, or referring to specific WGs as a place to perform specific future actions (e.g., reviewing follow-up documents). In some cases (like the `ORGANIZATION` clause in MIB modules), references to working groups are impossible to avoid; however, generally, Internet-Drafts should not assign powers or responsibilities to WGs unless the WG in question is certain to exist as long as the practice documented in the published RFC remains valid. In cases where a specific WG is expected to be a focal point for future action, it is acceptable to give the task to the IESG, giving instructions on how the action is expected to be delegated, e.g., by forwarding to an appropriate WG or another set of experts.
+
+* [ ] Check the I-D for text that could become stale. To the extent possible, make it future-proof.
+
+#### Protocol Issues
+
+This section provides some general guidance that will help to avoid extended discussion during the document review and approval process. The IESG has compiled a [list of useful topics to consider](https://trac.ietf.org/trac/iesg/wiki/ExpertTopics).
+
+* [ ] Ensure the I-D avoids IPv4 specificity. Both IPv4 and IPv6 must be supportable, unless the protocol is naturally IPv4 specific or IPv6 specific. Expect an IPv4-only protocol to be met with friction.
+
+* [ ] Ensure the I-D does not introduce congestion issues. No application can be permitted to cause catastrophic congestion. See [RFC 2914](https://rfc-editor.org/info/rfc2914) for details. Applications using TCP or SCTP will normally fulfill this requirement automatically. Applications using UDP should adhere to the guidance in [RFC 8085](https://rfc-editor.org/info/rfc8085).
+
+* [ ] Verify that any sort of end-to-end checksum or integrity check being used (especially, but not limited to, cryptographic checksums or MACs) precisely specifies the contents of the fields to be checksummed, and in exactly what order the operations are done. Pay special attention to any area reserved for the checksum itself.
+
+* [ ] Verify that all user-visible text fields are internationalizable; see [RFC 2277](https://rfc-editor.org/info/rfc2277). For most cases, this means [UTF-8](https://rfc-editor.org/info/rfc3629). But note that it is often not sufficient to simply say that strings are encoded with UTF-8 (see below about comparisons), especially when talking about case-(in)sensitivity, case folding, and the like.
+
+* [ ] If text fields are included in some calculations, like matching, sorting, etc., verify that how those operations are applied to the Unicode/ISO 10646 character set are described in detail. See ["stringprep"](https://rfc-editor.org/info/rfc8264) for more information on the recommended way of handling comparisons.
+
+#### Inclusive Language
+
+The IESG has made a [statement](https://www.ietf.org/about/groups/iesg/statements/on-inclusive-language/) recommending authors review [NISTIR 8366](https://doi.org/10.6028/NIST.IR.8366) for guidelines on using inclusive terminology.
\ No newline at end of file
diff --git a/document-validation.md b/document-validation.md
new file mode 100644
index 0000000..9093ddf
--- /dev/null
+++ b/document-validation.md
@@ -0,0 +1,57 @@
+---
+title: Document validation
+description: 
+published: true
+date: 2021-09-01T04:12:04.357Z
+tags: 
+editor: markdown
+dateCreated: 2021-08-20T02:57:26.157Z
+---
+
+As your I-D evolves you will inevitably want to check the contents and validate the format at regular stages.
+
+## Checking spelling, grammar and terminology
+
+### 1. idspell
+[idspell](https://tools.ietf.org/tools/idspell/webservice) is a shell script that checks the spelling of plain text I-Ds. It requires GNU Aspell and supplements that with a [custom wordlist](tools.ietf.org/tools/idspell/ietf-words.wl) of common IETF terminology built from two years' of published RFCs, the surnames of I-D authors in the reference bibliography and a short list of manually added words.
+
+## Validating your Internet-Draft
+Document validation is an important step for an Internet-Draft to ensure that it is correctly formatted.  This is different from the syntax validation that some of the tools perform as you use them.
+
+### 1. Validating XML I-Ds with xml2rfc
+XML I-Ds are validated through one of three methods:
+
+1. Using the xml2rfc [web service]()
+1. Running [xml2rfc] locally or as part of your build process
+1. By submitting the I-D to datatracker. This will automatically use [xml2rfc] to validate the I-D and report any errors.
+
+### 2. Validating plain text I-Ds with idnits
+Plain text I-Ds are validated through one of three methods:
+
+1. Using the idnits [web service](https://tools.ietf.org/tools/idnits/webservice).
+1. Running [idnits](https://tools.ietf.org/tools/idnits/index) locally or as part of your build service.
+1. By submitting the I-D to datatracker. This will automatically use [idnits] to validate the I-D and report any errors.
+
+### 3. Validating I-Ds in other formats
+Document validation is only possible for I-Ds written in XML or plain text.  An I-D authored in a different format needs to be converted to either XML or plain text and then validated using one of the methods above.
+
+## Validating formal languages
+There are a number of formal languages used in I-Ds and several tools have been written to help process them.
+
+### 1. rfcstrip
+[rfcstrip](https://github.com/mbj4668/rfcstrip) extracts code components, YANG modules and SMIv2 modules from RFCs and I-Ds, and extracts and unfolds artwork from RFCs and I-Ds in XML format.
+
+### 2. Extract and validate ABNF with bap
+[bap](https://github.com/fenner/bap) can extract and validate ABNF.  The extraction feature is available as a separate [web service](https://tools.ietf.org/abnf/) and the validation as a separate [web form](https://tools.ietf.org/tools/bap/abnf.cgi).
+
+### 3. MIB templates from the MIB doctors
+The MIB Doctors have produced three templates specifically aimed at drafts containing MIB modules: 
+* The first is an [XML template](https://tools.ietf.org/tools/templates/mib-doc-template-xml.txt). Some advice echoing guidelines from RFC4181 is embedded in comments. 
+* A second template is a plain text [template for MIB documents with advice embedded](https://tools.ietf.org/tools/templates/mib-doc-template-advice.txt) in the document. 
+* A third template is a plain text [template with no advice included](https://tools.ietf.org/tools/templates/mib-doc-template-plain.txt).
+
+### 4. Extract and validate YANG with YANG Catalog
+[YANG Catalog](https://www.yangvalidator.com/) is a website operated and maintained by the IETF that provides a central resource for the use of YANG, including the [YANG Validator](https://www.yangvalidator.com/yangvalidator).
+
+### 5. Validate SVG with svgcheck
+[svgcheck](https://github.com/ietf-tools/RfcEditor/tree/master/svgcheck) takes an XML file containing an SVG or an RFC document. It then compares all of the SVG elements with the schema defined in the document with RFC 7996 bis. The program has the option of modifying and writing out a version of the input that passes the defined schema.
\ No newline at end of file
diff --git a/drafting-in-markdown.md b/drafting-in-markdown.md
new file mode 100644
index 0000000..63cd9f7
--- /dev/null
+++ b/drafting-in-markdown.md
@@ -0,0 +1,30 @@
+---
+title: Drafting in Markdown
+description: 
+published: true
+date: 2021-09-01T03:46:50.337Z
+tags: 
+editor: markdown
+dateCreated: 2021-08-18T10:57:57.022Z
+---
+
+Markdown is a lightweight markup language that is widely supported.  While Markdown is significantly easier to use than XML is also less powerful and is less standardised.  Consequently the Markdown toolchains are very popular but the tools are not interchangeable as they use different syntaxes.
+
+## Markdown toolchains
+The following Markdown toolchains have been reported in common use by I-D authors.
+
+### 1. kramdown-rfc2629
+[kramdown-rfc2629](https://github.com/cabo/kramdown-rfc2629) is an open source text processor that converts files written in its proprietary markdown syntax into RFC XML. 
+
+The IETF provides an [experimental web service implementation](https://xml2rfc.tools.ietf.org/experimental.html) of kramdown-rfc2629.
+
+[draftr](https://ipv.sx/draftr-js/) provides a live on-screen conversion using kramdown-rfc2629.
+
+### 2. mmark
+[mmark](https://mmark.miek.nl) is an open source text processor that converts files written in its proprietary markdown syntax into RFC XML.
+
+## Supporting tools
+Authors writing in Markdown may find the following tools helpful:
+
+### 1. bibxml2md
+[bibxml2md](https://github.com/yaronf/bibxml2md) converts BibXML references into Markdown.  The IETF publishes a [library of BibXML references](https://xml2rfc.tools.ietf.org).
\ No newline at end of file
diff --git a/drafting-in-others-formats.md b/drafting-in-others-formats.md
new file mode 100644
index 0000000..279b895
--- /dev/null
+++ b/drafting-in-others-formats.md
@@ -0,0 +1,54 @@
+---
+title: Drafting in other formats 
+description: 
+published: true
+date: 2021-09-01T03:47:42.794Z
+tags: 
+editor: markdown
+dateCreated: 2021-08-19T09:01:14.498Z
+---
+
+There are many other lightweight text markup languages with their own processing systems. Those listed here are supported by a toolchain that produces ether a plain text Internet-Draft that is then converted into XML using the id2xml tool, or an RFC XML file that can be processed by xml2rfc.
+
+Most of these toolchains are not widely used and in some cases rely on tools that are unmaintained. 
+
+## AsciiDoc
+[AsciiDoc](https://asciidoc.org) is a text document format similar to Markdown.
+
+### 1. AsciiRFC with metanorma-ietf
+[AsciiRFC](https://datatracker.ietf.org/doc/html/draft-ribose-asciirfc) is an AsciiDoc syntax for writing IETF documents.  The [metanorma-ietf](https://github.com/metanorma/metanorma-ietf) tool converts documents in AsciiRFC into RFC XML.  
+
+## LaTeX
+[LaTeX](https://www.latex-project.org) is an open source typesetting system designed for the production of technical and scientific documentation. An out of date [LaTeX template](https://www.rfc-editor.org/materials/2-latex.template.txt) is available.
+
+### 1. Lyx with lyx2rfc
+[Lyx](https://www.lyx.org) is an open source what-you-see-is-what-you-mean (WYSIWYM) GUI editor for LaTeX documents. [lyx2rfc](https://github.com/nicowilliams/lyx2rfc) is a plugin to Lyx that converts LyX XHTML output to RFC XML.
+
+lyx2rfc is unmaintained and was last updated in 2014.
+
+## Nroff format
+Nroff is a text formatting program that produces output suitable for fixed-width files. An out of date [Nroff template](https://www.rfc-editor.org/materials/3-nroff.template) is available with a similarly out of date [tutorial](https://www.rfc-editor.org/materials/nroff.html).
+
+[xml2rfc] can convert an I-D in RFC XML into Nroff format.
+  
+### 1. Emacs editor in Nroff mode
+The popular open source editor Emacs includes [Nroff mode](https://www.gnu.org/software/emacs/manual/html_node/emacs/Nroff-Mode.html).
+
+### 2. Nroff with Nroff Edit
+[Nroff Edit](https://aaa-sec.com/nroffedit/) is a Java based WYSIWYG editor for writing and editing Internet-Drafts in Nroff. The Nroff based Internet-Draft file is edited in the left window while the resulting compiled text version is instantly shown in the right Window as a result of any edit changes.
+
+Nroff Edit is unmaintained and was last updated in 2015.
+
+### 3. Nroff with nroff2xml
+[nroff2xml](https://github.com/tomaszmrugalski/nroff2xml) is a Python script that converts a file in Nroff format into v2 RFC XML.  
+
+nroff2xml is unmaintained and was last updated in 2013.
+
+## Org Mode
+Org is a highly flexible structured plain text file format that is used mainly in the Emacs editor in [Org Mode](https://orgmode.org).
+
+### 1. Org Mode RFC XML Exporter
+[Org Mode RFC XML Exporter](https://github.com/choppsv1/org-rfc-export) is an Emacs plugin that exports Org Mode files to RFC XML.
+
+
+
diff --git a/drafting-in-wysiwyg-editors.md b/drafting-in-wysiwyg-editors.md
new file mode 100644
index 0000000..d6f1a23
--- /dev/null
+++ b/drafting-in-wysiwyg-editors.md
@@ -0,0 +1,25 @@
+---
+title: Drafting in WYSIWYG editors
+description: 
+published: true
+date: 2021-10-10T22:20:32.677Z
+tags: 
+editor: markdown
+dateCreated: 2021-08-18T10:58:56.227Z
+---
+
+WYSIWYG is used here to mean the class of tools where the author uses a GUI with no visibility of the underlying document format. 
+
+## WYSIWYG toolchains
+The toolchains listed here support WYSIWYG editing.
+
+### 1. MS Word with RFC 5385 template and tool
+The [Template for Internet-Drafts and RFCs for WinXP MS Word 2000+](https://www.strayalpha.com/tools/) comprises an MS Word template and a Perl script for converting your resulting .docx file into RFC XML.  This is fully documented in [RFC 5385](https://datatracker.ietf.org/doc/html/rfc5385).
+
+### 2. MS Word with RFC Tool
+[RFC Tool](https://github.com/hallambaker/PHB-Build-Tools/tree/master/DocTools/rfctool) converts .docx files from MS Word into RFC XML.  This is documented in [draft-hallambaker-rfctool](https://datatracker.ietf.org/doc/html/draft-hallambaker-rfctool).
+
+## Other WYSIWYG
+In addiiton to the toolchains listed above, a number of the [XML toolchains](/drafting-in-xml) support near-WYSIWYG drafting.
+
+Other WYSIWYG editors, such as LibreOffice, are not listed because there is no support for exporting or converting to RFC XML, though that can be used for Plain Text drafting.
\ No newline at end of file
diff --git a/drafting-in-xml.md b/drafting-in-xml.md
new file mode 100644
index 0000000..73851f0
--- /dev/null
+++ b/drafting-in-xml.md
@@ -0,0 +1,55 @@
+---
+title: Drafting in XML
+description: 
+published: true
+date: 2021-10-10T21:03:25.287Z
+tags: 
+editor: markdown
+dateCreated: 2021-08-18T10:56:56.326Z
+---
+
+## Introducing RFC XML
+RFC XML, also called 'The "xml2rfc" vocabulary', is an XML markup language that has been used as the canonical format for published RFCs since RFC 8650 in November 2019.  
+
+The current version of RFC XML, v3, is formally defined in a RELAX NG Compact Syntax (RNC) schema as documented and explained in [RFC 7991](https://www.rfc-editor.org/info/rfc7991). Since the publication of RFC 7991, a number of changes have been made to the schema that are currently documented in the [implementation notes for RFC 7991](https://datatracker.ietf.org/doc/html/draft-levkowetz-xml2rfc-v3-implementation-notes-11).
+
+The previous version of RFC XML, v2, is still actively used as some of the tools that process RFC XML do not fully support v3 or still default to v2. RFC XML v2 is documented and explained in [RFC 7749](https://www.rfc-editor.org/info/rfc7749).
+
+A small [library](https://tools.ietf.org/tools/templates/) of RFC XML templates is available though these are under review and likely to be updated and moved.
+
+Published RFCs go through a 'prep' process that makes multiple changes to the RFC XML in order to support the long time archival nature of RFCs.  While RFCs validate with the same schema, using an XML RFC as a template for an Internet-Draft is not recommended. 
+
+## What to look for in an XML toolchain
+There are two key features to look for in an XML toolchain:
+1. RNC schema validation. This ensures that your document is valid RFC XML as you type it.
+1. RNC aware editing support. 
+
+To take advantage of these features your XML code must include an [`<?xml-model ...>`](https://www.w3.org/TR/xml-model/) processing instruction as found in the [schema aware templates]() below.
+
+## RFC XML toolchains
+The following XML toolchains have been reported as in use by IETF community members.  These are all interactive XML editors. 
+
+### 1. Emacs editor in nXML Mode
+The popular open source editor Emacs includes [nXML Mode](https://www.gnu.org/software/emacs/manual/html_mono/nxml-mode.html), which enables validation and schema-sensitive editing when you use an RNC schema. 
+
+### 2. XMLmind XML Editor (XXE) with xml2rfc-xxe
+[XMLmind XML Editor (XXE)](https://www.xmlmind.com/xmleditor/) is a commercial near-WYSIWYG XML editor with a free edition for personal use.  XXE supports RNC schema validation and context-sensitive editing.
+
+A community developed configuration for XXE, [xml2rfc-xxe](https://github.com/wkumari/xml2rfc-xxe/) is available, providing additional context-sensitive editing features. 
+
+### 3. Oxygen XML Editor
+[Oxygen XML Editor](https://www.oxygenxml.com/xml_editor.html) is a commercial XML editing tool that comes in different versions with a number of different licensing options. All versions support RELAX NG validation and some support syntax highlighting and intelligent auto-completion. The premium version also supports collaborative edIting, including tracked changes and comment review.
+
+The same company also makes [Oxygen Content Fusion](https://www.oxygenxml.com/content_fusion.html), which support web-based collaborative editing and document review.
+
+## Supporting tools
+Authors writing in XML may find the following tools helpful:
+
+### 1. Add XML tags for RFC2119 keywords
+This [script](https://strayalpha.com/software/rfcxml/lookback-bcp-fix.pl) adds `<bcp14>` tags around RFC 2119 keywords in XML source.
+
+### 2. bibtex2rfc
+[bibtex2rfc](https://github.com/yaronf/bibtex2rfc) converts BibTeX citations into BibXML references. The IETF publishes a [library of BibXML references](https://xml2rfc.tools.ietf.org), which should be checked first.
+
+## TODO
+- DTDs
diff --git a/format.md b/format.md
new file mode 100644
index 0000000..75c2de9
--- /dev/null
+++ b/format.md
@@ -0,0 +1,45 @@
+---
+title: Format
+description: 
+published: true
+date: 2021-08-19T10:36:34.221Z
+tags: 
+editor: markdown
+dateCreated: 2021-08-16T23:24:47.622Z
+---
+
+Formatting is automatically handled when Internet-Drafts are submitted in XML form. Authors of such I-Ds have very few formatting issues to consider. The primary consideration is ensuring the tools are able to render the various formats. In particular, the content of the XML must be amenable to rendering with the 72 character per line restriction in the text format.
+
+Authors preparing Internet-Drafts in plain text must ensure the document conforms to many formatting rules.
+
+The format constraints for a plaintext I-D are primarily the same as those for the text format of an RFC as specified in [RFC 7994](https://rfc-editor.org/info/rfc7994). One notable difference is that Internet-Drafts are paginated, and include running headers and footers. A few formatting requirements are highlighted here, but authors preparing plaintext documents should fully understand the requirements in [RFC 7994](https://rfc-editor.org/info/rfc7994), [RFC 7841](https://rfc-editor.org/info/rfc7841), [RFC 7332](https://rfc-editor.org/info/rfc7332), [RFC 7322](https://rfc-editor.org/info/rfc7322), the RFC Editor's [Style Guide](https://www.rfc-editor.org/styleguide/), and the [current acceptable boilerplate texts](https://www.iab.org/documents/headers-boilerplate/).
+
+The submission tool will block submission for many formatting errors and flag many others. The [`idnits` tool](https://tools.ietf.org/tools/idnits/) can be used to identify those so they can be corrected before submission. Well-formatted I-Ds tend to progress through the review process more quickly. When an I-D is approved for publication as an RFC, the RFC Editor can take care of a few small formatting errors. However, if many formatting errors exist, the document will be returned to the stream requesting publication for fixes. Please be aware that not conforming to the formatting rules will most probably delay publication and consume time that can be spent on other work.
+
+These are formatting requirements for plaintext I-Ds that often are overlooked:
+
+* [ ] Verify that the document name and version appears on the first page.
+
+* [ ] Verify that the I-D contains a "Table of Contents" section between the "Copyright Notice" and the introduction. This section must not be numbered.
+
+* [ ] Verify that no text extends beyond the 72nd column of a line. This limit is especially important for diagrams, which the RFC Editor may not be able to trivially reformat to fall within the margins.
+
+* [ ] Verify that source code does not extend beyond the 69th column.
+
+* [ ] Verify that the text is ragged-right.
+
+* [ ] Verify that hyphenation is not used for line breaks. However, hyphenated words (e.g., "Internet-Draft") may be split at the hyphen across successive lines.
+
+* [ ] Verify that the I-D contains no footnotes.
+
+* [ ] Verify the characters in the I-D meet the requirements of [RFC 7994](https://rfc-editor.org/info/rfc7994). In brief, the document must be UTF-8 encoded, but code points not corresponding to ASCII are allowed only in certain contexts (see [RFC 7997](https://rfc-editor.org/info/rfc7997)). Control characters other than `CR`, `NL`, and `FF` are not allowed. The use of non-ASCII characters is limited to when there is a specific need, most notably for names. Many uses of non-ASCII characters will require listing the Unicode codepoint by number in addition to the character itself.
+
+* [ ] Verify that the "Status of This Memo" and "Abstract" sections are not numbered.
+
+* [ ] Verify that the appropriate boilerplate text in the IPR-related sections is reproduced exactly (see the [IPR-Related Notices section](#ipr-related-notices)). In particular, ensure that the names of RFCs contained in that content are not reformatted as references.
+
+* [ ] Verify that the I-D is well formatted for readability and clarity.
+
+* [ ] If the I-D has "Contributors" and/or "Acknowlegments" sections, verify that the sections are unnumbered and placed after the "References" section and any appendices. See Section 4 of [RFC 7322](https://rfc-editor.org/info/rfc7322).
+
+* [ ] Verify that references to Internet-Drafts and RFCs are formatted as shown in the "web portion" of the RFC Editor's Style Guide (see [here](https://www.rfc-editor.org/styleguide/part2/#ref_ids) for guidance on I-Ds and [here](https://www.rfc-editor.org/part2/#ref_rfcs) for guidance on RFCs). Note that these formats can change over time, so review these links carefully with each document submission.
diff --git a/home.md b/home.md
new file mode 100644
index 0000000..958445f
--- /dev/null
+++ b/home.md
@@ -0,0 +1,15 @@
+---
+title: Home
+description: Welcome to the Internet-Draft/RFC author resources site
+published: true
+date: 2021-08-20T03:13:33.476Z
+tags: 
+editor: markdown
+dateCreated: 2021-08-18T00:11:52.864Z
+---
+
+Welcome to the Internet-Draft authors resource site.
+
+This site is the main resource site for authors of an Internet-Draft (I-D) or those who want to author an I-D, with information on how to write an I-D and the tools available to support this.  It does not cover the IETF [standards development process](https://www.ietf.org/standards/process/) or the RFC publication process.
+
+**!! THIS SITE IS STILL UNDER CONSTRUCTION AND THE INFORMATION ON IT SHOULD NOT BE TRUSTED UNTIL IT GOES LIVE !!**
\ No newline at end of file
diff --git a/i-d-author-guidelines-complete.md b/i-d-author-guidelines-complete.md
new file mode 100644
index 0000000..44459df
--- /dev/null
+++ b/i-d-author-guidelines-complete.md
@@ -0,0 +1,918 @@
+---
+title: I-D author guidelines
+description: 
+published: true
+date: 2021-08-24T04:14:15.156Z
+tags: 
+editor: markdown
+dateCreated: 2021-08-24T04:14:11.973Z
+---
+
+# Guidelines to Authors of Internet-Drafts
+
+## Table of Contents
+
+* [Introduction](#introduction)
+* [Background](#background)
+* [Internet-Draft Names](#internet-draft-names)
+* [The Submission Process](#the-submission-process)
+* [Content](#content)
+  * [Required Content](#required-content)
+  * [Content Considerations](#content-considerations)
+* [Format](#format)
+* [Acknowledgement](#acknowledgement)
+
+## Introduction
+
+Internet-Drafts (I-Ds) are the basic work items of the IETF. They are the
+primary inputs into what may eventually be published as a Request for Comment
+(RFC).
+
+Internet-Drafts are used by all of the [RFC
+Streams](https://rfc-editor.org/info/rfc8729). The guidance in this document
+applies to all streams unless it is identified as specific to a particular
+stream.
+
+Internet-Drafts are prepared by people acting in possibly several roles, such
+as an author or an editor. This guidance uses the term "author", but the
+guidance applies to people acting in any role.
+
+This document collects and summarizes requirements and guidance from
+many sources. The following resources should be consulted
+for definitive details:
+
+* The IETF Standards Process is described in [RFC
+  2026](https://rfc-editor.org/info/rfc2026).
+* The IETF rules concerning copyright are described in [BCP
+  78](https://www.rfc-editor.org/info/bcp78).
+* The IETF rules on IPR are described in [BCP
+  79](https://www.rfc-editor.org/info/bcp79).
+* The IETF [Trust Legal Provisions Relating to IETF
+  Documents](https://trustee.ietf.org/documents/trust-legal-provisions/), called
+  "the TLP" for short, provides many details about copyright policy and
+  practice.
+
+Much of the guidance in this document is in the form of something that can be
+inspected, or checked, to see whether changes should be made before submitting
+an I-D. These items are marked with checkboxes ([ ]). However, authors are
+expected to be familiar with and to apply the full guidance in this document.
+
+There are tools to help with the creation of Internet-Drafts. Rather than
+attempting to construct a plaintext Internet-Draft manually, it is highly
+recommended using a structured language for authoring, and a toolchain like
+[xml2rfc](https://pypi.org/project/xml2rfc/) or
+[kramdown-rfc2629](https://github.com/cabo/kramdown-rfc2629) to build a
+submission.
+
+An [online converter](https://xml2rfc.tools.ietf.org/experimental.html) for
+documents in the [xml2rfc](https://pypi.org/project/xml2rfc/) or
+[kramdown-rfc2629](https://github.com/cabo/kramdown-rfc2629) input formats is
+available. Authors working with the xml2rfc XML source format should be familiar
+with [the XML grammar](https://rfc-editor.org/info/rfc7991) [that the xml2rfc
+tool currently accepts](https://xml2rfc.tools.ietf.org/xml2rfc-doc.html), and
+the [RFC Editor's FAQ on using the v3 XML
+format](https://www.rfc-editor.org/materials/FAQ-xml2rfcv3.html).
+
+As Internet-Drafts may be eventually published as RFCs, it is recommended to
+consult the [RFC Editor's publication
+process](https://www.rfc-editor.org/pubprocess/).
+
+## Background
+
+All versions of Internet-Drafts are kept in the [Internet-Draft
+Archive](https://www.ietf.org/archive/id). Active versions of Internet-Drafts
+are also placed in the [Internet-Draft Repository](https://www.ietf.org/id).
+
+Versions of Internet-Drafts are removed from the Repository when any of the
+following occur:
+
+* The I-D is updated with a new version.
+* The I-D is replaced by another Internet-Draft.
+* The I-D is published as an RFC.
+* The I-D expires.
+
+An I-D expires 185 days after it was placed in the Repository, unless it
+is in a state that prevents it from expiring. Examples of such states include
+being processed by the IESG for publication in the IETF stream, or being under
+review by the Independent Series Editor (ISE) for publication in the
+[Independent Submission Stream](https://www.rfc-editor.org/about/independent/).
+
+Internet-Drafts are not removed from the Archive when they are removed from the
+Repository. Removing an I-D from the Archive occurs only in exceptional
+circumstances, described in [this IESG
+Statement](https://www.ietf.org/about/groups/iesg/statements/internet-draft-removal/).
+
+Even though Internet-Drafts are kept in the Archive, they are not an archival
+series and should not be cited or quoted as anything other than "work in
+progress".
+
+## Internet-Draft Names
+
+Internet-Draft names appear inside the I-D, and are used as components of
+filenames for the various formats the I-D may appear in. The characters
+that may appear in an I-D name are restricted:
+
+* [ ] Ensure that the I-D name consists only of
+  * the lowercase letters `a-z`,
+  * the digits `0-9`,
+  * or hyphens (`-`).
+
+The name of an I-D consists of several components, separated by a hyphen.
+No empty components are allowed. That is, consecutive hyphens may not appear
+in an I-D name.
+
+The first component identifies the I-D as a draft (as opposed to other
+document types, such as a charter or a review).
+
+* [ ] Verify that the I-D name begins with `draft-`.
+
+The second component identifies the source of an I-D. If an I-D has
+been adopted into any stream other than the Independent Submission Stream,
+this component will identify the stream.
+
+If the I-D has not been adopted into any stream or if it is being considered for
+publication in the Independent Submission Stream, the second component should
+consist of a string related to the names(s) of the author(s). There are no
+mechanical rules for this string beyond consisting only of the allowed
+characters. However, objectionable or misleading strings are subject to change
+or removal. The string is typically the last name of the lead author or editor.
+
+The second component must not be easily confused with a group acronym. The
+following strings for the second component are reserved for their respective
+organizations (some of which are historic):
+
+* `iana`
+* `iaoc`
+* `iesg`
+* `ietf-trust`
+* `rfc-editor`
+
+The second component should not contain a hyphen. Legacy uses and edge cases
+such as hyphenated last names are allowed. Having a hyphen in the second
+component makes it hard to extract programmatically. This forces many tools
+to use heuristics when tying to locate the second component.
+
+* [ ] Ensure the second component reasonably identifies the source of the I-D.
+
+* [ ] If the I-D has been adopted by a stream, ensure the second component is:
+  * `ietf` for the IETF stream
+  * `irtf` for the IRTF stream
+  * `iab` for the IAB stream
+
+Otherwise, ensure that the second component is not a group acronym or a
+reserved string, is not objectionable, and does not introduce confusion.
+
+Note that any I-D submitted with one of these stream identifiers in the second
+component that has not been adopted by the indicated stream will either be
+rejected or replaced.
+
+If the I-D is targeted at or has been adopted by a group, the group's acronym
+should be added to the name just after the second component, separated by a
+hyphen.
+
+* [ ] Ensure an adopted or group-targeted I-D identifies the group just after
+  the second component by including the group's acronym.
+
+Note again that if the I-D has not been adopted into a stream, and it identifies
+a stream in the second component, it will be rejected or replaced. In particular
+for IETF stream documents, the first version of an I-D with a name that begins
+with `draft-ietf-acronym-` for any working group acronym must be approved by the
+working group's chairs before it will be posted.
+
+The remainder of the name describes the purpose of the I-D, usually in just a
+few words. Each word is separated by a hyphen.
+
+* [ ] Ensure the name reasonably reflects the purpose of the I-D.
+
+Internet-Drafts are versioned with two digits, separated from the name with a
+hyphen. The initial version of an I-D must be `00`, and subsequent updates must
+increment the version number by one.
+
+If the I-D is submitted as XML (which is highly recommended), the name and
+version of the document will be declared in the appropriate ["name" and
+"version" attributes](https://rfc-editor.org/info/rfc7991), and the filename
+submitted must be of the form `name-version.xml`.
+
+If the I-D is submitted as plain text (which is not recommended), the name and
+version will appear on the document's first page, and the filename submitted
+must be of the form `name-version.txt`.
+
+Convention dictates that an individual submission seeking adoption by a
+working group will include the working group's acronym just after the
+second component. For example, a person or group identified as "foo"
+seeking to get a document about "specific-subject" adopted by the "bar"
+working group might choose the name `draft-foo-bar-specific-subject`, and
+submit the file `draft-foo-bar-specific-subject-00.xml`. If the document is
+later adopted by the working group, the authors will usually create a new
+I-D named `draft-ietf-bar-specific-subject` and submit it as
+`draft-ietf-bar-specific-subject-00.xml`. Note that the version number of
+this new I-D will always be `00`.
+
+## The Submission Process
+
+Internet-Draft submissions are made using the [IETF Datatracker's submission
+tool](https://datatracker.ietf.org/submit). An I-D submission should preferably
+be an [xml2rfc version 3](https://rfc-editor.org/info/rfc7991) XML source file,
+but a [version 2 source](https://rfc-editor.org/info/rfc7749) will be accepted.
+If an XML source is not available, a plaintext submission will be accepted.
+
+Currently, the submission tool will accept both an XML and plaintext
+submission, as well as PDF and PostScript versions of the document. In such
+submissions, the XML is authoritative, if present, otherwise the plain text is
+authoritative. It is expected that the tool will change to allow only the
+submission of XML or plain text, but not both, and to not accept other formats.
+
+**In short: submit XML if at all possible, with v3 preferred over v2.**
+
+If XML source is submitted, the Datatracker will generate a plain text version
+of the I-D and place it in the Archive. If v3 source is submitted, the
+Datatracker will also generate an HTML version and place it in the Archive.
+
+When a submission is made through the submission tool, the authors will
+receive email with a request to verify the submission. The submission will
+not be accepted and posted until the action requested in that email is
+performed. If the submitter is logged into the Datatracker and listed as
+an author this step is bypassed.
+
+If the I-D being submitted replaces another I-D (such as in the earlier
+example discussing creating a new I-D when a working group adopts a
+document), the submitter will be able to identify the replacement using
+the submission tool. A group chair or the IETF Secretariat will verify
+the replacement before the relationship is added to the Datatracker.
+
+The submission tool will double-check many, but not all, of the guidance points
+called out in this document. Authors are expected to have manually applied the
+guidance before submission.
+
+While many of the requirements highlighted by this document are for RFCs,
+Internet-Drafts are expected to adhere to them to the extent possible. In
+particular, IETF stream I-Ds submitted to the IESG must follow all of the
+guidance. Working groups are encouraged to require the guidance be followed for
+I-Ds entering Working Group Last Call. I-Ds will progress through the review
+and publication process more efficiently the earlier the guidance is followed
+in the I-D.
+
+### Manual Submissions
+
+If authors are unable to submit an I-D through the Datatracker, they may make a
+manual-post request by sending the I-D via email to support@ietf.org. The
+message may contain the I-D as an attachment, or a URL that will resolve to the
+I-D. The I-D must be a standalone document in either XML or plaintext format.
+Multiple files presented in containers such as zip or tar will not be accepted.
+All other formats will be discarded without opening.
+
+Be aware of the deadlines for submitting I-Ds before each IETF Meeting. The
+[important dates page](https://datatracker.ietf.org/meeting/important-dates)
+will show the deadline for submitting I-Ds. Some meetings may have an earlier
+deadline for initial versions of I-Ds than for updates to existing I-Ds. After
+the deadlines, submissions will not be accepted until the meeting begins. The
+leadership responsible for each stream can override this submission blackout
+period when appropriate. Care should be taken when submitting an I-D near the
+deadline, especially if a manual post is requested. The steps to confirm and
+post the submission take time.
+
+## Content
+
+Internet-Drafts and RFCs have certain required content. I-Ds should take the
+accrued knowledge on frequent and particularly important topics into
+consideration as early in their life cycle as possible.
+
+### Required Content
+
+If an Internet-Draft is prepared in XML, the tooling will ensure that
+required content is present, automatically provide selected boilerplate
+text, and handle the majority of formatting concerns. An Internet-Draft
+prepared as plain text requires more effort to ensure that the required
+content is present and in the right form.
+
+As Internet-Drafts are inputs into what might eventually be published as RFCs,
+their content requirements are based on what is required in an RFC.
+Specifically, many of the documents defining these requirements are written in
+terms of RFCs and do not mention Internet-Drafts, but these requirements, with
+very few exceptions, apply to Internet-Drafts. See [RFC
+7841](https://rfc-editor.org/info/rfc7841) for specific details.
+
+* [ ] Ensure that the I-D correctly provides the following:
+  * The date the document was generated.
+  * A list of authors/editors and their affiliations.
+  * The group that originated the I-D (if any).
+  * The intended status of the document.
+  * The set of RFCs this I-D intends to update or replace, if any.
+
+These required elements are represented explicitly in XML source. The tools
+will automatically format the information when building a presentation format.
+The format required for these items in plaintext submissions is discussed
+in the [Format section](#format) below.
+
+* [ ] Ensure that the I-D contains each of the following sections:
+  * IPR-Related Notices
+  * Abstract
+  * Introduction
+  * Security Considerations
+  * IANA Considerations
+  * References
+  * Authors' Addresses
+
+* [ ] If the document uses [BCP 14](https://www.rfc-editor.org/info/bcp14)
+  normative language, ensure the unchanged boilerplate text from [BCP
+  14](https://www.rfc-editor.org/info/bcp14) is present in the I-D, and that
+  [BCP 14](https://www.rfc-editor.org/info/bcp14) is normatively referenced.
+
+Note that [BCP 14](https://www.rfc-editor.org/info/bcp14) is made up of both
+[RFC 2119](https://rfc-editor.org/info/rfc2119) and [RFC
+8174](https://rfc-editor.org/info/rfc8174), and they must be cited as described
+in the latter document. Please use the boilerplate text *exactly* as specified
+in [RFC 8174](https://rfc-editor.org/info/rfc8174).
+
+* [ ] If the I-D intends to obsolete or update existing RFCs, ensure there
+      is a "Summary of Changes" section.
+
+#### IPR-Related Notices 
+
+[BCP 78](https://www.rfc-editor.org/info/bcp78) and [BCP
+79](https://www.rfc-editor.org/info/bcp79) specify the IETF's Intellectual
+Property policies. Among them is a requirement to include certain standardized
+text in each Internet-Draft. This text is managed by the IAB, see the [current
+acceptable boilerplate
+texts](https://www.iab.org/documents/headers-boilerplate/) and the [fully
+expanded forms of the boilerplate
+texts](https://www.rfc-editor.org/materials/status-memos.txt).
+
+Authors preparing XML submissions indicate which boilerplate text to use by
+providing one of a set of enumerated values to the `ipr` attribute of the `rfc`
+element in the XML source. The tooling generates the actual required text. See
+Appendix A.1  in [RFC 7991](https://rfc-editor.org/info/rfc7991) for the
+available `ipr` attribute values. The majority of IETF stream I-Ds indicate
+`trust200902` or `pre5378Trust200902`, as needed.
+
+Authors preparing plaintext submissions must carefully reproduce the
+text most appropriate for their Internet-Draft.
+
+Authors of IETF stream documents must not select boilerplate that prohibits
+publication as an RFC.
+
+A standard Copyright Notice and Disclaimer must be included. This will be
+generated automatically for authors preparing XML submissions. Authors of
+plaintext submissions should refer to the [TLP Section
+6](https://trustee.ietf.org/documents/trust-legal-provisions/) for the exact
+text to reproduce.
+
+* [ ] Verify that one of the approved IPR boilerplate selections are
+      indicated in XML submissions or exactly reproduced in plaintext
+      submissions.
+
+* [ ] Verify that the most appropriate IPR boilerplate for the I-D is
+      indicated.
+
+Any Internet-Draft submitted that does not select one of the required IPR
+boilerplate statements will be rejected. The IETF Secretariat cannot add
+a selection for the author.
+
+##### Limiting Modifications and Derivative Works
+
+If the submitter of a non-IETF stream I-D desires to eliminate the IETF's
+right to make modifications and derivative works of the I-D, one of two
+notices must be included after the IPR statement.
+
+The first choice is used if the contributor intends for the I-D to be
+published as an RFC:
+
+> This document may not be modified, and derivative works of it may
+not be created, except to format it for publication as an RFC or
+to translate it into languages other than English.
+
+This will be automatically generated by the tools from XML source if the
+`ipr` attribute value `noModificationTrust200902` is selected.
+
+The second choice is used when the contributor does not intend for the I-D
+to be published as an RFC:
+
+> This document may not be modified, and derivative works of it may
+not be created, and it may not be published except as an
+Internet-Draft.
+
+This will be automatically generated by the tools from XML source if the
+`ipr` attribute value `noDerivativesTrust200902` is selected.
+
+These notices may not be used with any IETF Standards Track document or with
+most working group documents, except as discussed in [BCP
+78](https://www.rfc-editor.org/info/bcp78), since the IETF must retain change
+control over its documents and the ability to augment, clarify, and enhance the
+original contribution in accordance with the IETF Standards Process.
+
+The first choice may be appropriate when republishing standards produced by a
+standards body other than the IETF, industry consortia, or companies. These are
+typically published as Informational RFCs and do not require that change
+control be ceded to the IETF. Documents of this type convey information for the
+Internet community.
+
+The second choice may be used on I-Ds that are intended to provide background
+information to educate and to facilitate discussions within IETF working groups
+but are not intended to be published as RFCs.
+
+If you think that you, your company, or anyone else owns a patent or other
+Intellectual Property Rights (IPR) on the work described in the I-D, you should
+carefully read [BCP 79](https://www.rfc-editor.org/info/bcp79). The first notice
+required in an I-D, described earlier in this section, obligates you to send an
+IPR disclosure statement under certain circumstances. In particular, when
+preparing a document intended to be included in the IETF Stream, before
+submitting the I-D, discussing it with the working group chairs or Area
+Directors is advised.
+
+#### Abstract
+
+Every Internet-Draft must have an abstract. The abstract should provide a
+concise and comprehensive overview of the purpose and contents of the entire
+document. Its purpose is to give a technically knowledgeable reader a general
+overview of the function of the document, to decide whether reading it will be
+useful. In addition to its function in the document, the abstract is used as a
+summary in publication announcements and in the [online index of
+I-Ds](https://www.ietf.org/id/1id-abstracts.txt).
+
+Composing a useful abstract is a nontrivial writing task. Often, a
+satisfactory abstract can be constructed in part from material from the
+introduction section, but a good abstract will be shorter, less detailed, and
+broader in scope than the introduction. Simply copying and pasting the first
+few paragraphs of the introduction is tempting, but it generally results in an
+abstract that is both incomplete and redundant. An abstract will typically be
+five to ten lines. An abstract of more than 20 lines or fewer than three lines
+is generally not acceptable.
+
+* [ ] Ensure the Internet-Draft contains an appropriate abstract.
+
+An abstract should be complete in itself, so it should not contain citations
+unless they are completely defined within the abstract. Abbreviations appearing
+in the abstract should generally be expanded in parentheses. There is a set of
+reasonable exceptions to this rule; for example, readers don't need to be
+reminded of what "IP" or "TCP" or "MIB" means. The RFC Editor maintains a [list
+of approved
+abbreviations](https://www.rfc-editor.org/materials/abbrev.expansion.txt) that
+do not need to be expanded. In the end, this is a judgment call, but
+please err on the side of explicitness.
+
+* [ ] Verify that the abstract stands alone.
+* [ ] Ensure abbreviations in the abstract are expanded as appropriate.
+* [ ] If the I-D intends to obsolete or update a previous RFC, ensure the
+      abstract says so explicitly.
+
+The RFC Editor's [Style Guide](https://www.rfc-editor.org/styleguide/) includes
+further guidance about writing an abstract.
+
+#### Introduction
+
+* [ ] If the I-D intends to obsolete or update a previous RFC, ensure the
+      Introduction briefly explains what is being updated and why.
+
+#### Security Considerations
+
+[RFC 3552](https://rfc-editor.org/info/rfc3552) describes current best practices
+about writing a Security Considerations section. This section is mandatory in
+all documents.
+
+The text of this section must have a meaningful exploration of security issues
+raised by the proposal, which should include both risks and a description of
+solutions or workarounds. It is rare that technical work can legitimately make
+a claim like "This protocol introduces no security considerations," so it needs
+to be fairly obvious for that to be believable, or the document will be
+returned for further development. Procedural documents, however, more commonly
+can claim no added security risk.
+
+Some other references that may be useful when crafting this section are:
+
+* [Internet Security Glossary, Version 2](https://rfc-editor.org/info/rfc4949)
+* [Guidelines for Specifying the Use of IPsec Version
+  2](https://rfc-editor.org/info/rfc5406)
+* [Guidelines for Authors and Reviewers of MIB
+  Documents](https://rfc-editor.org/info/rfc4181)
+* [Security Guidelines for IETF MIB
+  Modules](https://trac.ietf.org/trac/ops/wiki/mib-security)
+* [YANG Security
+  Considerations](https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines)
+
+* [ ] Verify that a meaningful Security Consideration section is present.
+
+#### IANA Considerations
+
+This section must be present to enumerate any actions IANA must take upon
+publication of the document as an RFC.
+
+* [ ] Verify this section contains clear instructions if IANA is expected
+      to create a new registry or modify rules for an existing registry.
+
+* [ ] Verify this section contains clear instructions if the document
+      requires IANA to assign or update values in an IANA registry before
+      RFC publication.
+
+* [ ] Check the existing IANA registry for registration policy rules
+      and any requirements for specific requests for registration of
+      protocol parameters. Individual RFCs have specific criteria and
+      instructions that should be followed.
+
+* [ ] If the registration policy is "Expert Review" or "Specification
+      Required" and/or requires mailing list review, as soon as the
+      requested parameter information is properly formed, consider
+      initiating reviews with IANA or sending to the appropriate mailing
+      list (where applicable; see the RFC for that the registry for
+      instructions). If there are any questions about what type of approval
+      is needed from the Designated Expert (for example, if the registration
+      should be made immediately or only pre-reviewed before publication),
+      please contact IANA.
+
+* [ ] If registrations are needed early for registries with "Specification
+      Required", "RFC Required", "IETF Review", or "Standards Action" policies,
+      consider using the early allocation process defined in [RFC 7120](https://rfc-editor.org/info/rfc7120).
+
+* [ ] Verify this section explicitly and clearly identifies any references
+      to this document that should be added for any registrations and any
+      that should replace existing references.
+
+* [ ] If the document has considerable instructions for IANA actions, request
+      an early review of the document by IANA.
+
+* [ ] If there is no action for IANA, verify that this section explicitly says
+      “This document has no IANA actions.” It is often helpful for the IANA
+      Considerations section to remain in place upon publication as an RFC
+      even if there are no actions.
+
+For more specific guidelines regarding structure and content for writing IANA
+Considerations sections, please see [RFC
+8126](https://rfc-editor.org/info/rfc8126) and the IANA [Protocol Registration
+Procedures](https://www.iana.org/help/protocol-registration).
+
+#### Summary of Changes
+
+As noted in the abstract and introduction sections above, the abstract
+and introduction must call out any RFCs an I-D intends to obsolete
+or update. There should also be a section providing greater detail about
+the motivation and changes.
+
+* [ ] Ensure the I-D clearly summarizes any changes made from the RFCs
+      being updated or obsoleted.
+
+* [ ] Ensure any errata against RFCs that are being obsoleted or updated
+      have been considered, and that the I-D clearly identifies those that
+      have been addressed.
+
+#### References
+
+A references section must be present and split into normative and informative
+sections. For guidance, see the RFC Editor's [Style
+Guide](https://www.rfc-editor.org/styleguide/) and the [IESG Statement on
+Normative and Informative
+References](https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/).
+
+Normative and informative references to non-IETF documents are permitted.
+However, it is best to minimize such normative references, because assessing
+their status when the IETF document advances on the standards track is very
+difficult. It is important to use the exact title, author name(s), organization
+and publication date. External specifications referenced by
+Internet-Standard-level Technical Specifications or Applicability Statements
+must be to open external standards, per [RFC 2026](https://rfc-editor.org/info/rfc2026).
+
+* [ ] Ensure all needed references are present and correctly identified
+      as normative or informative.
+
+* [ ] Verify that references are stable and resolvable.
+
+A bare URI is not generally considered a stable reference. For web-only
+documents, adding a reference number, title , and/or an author will help make
+the reference more stable. See the RFC Editor's [Style
+Guide](https://www.rfc-editor.org/styleguide/) for specific guidance about URIs
+in Internet-Drafts. Judgment can be used here; the stability of normative
+references is even more important than the stability of informative references.
+
+Also note that normative references to I-Ds will cause the referencing document
+to wait in the RFC Editor queue for the referenced I-Ds to be published as RFCs.
+They may in some cases become a [cluster of
+documents](https://www.rfc-editor.org/about/clusters/) that will be published as
+RFCs simultaneously.
+
+#### Authors' Addresses
+
+* [ ] Verify that the I-D contains a section giving the name and contact
+      information (postal mail, phone, and/or email) for the authors.
+
+Note that if the I-D is eventually published as an RFC, this
+information will not be changeable. When possible, provide
+contact information that is expected to be stable over time.
+
+* [ ] Verify that there are no more than five authors or editors. If there
+      is a need to list more, discuss the need with the relevant stream
+      leadership as early in the process as possible. For the IETF stream,
+      consult an Area Director.
+
+Per [RFC 7322](https://rfc-editor.org/info/rfc7322):
+
+> The total number of authors or editors on the first page is generally
+limited to five individuals and their affiliations.  If there is a
+request for more than five authors, the stream-approving body needs
+to consider if one or two editors should have primary responsibility
+for this document, with the other individuals listed in the
+Contributors or Acknowledgements section.  There must be a direct
+correlation of authors and editors in the document header and the
+Authors' Addresses section.  These are the individuals that must sign
+off on the document during the AUTH48 process and respond to
+inquiries, such as errata.
+
+### Content Considerations
+
+#### Internet-Drafts Are Not RFCs
+
+* [ ] Verify that the I-D does not refer to itself as an RFC or a draft RFC.
+
+* [ ] Verify that the I-D neither states nor implies that it has any
+      standards-like status.
+
+To do so conflicts with the roles of the RFC Editor and the IESG. The title of
+the document should not imply a status. Avoid the use of the terms Standard,
+Proposed, Draft, Experimental, Historic, Required, Recommended, Elective, or
+Restricted in the I-D title. An I-D may indicate its intended status, if it were
+to be published as an RFC, by setting the `status` attribute of the `seriesInfo`
+XML element (see [RFC 7322](https://rfc-editor.org/info/rfc7322)) or by placing the
+words "Intended status: \<status\>" on the left side of the headers in the first
+page if preparing a plaintext submission.
+
+#### Use of BCP 14 Terms
+
+If [BCP 14](https://www.rfc-editor.org/info/bcp14) language (MUST, SHOULD, etc.)
+is used, the guidelines in [RFC 2119](https://rfc-editor.org/info/rfc2119),
+especially those in Sections 6 and 7, should be followed. SHOULD is especially
+problematic: it needs to be clear why SHOULD is used rather than MUST, and what
+the implications are of varying from the recommendation.
+
+#### Programing Languages
+
+When programming languages are used in Internet-Drafts, it is necessary to
+include as a reference the formal definition of that coding language (e.g., C87,
+C99, etc.).
+
+#### Formal Languages
+
+* [ ] Verify that any use of formal languages conforms with the [IESG statement
+      on the use of formal languages](https://www.ietf.org/about/groups/iesg/statements/formal-languages-use/).
+
+Some particular points to observe are enumerated below.
+
+##### MIB modules
+
+All MIB modules should have correct syntax, so they should compile cleanly
+using the `smilint` tool, e.g.:
+
+          smilint -m -s -l 6 -i namelength-32
+
+An [online service is available for MIB syntax
+checking](https://www.ibr.cs.tu-bs.de/projects/libsmi/tools/). This allows you
+to extract the MIB module from a document for your own local use, but you can
+also directly run a syntax check.
+
+You can also download the
+[`libsmi`](https://www.ibr.cs.tu-bs.de/projects/libsmi/tools/) tools for local
+use. In most cases, there should be no errors or warnings present in the report.
+Please evaluate all diagnostic messages before assuming that they are OK. If in
+doubt, feel free to check on the [ietfmibs mailing
+list](https://www.ietf.org/mailman/listinfo/IETFMIBS) or with the [OPS
+ADs](mailto:ops-ads@ietf.org).
+
+* [ ] Ensure that MIB modules compile cleanly
+
+* [ ] Verify that the I-D follows the guidelines in [RFC
+  4181](https://rfc-editor.org/info/rfc4181) as updated by [RFC
+  4841](https://www.rfc-editor.org/info/rfc4841).
+
+##### Augmented Backus-Naur Form (ABNF)
+
+* [ ] Ensure all Augmented Backus-Naur Form (ABNF) in the I-D compiles cleanly;
+  [a tool is available](https://tools.ietf.org/tools/bap/). See [RFC
+  5234](https://rfc-editor.org/info/rfc5234) for information about IETF ABNF.
+
+* [ ] If ABNF is used, ensure the I-D contains a normative reference to [RFC
+  5234](https://rfc-editor.org/info/rfc5234).
+
+##### XML
+
+Protocol specifications that use XML should always use well-formed XML at a
+minimum. Sample XML instances included in a specification have to be
+well-formed, and if the XML is supposed to be valid (according to the current
+W3C definition of validity), the samples must reference and be validated using
+an appropriate XML Schema, DTD, or another standard validation mechanism that
+is structurally and syntactically correct.
+
+Other guidelines for the use of XML in IETF protocols can be found in [RFC
+3470](https://rfc-editor.org/info/rfc3470).  Internet-Drafts that include an XML
+Schema should include a normative reference to either the W3C XML Schema
+Definition Language 1.1 [Part1](https://www.w3.org/TR/xmlschema11-1/) or [Part
+2](https://www.w3.org/TR/xmlschema11-2/) .
+
+* [ ] Verify that any XML in the I-D is well-formed, and if it is intended to
+      be valid, confirm that it validates against the appropriate definition.
+
+XML provides structures, such as the "`<any>`" element information item in XML
+Schema, to allow element extensions.
+
+* [ ] Ensure the I-D contains clear guidance on how, when, and where any
+      extension structures, such as versioning, can be used.
+
+* [ ] Check that any new or updated XML Schemas, Namespaces, and Resource
+  Description Framework (RDF) Schemas are being registered with IANA using the
+  procedures described in [RFC 3688](https://rfc-editor.org/info/rfc3688).
+
+##### YANG
+
+YANG (Yet Another Next Generation) is a data modeling language for data sent
+over network management protocols such as NETCONF and RESTCONF. Specifications
+that present a YANG module should test, review, and format them using [these tools
+and guidance](https://trac.ietf.org/trac/ops/wiki/yang-review-tools).
+
+Other useful references when considering inclusion of a YANG module include [RFC
+8340](https://rfc-editor.org/info/rfc8340), [RFC
+8407](https://rfc-editor.org/info/rfc8407), and the [YANG module security
+considerations](https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines).
+
+#### Example Addresses
+
+* [ ] Verify that examples use example FQDNs whenever possible.
+
+Addresses used in examples should use fully qualified domain names instead of
+literal IP addresses, and should use example FQDNs such as "foo.example.com"
+instead of real-world FQDNs. See [RFC 2606](https://rfc-editor.org/info/rfc2606)
+for example domain names that can be used. Note that the entire “.example” TLD
+is reserved, allowing for arbitrary subdomains (in particular, ones that are not
+considered same-origin on the Web.
+
+* [ ] Verify that literal IP addresses are from the example ranges.
+
+There are also ranges of IP addresses set aside for this purpose. For IPv4,
+these are defined in [RFC 6890](https://rfc-editor.org/info/rfc6890); for IPv6,
+see [RFC 3849](https://rfc-editor.org/info/rfc3849). Per the [IAB Statement on
+IPv6](https://www.iab.org/2016/11/07/iab-statement-on-ipv6), IPv6 examples
+should be used.
+
+* [ ] Verify that private addresses that would be used in the real world
+      are not used in examples.
+
+* [ ] Verify that real telephone numbers are not used in examples.
+
+Use those numbers that were reserved for examples or fictitious use.
+Available numbers for use in examples are:
+
+          UK: +44-<geographic-area-code>-496-<0000-0999>
+          USA: +1-<area code>-555-<0100-0199> 
+
+For USA examples, also see
+[ATIS-0300115](https://www.nationalnanpa.com/pdf/NRUF/ATIS-0300115.pdf).
+
+#### Stale Text
+
+Avoid text that will become outdated after the I-D is published. Examples
+include non-permanent URLs, mentions of specific mailing lists as places to send
+comments on a document, or referring to specific WGs as a place to perform
+specific future actions (e.g., reviewing follow-up documents). In some cases
+(like the `ORGANIZATION` clause in MIB modules), references to working groups
+are impossible to avoid; however, generally, Internet-Drafts should not assign
+powers or responsibilities to WGs unless the WG in question is certain to exist
+as long as the practice documented in the published RFC remains valid. In cases
+where a specific WG is expected to be a focal point for future action, it is
+acceptable to give the task to the IESG, giving instructions on how the action
+is expected to be delegated, e.g., by forwarding to an appropriate WG or another
+set of experts.
+
+* [ ] Check the I-D for text that could become stale. To the extent
+      possible, make it future-proof.
+
+#### Protocol Issues
+
+This section provides some general guidance that will help to avoid extended
+discussion during the document review and approval process. The IESG has
+compiled a [list of useful topics to
+consider](https://trac.ietf.org/trac/iesg/wiki/ExpertTopics).
+
+* [ ] Ensure the I-D avoids IPv4 specificity. Both IPv4 and IPv6 must be
+      supportable, unless the protocol is naturally IPv4 specific or IPv6
+      specific. Expect an IPv4-only protocol to be met with friction.
+
+* [ ] Ensure the I-D does not introduce congestion issues. No application can be
+  permitted to cause catastrophic congestion. See [RFC
+  2914](https://rfc-editor.org/info/rfc2914) for details. Applications using TCP
+  or SCTP will normally fulfill this requirement automatically. Applications
+  using UDP should adhere to the guidance in [RFC
+  8085](https://rfc-editor.org/info/rfc8085).
+
+* [ ] Verify that any sort of end-to-end checksum or integrity check being used
+      (especially, but not limited to, cryptographic checksums or MACs)
+      precisely specifies the contents of the fields to be checksummed, and in
+      exactly what order the operations are done. Pay special attention to any
+      area reserved for the checksum itself.
+
+* [ ] Verify that all user-visible text fields are internationalizable; see [RFC
+  2277](https://rfc-editor.org/info/rfc2277). For most cases, this means
+  [UTF-8](https://rfc-editor.org/info/rfc3629). But note that it is often not
+  sufficient to simply say that strings are encoded with UTF-8 (see below about
+  comparisons), especially when talking about case-(in)sensitivity, case
+  folding, and the like.
+
+* [ ] If text fields are included in some calculations, like matching, sorting,
+  etc., verify that how those operations are applied to the Unicode/ISO 10646
+  character set are described in detail. See
+  ["stringprep"](https://rfc-editor.org/info/rfc8264) for more information on
+  the recommended way of handling comparisons.
+
+#### Inclusive Language
+
+The IESG has made a
+[statement](https://www.ietf.org/about/groups/iesg/statements/on-inclusive-language/)
+recommending authors review [NISTIR 8366](https://doi.org/10.6028/NIST.IR.8366)
+for guidelines on using inclusive terminology.
+
+## Format
+
+Formatting is automatically handled when Internet-Drafts are submitted in
+XML form. Authors of such I-Ds have very few formatting issues to consider.
+The primary consideration is ensuring the tools are able to render the various
+formats. In particular, the content of the XML must be amenable to rendering
+with the 72 character per line restriction in the text format.
+
+Authors preparing Internet-Drafts in plain text must ensure the document
+conforms to many formatting rules.
+
+The format constraints for a plaintext I-D are primarily the same as those for
+the text format of an RFC as specified in [RFC
+7994](https://rfc-editor.org/info/rfc7994). One notable difference is that
+Internet-Drafts are paginated, and include running headers and footers. A few
+formatting requirements are highlighted here, but authors preparing plaintext
+documents should fully understand the requirements in [RFC
+7994](https://rfc-editor.org/info/rfc7994), [RFC
+7841](https://rfc-editor.org/info/rfc7841), [RFC
+7332](https://rfc-editor.org/info/rfc7332), [RFC
+7322](https://rfc-editor.org/info/rfc7322), the RFC Editor's [Style
+Guide](https://www.rfc-editor.org/styleguide/), and the [current acceptable
+boilerplate texts](https://www.iab.org/documents/headers-boilerplate/).
+
+The submission tool will block submission for many formatting errors and flag
+many others. The [`idnits` tool](https://tools.ietf.org/tools/idnits/) can be
+used to identify those so they can be corrected before submission.
+Well-formatted I-Ds tend to progress through the review process more quickly.
+When an I-D is approved for publication as an RFC, the RFC Editor can take care
+of a few small formatting errors. However, if many formatting errors exist, the
+document will be returned to the stream requesting publication for fixes. Please
+be aware that not conforming to the formatting rules will most probably delay
+publication and consume time that can be spent on other work.
+
+These are formatting requirements for plaintext I-Ds that often are
+overlooked:
+
+* [ ] Verify that the document name and version appears on the first page.
+
+* [ ] Verify that the I-D contains a "Table of Contents" section between
+      the "Copyright Notice" and the introduction. This section must not
+      be numbered.
+
+* [ ] Verify that no text extends beyond the 72nd column of a line. This
+      limit is especially important for diagrams, which the RFC
+      Editor may not be able to trivially reformat to fall within the
+      margins.
+
+* [ ] Verify that source code does not extend beyond the 69th column.
+
+* [ ] Verify that the text is ragged-right.
+
+* [ ] Verify that hyphenation is not used for line breaks. However,
+      hyphenated words (e.g., "Internet-Draft") may be split at the
+      hyphen across successive lines.
+
+* [ ] Verify that the I-D contains no footnotes.
+
+* [ ] Verify the characters in the I-D meet the requirements of [RFC
+  7994](https://rfc-editor.org/info/rfc7994). In brief, the document must be
+  UTF-8 encoded, but code points not corresponding to ASCII are allowed only in
+  certain contexts (see [RFC 7997](https://rfc-editor.org/info/rfc7997)).
+  Control characters other than `CR`, `NL`, and `FF` are not allowed. The use of
+  non-ASCII characters is limited to when there is a specific need, most notably
+  for names. Many uses of non-ASCII characters will require listing the Unicode
+  codepoint by number in addition to the character itself.
+
+* [ ] Verify that the "Status of This Memo" and "Abstract" sections are not
+      numbered.
+
+* [ ] Verify that the appropriate boilerplate text in the IPR-related sections
+  is reproduced exactly (see the [IPR-Related Notices
+  section](#ipr-related-notices)). In particular, ensure that the names of RFCs
+  contained in that content are not reformatted as references.
+
+* [ ] Verify that the I-D is well formatted for readability and clarity.
+
+* [ ] If the I-D has "Contributors" and/or "Acknowlegments" sections, verify
+  that the sections are unnumbered and placed after the "References" section and
+  any appendices. See Section 4 of [RFC
+  7322](https://rfc-editor.org/info/rfc7322).
+
+* [ ] Verify that references to Internet-Drafts and RFCs are formatted as shown
+  in the "web portion" of the RFC Editor's Style Guide (see
+  [here](https://www.rfc-editor.org/styleguide/part2/#ref_ids) for guidance on
+  I-Ds and [here](https://www.rfc-editor.org/part2/#ref_rfcs) for guidance on
+  RFCs). Note that these formats can change over time, so review these links
+  carefully with each document submission.
+
+## Acknowledgement
+
+This document is based heavily on the work of Russ Housley, Ben Kaduk,
+Murray Kucherawy, Alvaro Retana, and the members of many IESGs.
\ No newline at end of file
diff --git a/ietf-logo-300dpi-transparent-background.png b/ietf-logo-300dpi-transparent-background.png
new file mode 100644
index 0000000..f10a488
Binary files /dev/null and b/ietf-logo-300dpi-transparent-background.png differ
diff --git a/ietf-logo-reversed-300dpi-transparent-background.png b/ietf-logo-reversed-300dpi-transparent-background.png
new file mode 100644
index 0000000..af5de57
Binary files /dev/null and b/ietf-logo-reversed-300dpi-transparent-background.png differ
diff --git a/ietf-logo-reversed-square-300dpi-transparent-background.png b/ietf-logo-reversed-square-300dpi-transparent-background.png
new file mode 100644
index 0000000..1c51918
Binary files /dev/null and b/ietf-logo-reversed-square-300dpi-transparent-background.png differ
diff --git a/internet-draft-names.md b/internet-draft-names.md
new file mode 100644
index 0000000..816e5e2
--- /dev/null
+++ b/internet-draft-names.md
@@ -0,0 +1,65 @@
+---
+title: Internet-Draft names
+description: 
+published: true
+date: 2021-08-25T22:20:39.034Z
+tags: 
+editor: markdown
+dateCreated: 2021-08-16T22:51:45.856Z
+---
+
+Internet-Draft names appear inside the I-D, and are used as components of filenames for the various formats the I-D may appear in. The characters that may appear in an I-D name are restricted:
+
+* [ ] Ensure that the I-D name consists only of
+  * the lowercase letters `a-z`,
+  * the digits `0-9`,
+  * or hyphens (`-`).
+
+The name of an I-D consists of several components, separated by a hyphen. No empty components are allowed. That is, consecutive hyphens may not appear in an I-D name.
+
+The first component identifies the I-D as a draft (as opposed to other document types, such as a charter or a review).
+
+* [ ] Verify that the I-D name begins with `draft-`.
+
+The second component identifies the source of an I-D. If an I-D has been adopted into any stream other than the Independent Submission Stream, this component will identify the stream.
+
+If the I-D has not been adopted into any stream or if it is being considered for publication in the Independent Submission Stream, the second component should consist of a string related to the names(s) of the author(s). There are no mechanical rules for this string beyond consisting only of the allowed characters. However, objectionable or misleading strings are subject to change or removal. The string is typically the last name of the lead author or editor.
+
+The second component must not be easily confused with a group acronym. The following strings for the second component are reserved for their respective organizations (some of which are historic):
+
+* `iana`
+* `iaoc`
+* `iesg`
+* `ietf-trust`
+* `rfc-editor`
+
+The second component should not contain a hyphen. Legacy uses and edge cases such as hyphenated last names are allowed. Having a hyphen in the second component makes it hard to extract programmatically. This forces many tools to use heuristics when tying to locate the second component.
+
+* [ ] Ensure the second component reasonably identifies the source of the I-D.
+
+* [ ] If the I-D has been adopted by a stream, ensure the second component is:
+  * `ietf` for the IETF stream
+  * `irtf` for the IRTF stream
+  * `iab` for the IAB stream
+
+Otherwise, ensure that the second component is not a group acronym or a reserved string, is not objectionable, and does not introduce confusion.
+
+Note that any I-D submitted with one of these stream identifiers in the second component that has not been adopted by the indicated stream will either be rejected or replaced.
+
+If the I-D is targeted at or has been adopted by a group, the group's acronym should be added to the name just after the second component, separated by a hyphen.
+
+* [ ] Ensure an adopted or group-targeted I-D identifies the group just after the second component by including the group's acronym.
+
+Note again that if the I-D has not been adopted into a stream, and it identifies a stream in the second component, it will be rejected or replaced. In particular for IETF stream documents, the first version of an I-D with a name that begins with `draft-ietf-acronym-` for any working group acronym must be approved by the working group's chairs before it will be posted.
+
+The remainder of the name describes the purpose of the I-D, usually in just a few words. Each word is separated by a hyphen.
+
+* [ ] Ensure the name reasonably reflects the purpose of the I-D.
+
+Internet-Drafts are versioned with two digits, separated from the name with a hyphen. The initial version of an I-D must be `00`, and subsequent updates must increment the version number by one.
+
+If the I-D is submitted as XML (which is highly recommended), the name and version of the document will be declared in the appropriate ["name" and "version" attributes](https://rfc-editor.org/info/rfc7991), and the filename submitted must be of the form `name-version.xml`.
+
+If the I-D is submitted as plain text (which is not recommended), the name and version will appear on the document's first page, and the filename submitted must be of the form `name-version.txt`.
+
+Convention dictates that an individual submission seeking adoption by a working group will include the working group's acronym just after the second component. For example, a person or group identified as "foo" seeking to get a document about "specific-subject" adopted by the "bar" working group might choose the name `draft-foo-bar-specific-subject`, and submit the file `draft-foo-bar-specific-subject-00.xml`. If the document is later adopted by the working group, the authors will usually create a new I-D named `draft-ietf-bar-specific-subject` and submit it as `draft-ietf-bar-specific-subject-00.xml`. Note that the version number of this new I-D will always be `00`.
\ No newline at end of file
diff --git a/internet-draft-repository.md b/internet-draft-repository.md
new file mode 100644
index 0000000..8505de8
--- /dev/null
+++ b/internet-draft-repository.md
@@ -0,0 +1,24 @@
+---
+title: Internet-Draft repository and archive
+description: 
+published: true
+date: 2021-08-26T20:41:05.437Z
+tags: 
+editor: markdown
+dateCreated: 2021-08-19T03:42:42.411Z
+---
+
+All versions of Internet-Drafts are kept in the [Internet-Draft Archive](https://www.ietf.org/archive/id). Active versions of Internet-Drafts are also placed in the [Internet-Draft Repository](https://www.ietf.org/id).
+
+Versions of Internet-Drafts are removed from the Repository when any of the following occur:
+
+* The I-D is updated with a new version.
+* The I-D is replaced by another Internet-Draft.
+* The I-D is published as an RFC.
+* The I-D expires.
+
+An I-D expires 185 days after it was placed in the Repository, unless it is in a state that prevents it from expiring. Examples of such states include being processed by the IESG for publication in the IETF stream, or being under review by the Independent Series Editor (ISE) for publication in the [Independent Submission Stream](https://www.rfc-editor.org/about/independent/).
+
+Internet-Drafts are not removed from the Archive when they are removed from the Repository. Removing an I-D from the Archive occurs only in exceptional circumstances, described in [this IESG Statement](https://www.ietf.org/about/groups/iesg/statements/internet-draft-removal/).
+
+Even though Internet-Drafts are kept in the Archive, they are not an archival series and should not be cited or quoted as anything other than "work in progress".
\ No newline at end of file
diff --git a/introducing-internet-drafts.md b/introducing-internet-drafts.md
new file mode 100644
index 0000000..e7d4e51
--- /dev/null
+++ b/introducing-internet-drafts.md
@@ -0,0 +1,30 @@
+---
+title: Introducing Internet-Drafts
+description: 
+published: true
+date: 2021-08-19T10:35:23.633Z
+tags: 
+editor: markdown
+dateCreated: 2021-08-16T22:46:06.973Z
+---
+
+Internet-Drafts (I-Ds) are the basic work items of the IETF. They are the primary inputs into what may eventually be published as a Request for Comment (RFC).
+
+Internet-Drafts are used by all of the [RFC Streams](https://rfc-editor.org/info/rfc8729). The guidance in this document applies to all streams unless it is identified as specific to a particular stream.
+
+Internet-Drafts are prepared by people acting in possibly several roles, such as an author or an editor. This guidance uses the term "author", but the guidance applies to people acting in any role.
+
+This document collects and summarizes requirements and guidance from many sources. The following resources should be consulted for definitive details:
+
+* The IETF Standards Process is described in [RFC 2026](https://www.rfc-editor.org/info/rfc2026).
+* The IETF rules concerning copyright are described in [BCP 78](https://www.rfc-editor.org/info/bcp78).
+* The IETF rules on IPR are described in [BCP 79](https://www.rfc-editor.org/info/bcp79).
+* The IETF [Trust Legal Provisions Relating to IETF Documents](https://trustee.ietf.org/documents/trust-legal-provisions/), called "the TLP" for short, provides many details about copyright policy and practice.
+
+Much of the guidance in this document is in the form of something that can be inspected, or checked, to see whether changes should be made before submitting an I-D. These items are marked with checkboxes ([ ]). However, authors are expected to be familiar with and to apply the full guidance in this document.
+
+There are tools to help with the creation of Internet-Drafts. Rather than attempting to construct a plaintext Internet-Draft manually, it is highly recommended using a structured language for authoring, and a toolchain like [xml2rfc](https://pypi.org/project/xml2rfc/) or [kramdown-rfc2629](https://github.com/cabo/kramdown-rfc2629) to build a submission.
+
+An [online converter](https://xml2rfc.tools.ietf.org/experimental.html) for documents in the [xml2rfc](https://pypi.org/project/xml2rfc/) or [kramdown-rfc2629](https://github.com/cabo/kramdown-rfc2629) input formats is available. Authors working with the xml2rfc XML source format should be familiar with [the XML grammar](https://rfc-editor.org/info/rfc7991) [that the xml2rfc tool currently accepts](https://xml2rfc.tools.ietf.org/xml2rfc-doc.html), and the [RFC Editor's FAQ on using the v3 XML format](https://www.rfc-editor.org/materials/FAQ-xml2rfcv3.html).
+
+As Internet-Drafts may be eventually published as RFCs, it is recommended to consult the [RFC Editor's publication process](https://www.rfc-editor.org/pubprocess/).
\ No newline at end of file
diff --git a/miscellaneous-tools.md b/miscellaneous-tools.md
new file mode 100644
index 0000000..0861ae5
--- /dev/null
+++ b/miscellaneous-tools.md
@@ -0,0 +1,26 @@
+---
+title: Miscellaneous tools
+description: 
+published: true
+date: 2021-09-02T02:31:09.171Z
+tags: 
+editor: markdown
+dateCreated: 2021-08-18T07:41:10.639Z
+---
+
+There are a number of miscellaneous tools that authors may find useful:
+
+- **[ietf-cli](https://trac.tools.ietf.org/tools/ietf-cli/)**
+A multi-functional command line tool for manipulating I-Ds and RFCs and local repositories.
+
+- **[print_rfc_or_draft](https://www.kumari.net/index.php/programming/programmingcat/45-printrfcordraft)**
+A simple program that prints an Internet Draft (ID) or RFC. Because of the difference between the number of lines on laser printers and line / dot-matrix printers, each "page" of the draft actually takes up 2 pages and you end up with lots of pages with just a one line footer. This script tries to fix that by downloading the draft, converting it to a PDF and then printing it.
+
+- **[Rewrite IETF ID URLs to Tools or Datatracker](https://chrome.google.com/webstore/detail/rewrite-ietf-id-urls-to-t/aiccdpabeagpjcebilebhlifplfkinao)**
+Google Chrome extension that rewrites I-D URLs that point to www.ietf.org to point to datatracker.ietf.org or tools.ietf.org. 
+
+- **[RFC-what-I-mean](https://www.strayalpha.com/tools/)**
+Checks a list of RFCs to find the most recent list and their dependents. It needs to run with a copy of rfc-index.txt as input.
+
+- **[rfc-mode](https://github.com/galdor/rfc-mode)**
+A plugin Emacs major mode that provides support for reading RFCs.
diff --git a/rendering-and-converting.md b/rendering-and-converting.md
new file mode 100644
index 0000000..a0d9f6a
--- /dev/null
+++ b/rendering-and-converting.md
@@ -0,0 +1,30 @@
+---
+title: Rendering and converting
+description: 
+published: true
+date: 2021-10-10T22:17:20.755Z
+tags: 
+editor: markdown
+dateCreated: 2021-09-02T02:05:52.949Z
+---
+
+It is common for authors to render their documents into a different format to make them easier to read, or to convert to another format for use in another tool. The table below shows the conversion options from the two supported source formats of RFC XML and Plain Text into other formats.  If you want to convert from a different source format then hyou should first convert to one of these two formats and then refer to this table.
+
+| Output     | Input ||
+|            | RFC XML | Plain Text |
+| ---------- | :-----: | :--------: |
+| **RFC XML**    | - | id2xml |
+| **Plain Text** | [xml2rfc]() _or_ [rfc2629.xslt](https://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html) | - |
+| **HTML**       | [xml2rfc]() _or_ [rfc2629.xslt](https://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html) | [xml2rfc]() _or_ [rfcmarkup](https://tools.ietf.org/tools/rfcmarkup/) |
+| **HTMLised**<sup>1</sup>   | [xml2rfc]() | [xml2rfc]() |
+| **PDF**        | [xml2rfc]() _or_ [rfc2629.xslt](https://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html) | [xml2rfc]() |
+| **EPUB**       | [xml2rfc]() _or_ [rfc2629.xslt](https://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html) | [xml2rfc]() |
+| **Nroff**      | [xml2rfc]() | [xml2rfc]() |
+| **CHM**<sup>2</sup>        | [rfc2629.xslt](https://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html) | - |
+| **DOCX**       | [xml2docx](https://github.com/evyncke/xml2docx) | - |
+
+Notes:
+<sup>1</sup> **HTMLised** is the plain text version with an HTML wrapper and the references and table of contents turned into links.
+<sup>2</sup> **CHM** is Microsoft's Compiled Help Module.
+
+
diff --git a/required-content.md b/required-content.md
new file mode 100644
index 0000000..564a4d5
--- /dev/null
+++ b/required-content.md
@@ -0,0 +1,173 @@
+---
+title: Required Content
+description: 
+published: true
+date: 2021-08-19T10:35:51.639Z
+tags: 
+editor: markdown
+dateCreated: 2021-08-16T23:20:42.916Z
+---
+
+Internet-Drafts and RFCs have certain required content. I-Ds should take the accrued knowledge on frequent and particularly important topics into consideration as early in their life cycle as possible.
+
+If an Internet-Draft is prepared in XML, the tooling will ensure that required content is present, automatically provide selected boilerplate text, and handle the majority of formatting concerns. An Internet-Draft prepared as plain text requires more effort to ensure that the required content is present and in the right form.
+
+As Internet-Drafts are inputs into what might eventually be published as RFCs, their content requirements are based on what is required in an RFC. Specifically, many of the documents defining these requirements are written in terms of RFCs and do not mention Internet-Drafts, but these requirements, with very few exceptions, apply to Internet-Drafts. See [RFC 7841](https://rfc-editor.org/info/rfc7841) for specific details.
+
+* [ ] Ensure that the I-D correctly provides the following:
+  * The date the document was generated.
+  * A list of authors/editors and their affiliations.
+  * The group that originated the I-D (if any).
+  * The intended status of the document.
+  * The set of RFCs this I-D intends to update or replace, if any.
+
+These required elements are represented explicitly in XML source. The tools will automatically format the information when building a presentation format. The format required for these items in plaintext submissions is discussed in the [Format section](#format) below.
+
+* [ ] Ensure that the I-D contains each of the following sections:
+  * IPR-Related Notices
+  * Abstract
+  * Introduction
+  * Security Considerations
+  * IANA Considerations
+  * References
+  * Authors' Addresses
+
+* [ ] If the document uses [BCP 14](https://www.rfc-editor.org/info/bcp14) normative language, ensure the unchanged boilerplate text from [BCP 14](https://www.rfc-editor.org/info/bcp14) is present in the I-D, and that [BCP 14](https://www.rfc-editor.org/info/bcp14) is normatively referenced.
+
+Note that [BCP 14](https://www.rfc-editor.org/info/bcp14) is made up of both [RFC 2119](https://rfc-editor.org/info/rfc2119) and [RFC 8174](https://rfc-editor.org/info/rfc8174), and they must be cited as described in the latter document. Please use the boilerplate text *exactly* as specified in [RFC 8174](https://rfc-editor.org/info/rfc8174).
+
+* [ ] If the I-D intends to obsolete or update existing RFCs, ensure there is a "Summary of Changes" section.
+
+#### IPR-Related Notices 
+
+[BCP 78](https://www.rfc-editor.org/info/bcp78) and [BCP 79](https://www.rfc-editor.org/info/bcp79) specify the IETF's Intellectual Property policies. Among them is a requirement to include certain standardized text in each Internet-Draft. This text is managed by the IAB, see the [current acceptable boilerplate texts](https://www.iab.org/documents/headers-boilerplate/) and the [fully expanded forms of the boilerplate texts](https://www.rfc-editor.org/materials/status-memos.txt).
+
+Authors preparing XML submissions indicate which boilerplate text to use by providing one of a set of enumerated values to the `ipr` attribute of the `rfc` element in the XML source. The tooling generates the actual required text. See Appendix A.1  in [RFC 7991](https://rfc-editor.org/info/rfc7991) for the available `ipr` attribute values. The majority of IETF stream I-Ds indicate `trust200902` or `pre5378Trust200902`, as needed.
+
+Authors preparing plaintext submissions must carefully reproduce the text most appropriate for their Internet-Draft.
+
+Authors of IETF stream documents must not select boilerplate that prohibits publication as an RFC.
+
+A standard Copyright Notice and Disclaimer must be included. This will be generated automatically for authors preparing XML submissions. Authors of plaintext submissions should refer to the [TLP Section 6](https://trustee.ietf.org/documents/trust-legal-provisions/) for the exact text to reproduce.
+
+* [ ] Verify that one of the approved IPR boilerplate selections are indicated in XML submissions or exactly reproduced in plaintext submissions.
+
+* [ ] Verify that the most appropriate IPR boilerplate for the I-D is indicated.
+
+Any Internet-Draft submitted that does not select one of the required IPR boilerplate statements will be rejected. The IETF Secretariat cannot add a selection for the author.
+
+##### Limiting Modifications and Derivative Works
+
+If the submitter of a non-IETF stream I-D desires to eliminate the IETF's right to make modifications and derivative works of the I-D, one of two notices must be included after the IPR statement.
+
+The first choice is used if the contributor intends for the I-D to be published as an RFC:
+
+> This document may not be modified, and derivative works of it may not be created, except to format it for publication as an RFC or to translate it into languages other than English.
+
+This will be automatically generated by the tools from XML source if the `ipr` attribute value `noModificationTrust200902` is selected.
+
+The second choice is used when the contributor does not intend for the I-D to be published as an RFC:
+
+> This document may not be modified, and derivative works of it may not be created, and it may not be published except as an Internet-Draft.
+
+This will be automatically generated by the tools from XML source if the `ipr` attribute value `noDerivativesTrust200902` is selected.
+
+These notices may not be used with any IETF Standards Track document or with most working group documents, except as discussed in [BCP 78](https://www.rfc-editor.org/info/bcp78), since the IETF must retain change control over its documents and the ability to augment, clarify, and enhance the original contribution in accordance with the IETF Standards Process.
+
+The first choice may be appropriate when republishing standards produced by a standards body other than the IETF, industry consortia, or companies. These are typically published as Informational RFCs and do not require that change control be ceded to the IETF. Documents of this type convey information for the Internet community.
+
+The second choice may be used on I-Ds that are intended to provide background information to educate and to facilitate discussions within IETF working groups but are not intended to be published as RFCs.
+
+If you think that you, your company, or anyone else owns a patent or other Intellectual Property Rights (IPR) on the work described in the I-D, you should carefully read [BCP 79](https://www.rfc-editor.org/info/bcp79). The first notice required in an I-D, described earlier in this section, obligates you to send an IPR disclosure statement under certain circumstances. In particular, when preparing a document intended to be included in the IETF Stream, before submitting the I-D, discussing it with the working group chairs or Area Directors is advised.
+
+#### Abstract
+
+Every Internet-Draft must have an abstract. The abstract should provide a concise and comprehensive overview of the purpose and contents of the entire document. Its purpose is to give a technically knowledgeable reader a general overview of the function of the document, to decide whether reading it will be useful. In addition to its function in the document, the abstract is used as a summary in publication announcements and in the [online index of I-Ds](https://www.ietf.org/id/1id-abstracts.txt).
+
+Composing a useful abstract is a nontrivial writing task. Often, a satisfactory abstract can be constructed in part from material from the introduction section, but a good abstract will be shorter, less detailed, and broader in scope than the introduction. Simply copying and pasting the first few paragraphs of the introduction is tempting, but it generally results in an abstract that is both incomplete and redundant. An abstract will typically be five to ten lines. An abstract of more than 20 lines or fewer than three lines is generally not acceptable.
+
+* [ ] Ensure the Internet-Draft contains an appropriate abstract.
+
+An abstract should be complete in itself, so it should not contain citations unless they are completely defined within the abstract. Abbreviations appearing in the abstract should generally be expanded in parentheses. There is a set of reasonable exceptions to this rule; for example, readers don't need to be reminded of what "IP" or "TCP" or "MIB" means. The RFC Editor maintains a [list of approved abbreviations](https://www.rfc-editor.org/materials/abbrev.expansion.txt) that do not need to be expanded. In the end, this is a judgment call, but please err on the side of explicitness.
+
+* [ ] Verify that the abstract stands alone.
+* [ ] Ensure abbreviations in the abstract are expanded as appropriate.
+* [ ] If the I-D intends to obsolete or update a previous RFC, ensure the abstract says so explicitly.
+
+The RFC Editor's [Style Guide](https://www.rfc-editor.org/styleguide/) includes further guidance about writing an abstract.
+
+#### Introduction
+
+* [ ] If the I-D intends to obsolete or update a previous RFC, ensure the Introduction briefly explains what is being updated and why.
+
+#### Security Considerations
+
+[RFC 3552](https://rfc-editor.org/info/rfc3552) describes current best practices about writing a Security Considerations section. This section is mandatory in all documents.
+
+The text of this section must have a meaningful exploration of security issues raised by the proposal, which should include both risks and a description of solutions or workarounds. It is rare that technical work can legitimately make a claim like "This protocol introduces no security considerations," so it needs to be fairly obvious for that to be believable, or the document will be returned for further development. Procedural documents, however, more commonly can claim no added security risk.
+
+Some other references that may be useful when crafting this section are:
+
+* [Internet Security Glossary, Version 2](https://rfc-editor.org/info/rfc4949)
+* [Guidelines for Specifying the Use of IPsec Version 2](https://rfc-editor.org/info/rfc5406)
+* [Guidelines for Authors and Reviewers of MIB Documents](https://rfc-editor.org/info/rfc4181)
+* [Security Guidelines for IETF MIB Modules](https://trac.ietf.org/trac/ops/wiki/mib-security)
+* [YANG Security Considerations](https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines)
+
+* [ ] Verify that a meaningful Security Consideration section is present.
+
+#### IANA Considerations
+
+This section must be present to enumerate any actions IANA must take upon publication of the document as an RFC.
+
+* [ ] Verify this section contains clear instructions if IANA is expected to create a new registry or modify rules for an existing registry.
+
+* [ ] Verify this section contains clear instructions if the document requires IANA to assign or update values in an IANA registry before RFC publication.
+
+* [ ] Check the existing IANA registry for registration policy rules and any requirements for specific requests for registration of protocol parameters. Individual RFCs have specific criteria and instructions that should be followed.
+
+* [ ] If the registration policy is "Expert Review" or "Specification Required" and/or requires mailing list review, as soon as the requested parameter information is properly formed, consider initiating reviews with IANA or sending to the appropriate mailing list (where applicable; see the RFC for that the registry for instructions). If there are any questions about what type of approval is needed from the Designated Expert (for example, if the registration should be made immediately or only pre-reviewed before publication), please contact IANA.
+
+* [ ] If registrations are needed early for registries with "Specification Required", "RFC Required", "IETF Review", or "Standards Action" policies, consider using the early allocation process defined in [RFC 7120](https://rfc-editor.org/info/rfc7120).
+
+* [ ] Verify this section explicitly and clearly identifies any references to this document that should be added for any registrations and any that should replace existing references.
+
+* [ ] If the document has considerable instructions for IANA actions, request an early review of the document by IANA.
+
+* [ ] If there is no action for IANA, verify that this section explicitly says “This document has no IANA actions.” It is often helpful for the IANA Considerations section to remain in place upon publication as an RFC even if there are no actions.
+
+For more specific guidelines regarding structure and content for writing IANA Considerations sections, please see [RFC 8126](https://rfc-editor.org/info/rfc8126) and the IANA [Protocol Registration Procedures](https://www.iana.org/help/protocol-registration).
+
+#### Summary of Changes
+
+As noted in the abstract and introduction sections above, the abstract and introduction must call out any RFCs an I-D intends to obsolete or update. There should also be a section providing greater detail about the motivation and changes.
+
+* [ ] Ensure the I-D clearly summarizes any changes made from the RFCs being updated or obsoleted.
+
+* [ ] Ensure any errata against RFCs that are being obsoleted or updated have been considered, and that the I-D clearly identifies those that have been addressed.
+
+#### References
+
+A references section must be present and split into normative and informative sections. For guidance, see the RFC Editor's [Style Guide](https://www.rfc-editor.org/styleguide/) and the [IESG Statement on Normative and Informative References](https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/).
+
+Normative and informative references to non-IETF documents are permitted. However, it is best to minimize such normative references, because assessing their status when the IETF document advances on the standards track is very difficult. It is important to use the exact title, author name(s), organization and publication date. External specifications referenced by Internet-Standard-level Technical Specifications or Applicability Statements must be to open external standards, per [RFC 2026](https://rfc-editor.org/info/rfc2026).
+
+* [ ] Ensure all needed references are present and correctly identified as normative or informative.
+
+* [ ] Verify that references are stable and resolvable.
+
+A bare URI is not generally considered a stable reference. For web-only documents, adding a reference number, title , and/or an author will help make the reference more stable. See the RFC Editor's [Style Guide](https://www.rfc-editor.org/styleguide/) for specific guidance about URIs in Internet-Drafts. Judgment can be used here; the stability of normative references is even more important than the stability of informative references.
+
+Also note that normative references to I-Ds will cause the referencing document to wait in the RFC Editor queue for the referenced I-Ds to be published as RFCs. They may in some cases become a [cluster of documents](https://www.rfc-editor.org/about/clusters/) that will be published as RFCs simultaneously.
+
+#### Authors' Addresses
+
+* [ ] Verify that the I-D contains a section giving the name and contact information (postal mail, phone, and/or email) for the authors.
+
+Note that if the I-D is eventually published as an RFC, this information will not be changeable. When possible, provide contact information that is expected to be stable over time.
+
+* [ ] Verify that there are no more than five authors or editors. If there is a need to list more, discuss the need with the relevant stream leadership as early in the process as possible. For the IETF stream, consult an Area Director.
+
+Per [RFC 7322](https://rfc-editor.org/info/rfc7322):
+
+> The total number of authors or editors on the first page is generally limited to five individuals and their affiliations.  If there is a request for more than five authors, the stream-approving body needs to consider if one or two editors should have primary responsibility for this document, with the other individuals listed in the Contributors or Acknowledgements section.  There must be a direct correlation of authors and editors in the document header and the Authors' Addresses section.  These are the individuals that must sign off on the document during the AUTH48 process and respond to inquiries, such as errata.
\ No newline at end of file
diff --git a/submission-process.md b/submission-process.md
new file mode 100644
index 0000000..aea322f
--- /dev/null
+++ b/submission-process.md
@@ -0,0 +1,31 @@
+---
+title: Submission process
+description: 
+published: true
+date: 2021-08-19T10:33:41.770Z
+tags: 
+editor: markdown
+dateCreated: 2021-08-16T23:02:57.910Z
+---
+
+Internet-Draft submissions are made using the [IETF Datatracker's submission tool](https://datatracker.ietf.org/submit). An I-D submission should preferably be an [xml2rfc version 3](https://rfc-editor.org/info/rfc7991) XML source file, but a [version 2 source](https://rfc-editor.org/info/rfc7749) will be accepted. If an XML source is not available, a plaintext submission will be accepted.
+
+Currently, the submission tool will accept both an XML and plaintext submission, as well as PDF and PostScript versions of the document. In such submissions, the XML is authoritative, if present, otherwise the plain text is authoritative. It is expected that the tool will change to allow only the submission of XML or plain text, but not both, and to not accept other formats.
+
+**In short: submit XML if at all possible, with v3 preferred over v2.**
+
+If XML source is submitted, the Datatracker will generate a plain text version of the I-D and place it in the Archive. If v3 source is submitted, the Datatracker will also generate an HTML version and place it in the Archive.
+
+When a submission is made through the submission tool, the authors will receive email with a request to verify the submission. The submission will not be accepted and posted until the action requested in that email is performed. If the submitter is logged into the Datatracker and listed as an author this step is bypassed.
+
+If the I-D being submitted replaces another I-D (such as in the earlier example discussing creating a new I-D when a working group adopts a document), the submitter will be able to identify the replacement using the submission tool. A group chair or the IETF Secretariat will verify the replacement before the relationship is added to the Datatracker.
+
+The submission tool will double-check many, but not all, of the guidance points called out in this document. Authors are expected to have manually applied the guidance before submission.
+
+While many of the requirements highlighted by this document are for RFCs, Internet-Drafts are expected to adhere to them to the extent possible. In particular, IETF stream I-Ds submitted to the IESG must follow all of the guidance. Working groups are encouraged to require the guidance be followed for I-Ds entering Working Group Last Call. I-Ds will progress through the review and publication process more efficiently the earlier the guidance is followed in the I-D.
+
+## Manual submissions
+
+If authors are unable to submit an I-D through the Datatracker, they may make a manual-post request by sending the I-D via email to support@ietf.org. The message may contain the I-D as an attachment, or a URL that will resolve to the I-D. The I-D must be a standalone document in either XML or plaintext format. Multiple files presented in containers such as zip or tar will not be accepted. All other formats will be discarded without opening.
+
+Be aware of the deadlines for submitting I-Ds before each IETF Meeting. The [important dates page](https://datatracker.ietf.org/meeting/important-dates) will show the deadline for submitting I-Ds. Some meetings may have an earlier deadline for initial versions of I-Ds than for updates to existing I-Ds. After the deadlines, submissions will not be accepted until the meeting begins. The leadership responsible for each stream can override this submission blackout period when appropriate. Care should be taken when submitting an I-D near the deadline, especially if a manual post is requested. The steps to confirm and post the submission take time.
diff --git a/tools-catalog.md b/tools-catalog.md
new file mode 100644
index 0000000..068bbda
--- /dev/null
+++ b/tools-catalog.md
@@ -0,0 +1,116 @@
+---
+title: Tools catalog
+description: 
+published: true
+date: 2021-08-20T11:25:26.126Z
+tags: 
+editor: markdown
+dateCreated: 2021-08-17T00:37:22.495Z
+---
+
+The catalog tables below provide the following details for each tool:
+- **Basic** - name and description
+- **Features** - modes, operations, input formats and output formats 
+- **Status** - author, ownership, licensing, maintenance status, maintainer
+
+### Modes
+The tools generally support one or more of the following modes of operation:
+
+- Interactive **Editor** 
+- Command Line Interface (**CLI**).  Where the author installs the tools locally and then runs them on local files from the command line, one operation at a time.
+- Automated **Build** process. Where the author(s) installs the tools into a build manager that then runs a sequence of tools on a source target.  This allows for a continuous integrated build process much as software developers use when building code. 
+- **Web** service. This can be broken down into two sub-modes:
+    - Where the author uses an interactive web page that in turns calls a remote web service, on individual local files generally one operation at the time.
+    - Where the author(s) configures their build service to use a remote web service via an API instead of installing the tools. 
+
+### Operations
+The tools generally provide one of more of the following broad operations:
+
+-  **Convert** the document from one format to another such as from XML to PDF.
+-  **Validate** that the format/structure of the document source conforms to the format/structure rules for an I-D/RFC.
+-  **Extract** part of the document. For example, extracting a code module such as YANG, MIB or ABNF and passing it to a separate validator. 
+-  **Insert** new text into an I-D. This may be boilerplate, references, new sections or other custom text.
+-  **Compare** two different I-Ds or two versions of an I-D.
+-  Supports an interactive **Editor** with features such as auto-completion.
+
+### Formats
+The formats that we are aware of tools supporting include: AsciiDoc, DOCX, EPUB, LaTeX, Markdown, nroff, Org Mode, PDF, Plain Text, RFC XML v2, RFC XML v3
+
+## Catalog
+
+### Tables {.tabset}
+#### Basic
+
+| Tool | Description |
+| :--- | :---------- |
+| bibtext2rfc |
+| Bill's ABNF parser |
+| id2xml |
+| idnits |
+| idspell |
+| kramdown-rfc2629 |
+| lyx2rfc |
+| metanorma-ietf |
+| pyang |
+| rfcdiff |
+| SMICng |
+| smilint |
+| svgcheck |
+| xml2rfc |
+| xml2rfc-xxe |
+| xym |
+| YANG validator |
+| yanglint |
+| **bibxml2md** | Converts bibxml references into markdown | 
+| **nroff2xml** | Converts nroff I-D sources into xml2rfc format (xml) | 
+
+#### Features
+
+| Tool | Modes | Operations | Input formats | Output formats |
+| :--- | :---- | :------------ | :------------ | :------------- |
+| bibtext2rfc |
+| Bill's ABNF parser |
+| id2xml |
+| idnits |
+| idspell |
+| kramdown-rfc2629 |
+| lyx2rfc |
+| metanorma-ietf |
+| pyang |
+| rfcdiff |
+| SMICng |
+| smilint |
+| svgcheck |
+| xml2rfc |
+| xml2rfc-xxe |
+| xym |
+| YANG validator |
+| yanglint |
+| **bibxml2md** | Build, CLI | Convert | BibXML | XML |
+| **nroff2xml** | Build, CLI | Convert | nroff | XML |
+
+#### Status
+
+| Tool | Author | Ownership | License | Repository | Maintained | Maintainer |
+| :--- | :----- | :-------- | :------ | :--------- | :--------- | :--------- |
+| bibtext2rfc |
+| Bill's ABNF parser |
+| id2xml |
+| idnits |
+| idspell |
+| kramdown-rfc2629 |
+| lyx2rfc |
+| metanorma-ietf |
+| pyang |
+| rfcdiff |
+| SMICng |
+| smilint |
+| svgcheck |
+| xml2rfc |
+| xml2rfc-xxe |
+| xym |
+| YANG validator |
+| yanglint |
+| **bibxml2md** | Yaron Sheffer | None | None | [GitHub](https://github.com/yaronf/bibxml2md) | Yes | Yaron Sheffer |
+| **nroff2xml** | Tomek Mrugalski | IETF Trust | Simplified BSD | [GitHub](https://github.com/tomaszmrugalski/nroff2xml) | No | None |
+