idnits 2.17.1 draft-ietf-diffserv-trafcon-format-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == Mismatching filename: the document gives the document name as 'draft-ietf-diffserv-traffcon-format-00', but the file name used is 'draft-ietf-diffserv-trafcon-format-00' == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 2 longer pages, the longest (page 2) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 55 instances of lines with control characters in the document. ** The abstract seems to contain references ([RFC2119]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 139 has weird spacing: '...tecture for D...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 5) Describe the minimal functionality required for this type of traffic conditioner. For example "A shaper MUST at least allow a specification of peak rate and MUST provide a holding queue of at least 2 times this configured peak rate (in bytes) times 0.1. The output of the shaper MUST not exceed the configured peak rate for any time scale larger than the time to transmit an MTU-sized packet at the output line rate." == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 2475 Summary: 7 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT Kathleen Nichols 2 Internet Engineering Task Force Cisco Systems 3 Differentiated Services Working Group Brian Carpenter 4 Expires August, 1999 IBM 5 February, 1999 7 Format for Diffserv Working Group Traffic Conditioner Drafts 8 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance 13 with all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as 18 Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet- 23 Drafts as reference material or to cite them other than as 24 "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Distribution of this memo is unlimited. 34 Abstract 36 This draft outlines the format and required content for traffic 37 conditioner drafts that are submitted to the Differentiated 38 Services Working Group (Diff-Serv). This format is specified to 39 expedite working group review of traffic conditioner submissions. 41 The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", 42 and "MAY" that appear in this document are to be 43 interpreted as described in [RFC2119]. 45 1. Introduction 47 A key component of the differentiated services architecture 48 [RFC2474,RFC2475] is traffic conditioners. To expedite working group 49 review of all drafts submitted on traffic conditioners, this 50 document outlines the format and required content for such drafts. 52 Each draft should describe only one traffic conditioner. 54 Drafts describing traffic conditioners are to serve two main 55 purposes: first, to describe a particular kind of traffic 56 conditioner in a general way and, second, give guidelines for 57 implementers of the traffic conditioner as to the minimum 58 requirements and how to describe the features of the implementation. 59 Each draft should be concise, but complete. In particular, each 60 document should contain the information listed in the next section. 62 2. General format and content for traffic conditioner drafts 64 Traffic conditioner drafts should have: 66 1) An abstract with the name of the traffic conditioner, a 67 description of its general behavior and why it is useful. 68 For example: "Shapers may delay packets of a behavior aggregate 69 to enforce conformance to a traffic profile." 71 2) A labled block diagram of the traffic conditioner. The text 72 version of the draft must include this. 74 3) Specify the required configuration parameters and 75 monitoring data for the traffic conditioner as well as 76 any additional non-required but externally visible parameters 77 that may be configured. Specify the units or type of units that 78 must be used. For example, a required statement could be: "The 79 shaper's peak output rate MUST be configurable, though an 80 implementation may specify either bytes per second or packets 81 per second." An example of required monitoring data might read 82 "It MUST be possible to monitor the number of packets that have 83 arrived at the shaper and been dropped due to insufficient 84 holding queue and it must also be possible to monitor the 85 actual rate of shaped packets that have left the shaper." 86 An example of additional optional configuration data is: 87 "The size of the shaper's holding queue MAY be specified, 88 in either packets or bytes. When this is not externally 89 specified or for implementations where it is not possible to 90 set this parameter, a default value of 2 times the configured 91 rate in bytes per second times 0.1 should be used." 93 4) Describe the specific behavior of this traffic 94 conditioner. In general, this section will be more verbose 95 than the others. If there is a range of acceptable behavior, 96 describe this as well as the manner in which a particular 97 implementation should be documented. For example: "Shapers 98 MAY be specified as operating on a per packet or a per byte 99 basis. This MUST be made explicit. If shaping is done per 100 packet, it MUST be made clear what packet size is assumed by 101 the module or if this is a configurable parameter." 103 5) Describe the minimal functionality required for this type 104 of traffic conditioner. For example "A shaper MUST at least 105 allow a specification of peak rate and MUST provide a holding 106 queue of at least 2 times this configured peak rate (in bytes) 107 times 0.1. The output of the shaper MUST not exceed the 108 configured peak rate for any time scale larger than the time 109 to transmit an MTU-sized packet at the output line rate." 111 6) Describe the scaling properties of the described conditioner 112 along with any security issues (for example, denial of service). 114 7) Document the assumptions, if any, made about the input 115 traffic. That is, is there an assumed maximum rate or 116 interarrival time for this traffic conditioner or can arrival 117 traffic have arbitrary dynamic characteristics? 119 8) Describe one or more example services that could be offered 120 with the described conditioner. 122 3. Security Considerations 124 There may be security considerations associated with either 125 a proposed traffic conditioner or an example service built 126 with that traffic conditioner. These must be described in the 127 draft. 129 4. References 131 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement 132 Levels", Internet RFC 2119, March 1997. 134 [RFC2474] K. Nichols, S. Blake, F. Baker, and D. Black, "Definition of 135 the Differentiated Services Field (DS Field) in the IPv4 and IPv6 136 Headers", Internet RFC 2474, December 1998. 138 [RFC2475] D. Black, S. Blake, M. Carlson, E. Davies, Z. Wang, and 139 W. Weiss, "An Architecture for Differentiated Services", Internet 140 RFC 2475, December 1998. 142 5. Authors' Addresses 144 Kathleen Nichols 145 Cisco Systems, Inc 146 170 W. Tasman Drive 147 San Jose, CA 95134-1706 148 kmn@cisco.com 150 Brian Carpenter 151 IBM United Kingdom Laboratories 152 MP 185, Hursley Park 153 Winchester, Hampshire S021 2JN, UK