idnits 2.17.1 draft-ietf-radius-ms-ba-attr-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-23) 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. 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 11 has weird spacing: '...This document...' == Line 12 has weird spacing: '...as, and its...' == Line 17 has weird spacing: '...and may be ...' == Line 18 has weird spacing: '...ference mater...' == Line 21 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 9564 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 (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Zorn 3 Internet-Draft Microsoft Corporation 4 Category: Informational February 1998 5 7 RADIUS Attributes for Multilink PPP Bandwidth Allocation Control 9 1. Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working docu- 12 ments of the Internet Engineering Task Force (IETF), its areas, and its 13 working groups. Note that other groups may also distribute working doc- 14 uments as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference material 19 or to cite them other than as ``work in progress''. 21 To learn the current status of any Internet-Draft, please check the 22 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 23 Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), 24 ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 26 This memo provides information for the Internet community. This memo 27 does not specify an Internet standard of any kind. The distribution of 28 this memo is unlimited. It is filed as and expires August 28, 1998. Please send comments to the 30 RADIUS Working Group mailing list (ietf-radius@livingston.com) or to the 31 author (glennz@microsoft.com). 33 2. Abstract 35 This document describes a set of vendor-specific RADIUS attributes 36 designed to support the dynamic control of bandwidth allocation in mul- 37 tilink PPP [1]. Attributes are defined that specify whether use of the 38 PPP Bandwidth Allocation Protocol [2] is allowed or required on incoming 39 calls, the level of line capacity (expressed as a percentage) below 40 which utilization must fall before a link is eligible to be dropped, and 41 the length of time (in seconds) that a link must be underutilized before 42 it is dropped. 44 3. Specification of Requirements 46 In this document, the key words "MAY", "MUST, "MUST NOT", "optional", 47 "recommended", "SHOULD", and "SHOULD NOT" are to be interpreted as 48 described in [3]. 50 4. Attributes 52 The following sections describe sub-attributes which may be transmitted 53 in one or more RADIUS attributes of type Vendor-Specific [4]. More than 54 one sub-attribute MAY be transmitted in a single Vendor-Specific 55 Attribute; if this is done, the sub-attributes SHOULD be packed as a 56 sequence of Vendor-Type/Vendor-Length/Value triples following the inital 57 Type, Length and Vendor-ID fields. The Length field of the Vendor-Spe- 58 cific Attribute MUST be set equal to the sum of the Vendor-Length fields 59 of the sub-attributes contained in the Vendor-Specific Attribute, plus 60 six. The Vendor-ID field of the Vendor-Specific Attribute(s) MUST be 61 set to decimal 311 (Microsoft). 63 4.1. MS-BAP-Usage 65 Description 67 This Attribute describes whether the use of BAP is allowed, disal- 68 lowed or required on new multilink calls. It MAY be used in 69 Access-Accept packets. 71 A summary of the MS-BAP-Usage Attribute format is shown below. The 72 fields are transmitted from left to right. 74 0 1 2 3 75 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 76 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 77 | Vendor-Type | Vendor-Length | Value 78 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 79 Value (cont) | 80 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 82 Vendor-Type 83 13 for MS-BAP-Usage. 85 Vendor-Length 86 6 88 Value 89 The Value field is four octets. 91 0 BAP usage not allowed 92 1 BAP usage allowed 93 2 BAP usage required 95 4.2. MS-Link-Utilization-Threshold 97 Description 99 This Attribute represents the percentage of available bandwidth 100 utilization below which the link must fall before the link is eli- 101 gible for termination. Permissible values for the MS-Link-Uti- 102 lization-Threshold Attribute are in the range 1-100, inclusive. 103 It is only used in Access-Accept packets. 105 A summary of the MS-Link-Utilization-Threshold Attribute format is 106 shown below. The fields are transmitted from left to right. 108 0 1 2 3 109 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 110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 111 | Vendor-Type | Vendor-Length | Value 112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 113 Value (cont) | 114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 116 Vendor-Type 117 14 for MS-Link-Utilization-Threshold 119 Vendor-Length 120 6 122 Value 123 The Value field is four octets in length and represents the per- 124 centage of available bandwidth utilization below which the link 125 must fall before the link is eligible for termination. Permissi- 126 ble values are in the range 1-100, inclusive. 128 4.3. MS-Link-Drop-Time-Limit 130 Description 132 The MS-Link-Drop-Time-Limit Attribute indicates the length of time 133 (in seconds) that a link must be underutilized before it is 134 dropped. It MAY only be included in Access-Accept packets. 136 A summary of the MS-Link-Drop-Time-Limit Attribute format is given 137 below. The fields are transmitted left to right. 139 0 1 2 3 140 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 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 | Vendor-Type | Vendor-Length | Value 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 Value (cont) | 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 Vendor-Type 148 15 for MS-Link-Drop-Time-Limit 150 Vendor-Length 151 6 153 Value 154 The Value field represents the number of seconds that a link must 155 be underutilized (i.e., display bandwidth utilization below the 156 threshold specified in the MS-Link-Utilization-Threshold 157 Attribute) before the link is dropped. 159 5. Table of Attributes 161 The following table provides a guide to which of the above attributes 162 may be found in which kinds of packets, and in what quantity. 164 Request Accept Reject Challenge Acct-Request # Attribute 165 0 0-1 0 0 0 13 MS-BAP-Usage 166 0 0-1 0 0 0 14 MS-Link-Utilization-Threshold 167 0 0-1 0 0 0 15 MS-Link-Drop-Time-Limit 169 The following table defines the meaning of the above table entries. 171 0 This attribute MUST NOT be present in packet. 172 0+ Zero or more instances of this attribute MAY be present in packet. 173 0-1 Zero or one instance of this attribute MAY be present in packet. 175 6. Security Considerations 177 None. 179 7. Acknowledgements 181 Thanks to Narendra Gidwani (nareng@microsoft.com) and Aydin Edguer 182 (edguer@MorningStar.com) for useful comments. 184 8. Expiration Date 186 This document expires August 28, 1998. 188 9. Chair's Address 190 The RADIUS Working Group can be contacted via the current chair: 192 Carl Rigney 193 Livingston Enterprises 194 4464 Willow Road 195 Pleasanton, California 94588 197 Phone: +1 510 426 0770 198 E-Mail: cdr@livingston.com 200 10. Author's Address 202 Questions about this memo can also be directed to: 204 Glen Zorn 205 Microsoft Corporation 206 One Microsoft Way 207 Redmond, Washington 98052 209 Phone: +1 425 703 1559 210 FAX: +1 425 936 7329 211 EMail: glennz@microsoft.com 213 11. References 215 [1] Sklower, K., et. al., "The PPP Multilink Protocol (MP)", RFC 1990, 216 August 1996 218 [2] Richards, C. and Smith, K., "The PPP Bandwidth Allocation Protocol 219 (BAP) The PPP Bandwidth Allocation Control Protocol (BACP)" RFC 220 2125, March 1997 222 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 223 Levels", RFC 2119, March 1997 225 [4] Rigney, C., et. al., "Remote Access Dial In User Service", RFC 226 2138, April 1997