= IETF Operations & Management (OPS) Area Home Page = == Getting Started == The Ops area aims to be very friendly. We don't always succeed, but we try to make newcomers feel welcome. We've started an [wiki:OpsBooks Ops reading / book recommendation list] here. These are just a set of books that we'd found interesting / useful, and figured that you might enjoy too... == Office Hours == Warren Kumari and Rob Wilton hold irregular on-line office hours. The schedule is posted at the URL below: * [wiki:OfficeHours Office Hours] == Hot Topics / Tips == The below are some things to consider and keep in mind while writing Internet Drafts, both in the Operations and Management area, but also in the IETF in general. There are many ways to shoot yourself in the foot when writing an Internet Draft - here are some of the ways that the current AD has seen this happen and / or things which it is worth keeping in mind. Note that these are just the personal views and advice from the current OpsAD - it is far from complete, feel free to send me additional pointers / ways which you've seen people trip over operational bits. RFC 5706 Appendix A. - "Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions" (https://tools.ietf.org/html/rfc5706) contains a checklist which is also very helpful. === DNS === DNS is core plumbing, and as such it is one of the obvious tools in the protocol designer's toolbox. There are, however, a number of dangers here. These include: - Trying to use a name in the "rightmost" (TLD) part of the name - this is almost definitely doing to end poorly for you. For a small subset of issues with this see: - RFC 8244 - Special-Use Domain Names Problem Statement - RFC6761 - Special-Use Domain Names - IAB statement on the registration of special use names in the ARPA domain - Guidelines for Use of the Special Use Names Registry ("work in progress.") - Assuming that the "reverse DNS" tree (in-addr.arpa) is complete and / or up to date and / or reflects reality. Periodically it is assumed that publishing security or similar information at e.g 1.2.0.192.in-addr.arpa.is safe because only the "owner" of 192.0.2.1 controls this. This is sadly incorrect. - Mistakenly thinking that DNS is a UDP only protocol (and / or that TCP is only used for zone transfers). Additional reading: RFC7766 - DNS Transport over TCP - Implementation Requirements - Using DNS TXT records. While the DNS can store TXT records (RFC1464), it is almost definitely a mistake to develop a protocol which uses these. A new DNS RRType is much preferred - it makes it easier to parse, and is less likely to break things. See RFC6895 - Domain Name System (DNS) IANA Considerations, Section 3.1 for more detail. - Incorrect usage of the _underscore naming pattern - see RFC8552 - Scoped Interpretation of DNS Resource Records through "Underscored" Naming of Attribute Leaves for advice on how to use these. === IPv6 === - Due to various hardware limitations, packets with "excessive" IPv6 Extension Headers may be dropped. Various operators also filter packets with extension headers and or fragments - see the (expired) draft "Why Operators Filter Fragments and What It Implies"(https://www.ietf.org/archive/id/draft-taylor-v6ops-fragdrop-02.txt) for more background. === Routing === - Assuming that "customers" connect to Tier-2 ISPs who then connect to Tier-1 ISPs. The routing system is much more messy than this, and "customers" and various size ISPs all peer / purchase transit / etc. - Assuming that sending a packet which needs "high-touch" (the control plane) of a router is a reasonable thing to do. In order to scale, modern routers do almost all work in dedicated network hardware. Anything which requires punting transit traffic to the control plane almost definitely means that the traffic will be dropped / that the protocol will not be deployable. - Assuming that Quality of Service markings will cross administrative boundaries. === Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions === * [https://tools.ietf.org/html/rfc5706] === MIB Guidelines === In forthcoming MIB reviews the MIB Doctors will be applying these [http://www.rfc-editor.org/rfc/rfc4181.txt "Guidelines for Authors and Reviewers of MIB Documents [RFC4181, BCP111]"], (RFC issued September 23rd, 2005). These guidelines have been updated by an IESG approved document: "RFC 4181 Update to Recognize the IETF Trust [RFC4841, BCP111]". For your convenience: [wiki:mib-boilerplate Boilerplate for MIB documents] [[BR]] [wiki:mib-security Guidelines for a MIB security section] [[BR]] [wiki:mib-common-tcs Generic and Common Textual Conventions][[BR]] [wiki:mib-review-tools MIB review tools] [[BR]] There is a text template you can use to start a document containing a MIB module that helps you meet many of the requirements listed in RFC4181 "Guidelines for Authors and Reviewers of MIB Documents" and also is designed to meet the preferences of the MIB Doctors for section ordering and naming to simplify automated checking. See [http://www.rfc-editor.org/rfc/rfc5249.txt RFC 5249 - Templates for Internet-Drafts Containing MIB Modules] The XML source for generating the text template with the [http://xml.resource.org/ xml2rfc] tool is also available. The XML source includes additional comments that can help an author fill in the various sections appropriately using an XML editor. The XML source is contained in An XML Template for Documents Containing a MIB Module. Viewing the XML source in your XML editor may require having an rfc2629.dtd from xml.resource.org. Updated templates (June 2013), by David B. Harrington, can be found [https://tools.ietf.org/ "here"].[[BR]] The MIB Doctors have produced three templates specifically aimed at drafts containing MIB modules:[[BR]] • The first is an [https://tools.ietf.org/tools/templates/mib-doc-template-xml.txt "XML template for editors that use XML2RFC"]. Some advice echoing guidelines from RFC4181 is embedded in comments.[[BR]] • A second template is a [https://tools.ietf.org/tools/templates/mib-doc-template-advice.txt "text template for MIB documents with advice embedded"] in the document.[[BR]] • A third template is [https://tools.ietf.org/tools/templates/mib-doc-template-plain.txt "a plain text template with no advice included"].[[BR]] === YANG Guidelines === In forthcoming YANG reviews the YANG Doctors will be applying the [https://tools.ietf.org/html/rfc6087 Guidelines for Authors and Reviewers of YANG Data Model Documents (RFC 6087)]. For your convenience: [wiki:yang-security-guidelines YANG module security guidelines] (16 June 2010, approved by Security ADs, updated 22 March 2012). List of [http://www.netconfcentral.org/typedeflist YANG typedefs]. == Other Wiki Pages == * [wiki:Directorates Directorates] * [https://datatracker.ietf.org/group/opsdir/about/ OPS Directorate] * [http://trac.tools.ietf.org/wg/dime/trac/wiki/AaaDoctorsv2 AAA-Doctors] * [https://datatracker.ietf.org/group/yangdoctors/about/ YANG Doctors Page] * [https://datatracker.ietf.org/group/mibdoctors/about/ MIB Doctors Page] * [https://www.ietf.org/mail-archive/web/aaa-doctors/current/maillist.html AAA Doctors] * [https://datatracker.ietf.org/group/perfmetrdir/about/ Performance Metrics Directorate] == Advice for WG Chairs == * [wiki:Chairs Advice for WG Chairs] == IETF High Level Working Group Summaries == * [wiki:IETF86summary IETF 86 WG High Level Summaries] * [wiki:IETF87summary IETF 87 WG High Level Summaries] * [wiki:IETF88summary IETF 88 WG High Level Summaries] * [wiki:IETF89summary IETF 89 WG High Level Summaries] * [wiki:IETF90summary IETF 90 WG High Level Summaries] * [wiki:IETF91summary IETF 91 WG High Level Summaries] * [wiki:IETF92summary IETF 92 WG High Level Summaries] * [wiki:IETF93summary IETF 93 WG High Level Summaries] * [wiki:IETF94summary IETF 94 WG High Level Summaries] * [wiki:IETF95summary IETF 95 WG High Level Summaries] * [wiki:IETF96summary IETF 96 WG High Level Summaries] * [wiki:IETF97summary IETF 97 WG High Level Summaries] * [wiki:IETF98summary IETF 98 WG High Level Summaries] * [wiki:IETF99summary IETF 99 WG High Level Summaries] * [wiki:IETF100summary IETF 100 WG High Level Summaries] * [wiki:IETF101summary IETF 101 WG High Level Summaries] * [wiki:IETF102summary IETF 102 WG High Level Summaries] * [wiki:IETF103summary IETF 103 WG High Level Summaries] * [wiki:IETF104summary IETF 104 WG High Level Summaries] * [wiki:IETF105summary IETF 105 WG High Level Summaries] * [wiki:IETF106summary IETF 106 WG High Level Summaries] * [wiki:IETF109summary IETF 109 WG High Level Summaries] * [wiki:IETF110summary IETF 110 WG High Level Summaries] * [wiki:IETF111summary IETF 111 WG High Level Summaries] * [wiki:IETF113summary IETF 113 WG High Level Summaries]