idnits 2.17.1 draft-ietf-radius-bap-01.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-18) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == Mismatching filename: the document gives the document name as 'draft-ietf-radius-ms-ba-attr-01', but the file name used is 'draft-ietf-radius-bap-01' Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** 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 4 instances of too long lines in the document, the longest one being 8 characters in excess of 72. ** The abstract seems to contain references ([2], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 10 has weird spacing: '...This document...' == Line 11 has weird spacing: '...as, and its...' == Line 16 has weird spacing: '...and may be ...' == Line 17 has weird spacing: '...ference mater...' == Line 20 has weird spacing: '...To learn the...' == (30 more instances...) == 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). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 1998) is 9559 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2138 (ref. '4') (Obsoleted by RFC 2865) Summary: 13 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group G. Zorn 2 Internet-Draft Microsoft Corporation 3 Category: Informational February 1998 4 6 RADIUS Attributes for Multilink PPP Banwidth Allocation Control 8 1. Status of this Memo 10 This document is an Internet-Draft. Internet-Drafts are working docu- 11 ments of the Internet Engineering Task Force (IETF), its areas, and its 12 working groups. Note that other groups may also distribute working doc- 13 uments as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six months 16 and may be updated, replaced, or obsoleted by other documents at any 17 time. It is inappropriate to use Internet-Drafts as reference material 18 or to cite them other than as ``work in progress''. 20 To learn the current status of any Internet-Draft, please check the 21 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 22 Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), 23 ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 25 This memo provides information for the Internet community. This memo 26 does not specify an Internet standard of any kind. The distribution of 27 this memo is unlimited. It is filed as and expires August 20, 1998. Please send comments to the 29 RADIUS Working Group mailing list (ietf-radius@livingston.com) or to the 30 author (glennz@microsoft.com). 32 2. Abstract 34 This document describes a set of vendor-specific RADIUS attributes 35 designed to support the dynamic control of bandwidth allocation in mul- 36 tilink PPP [1]. Attributes are defined that specify whether use of the 37 PPP Bandwidth Allocation Protocol [2] is allowed or required on incoming 38 calls, the level of line capacity (expressed as a percentage) below 39 which utilization must fall before a link is eligible to be dropped, and 40 the length of time (in seconds) that a link must be underutilized before 41 it is dropped. 43 3. Specification of Requirements 45 In this document, the key words "MAY", "MUST, "MUST NOT", "optional", 46 "recommended", "SHOULD", and "SHOULD NOT" are to be interpreted as 47 described in [3]. 49 4. Attributes 51 The following sections describe sub-attributes which may be transmitted 52 in one or more RADIUS attributes of type Vendor-Specific [4]. More than 53 one sub-attribute MAY be transmitted in a single Vendor-Specific 54 Attribute; if this is done, the sub-attributes SHOULD be packed as a 55 sequence of Vendor-Type/Vendor-Length/Value triples following the inital 56 Type, Length and Vendor-ID fields. The Length field of the Vendor-Spe- 57 cific Attribute MUST be set equal to the sum of the Vendor-Length fields 58 of the sub-attributes contained in the Vendor-Specific Attribute, plus 59 six. The Vendor-ID field of the Vendor-Specific Attribute(s) MUST be 60 set to decimal 311 (Microsoft). 62 4.1. MS-BAP-Usage 64 Description 66 This Attribute describes whether the use of BAP is allowed, disal- 67 lowed or required on new multilink calls. It MAY be used in 68 Access-Accept packets. 70 A summary of the MS-BAP-Usage Attribute format is shown below. The 71 fields are transmitted from left to right. 73 0 1 2 3 74 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 75 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 76 | Vendor-Type | Vendor-Length | Value 77 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 78 Value (cont) | 79 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 81 Vendor-Type 82 13 for MS-BAP-Usage. 84 Vendor-Length 85 6 87 Value 88 The Value field is four octets. 90 0 BAP usage not allowed 91 1 BAP usage allowed 92 2 BAP usage required 94 4.2. MS-Link-Utilization-Threshold 96 Description 98 This Attribute represents the percentage of available bandwidth 99 utilization below which the link must fall before the link is eli- 100 gible for termination. Permissible values for the MS-Link-Uti- 101 lization-Threshold Attribute are in the range 1-100, inclusive. 102 It is only used in Access-Accept packets. 104 A summary of the MS-Link-Utilization-Threshold Attribute format is 105 shown below. The fields are transmitted from left to right. 107 0 1 2 3 108 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 110 | Vendor-Type | Vendor-Length | Value 111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 112 Value (cont) | 113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 115 Vendor-Type 116 14 for MS-Link-Utilization-Threshold 118 Vendor-Length 119 6 121 Value 122 The Value field is four octets in length and represents the per- 123 centage of available bandwidth utilization below which the link 124 must fall before the link is eligible for termination. Permissi- 125 ble values are in the range 1-100, inclusive. 127 4.3. MS-Link-Drop-Time-Limit 129 Description 131 The MS-Link-Drop-Time-Limit Attribute indicates the length of time 132 (in seconds) that a link must be underutilized before it is 133 dropped. It MAY only be included in Access-Accept packets. 135 A summary of the MS-Link-Drop-Time-Limit Attribute format is given 136 below. The fields are transmitted left to right. 138 0 1 2 3 139 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 | Vendor-Type | Vendor-Length | Value 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 Value (cont) | 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 Vendor-Type 147 15 for MS-Link-Drop-Time-Limit 149 Vendor-Length 150 6 152 Value 153 The Value field represents the number of seconds that a link must 154 be underutilized (i.e., display bandwidth utilization below the 155 threshold specified in the MS-Link-Utilization-Threshold 156 Attribute) before the link is dropped. 158 5. Table of Attributes 160 The following table provides a guide to which of the above attributes 161 may be found in which kinds of packets, and in what quantity. 163 Request Accept Reject Challenge Acct-Request # Attribute 164 0 0-1 0 0 0 13 MS-BAP-Usage 165 0 0-1 0 0 0 14 MS-Link-Utilization-Threshold 166 0 0-1 0 0 0 15 MS-Link-Drop-Time-Limit 168 The following table defines the meaning of the above table entries. 170 0 This attribute MUST NOT be present in packet. 171 0+ Zero or more instances of this attribute MAY be present in packet. 172 0-1 Zero or one instance of this attribute MAY be present in packet. 174 6. Security Considerations 176 None. 178 7. Acknowledgements 180 Thanks to Narendra Gidwani (nareng@microsoft.com) and Aydin Edguer 181 (edguer@MorningStar.com) for useful comments. 183 8. Expiration Date 185 This document expires August 20, 1998. 187 9. Chair's Address 189 The RADIUS Working Group can be contacted via the current chair: 191 Carl Rigney 192 Livingston Enterprises 193 4464 Willow Road 194 Pleasanton, California 94588 196 Phone: +1 510 426 0770 197 E-Mail: cdr@livingston.com 199 10. Author's Address 201 Questions about this memo can also be directed to: 203 Glen Zorn 204 Microsoft Corporation 205 One Microsoft Way 206 Redmond, Washington 98052 208 Phone: +1 425 703 1559 209 FAX: +1 425 936 7329 210 EMail: glennz@microsoft.com 212 11. References 214 [1] Sklower, K., et. al., "The PPP Multilink Protocol (MP)", RFC 1990, 215 August 1996 217 [2] Richards, C. and Smith, K., "The PPP Bandwidth Allocation Protocol 218 (BAP) The PPP Bandwidth Allocation Control Protocol (BACP)" RFC 219 2125, March 1997 221 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 222 Levels", RFC 2119, March 1997 224 [4] Rigney, C., et. al., "Remote Access Dial In User Service", RFC 225 2138, April 1997