idnits 2.17.1 draft-calhoun-radius-ext-00.txt: 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-25) 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 a Security Considerations 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 an Authors' Addresses Section. ** There are 4 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (June 1996) is 10176 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 10 errors (**), 0 flaws (~~), 0 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Pat R. Calhoun 2 Category: Experimental US Robotics Access Corp. 3 expires in six months June 1996 5 Enhanced Remote Authentication Dial In User Service (RADIUS) 6 Protocol Extension Specifications 7 9 Status of this Memo 11 Distribution of this memo is unlimited. 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as ``work in progress.'' 23 To learn the current status of any Internet-Draft, please check the 24 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 25 Directories on ds.internic.net (US East Coast), nic.nordu.net 26 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 27 Rim). 29 Abstract 31 Enhanced RADIUS is an extension to the existing RADIUS 32 commands/attributes. This document defines the required documentation 33 for extensions to the protocol. 35 Introduction 37 The intent of providing for Commands within the Enhanced RADIUS 38 Protocol is to permit the RADIUS Protocol to be enhanced in 39 functionality. It should be possible for devices to invent, test, or 40 discard commands at will. Nevertheless, it is envisioned that 41 commands which prove generally useful will eventually be supported by 42 many implementations of RADIUS Servers and Network Access Devices; 43 therefore it is desirable that commands be documented and publicized. 44 In addition, it is necessary to insure that a single command code 45 does not have multiple definitions. 47 This document specifies a method of Enhanced RADIUS Command Code 48 assignement and standards for documentation of new commands. The 49 invidual responsible for assignement of the Command code may waive 50 the requirement for complete documentation for some cases of 51 experimentation, but in general documentation will be required prior 52 to code assignment. Commands will be publicized by publishing their 53 documentation as RFCs; inventors of the commands may, of course, 54 publicize them in other ways as well. 56 Command codes will be assigned by: 58 Pat R. Calhoun 59 US Robotics Access Corp. 60 8100 N. McCormick Blvd. 61 Skokie, Il, 60076 63 pcalhoun@usr.com 64 (847) 933-5181 66 Since it will obviously occur that new commands are not supported by 67 existing devices, it is recommended that a device respond with a 68 Command-Unrecognized packet if it receives an unsupported RADIUS 69 Command Type. However, for backward compatibility, it is necessary 70 for an implementation to support the fact that the recipient of the 71 packet may silently discard the frame. 73 Documentation of Commands should contain at least the following sections: 75 Section 1 - Command Name and Command Code 77 Section 2 - Command Meanings 79 The meaning of each possible Enhanced RADIUS command relevant to 80 this command should be described. Note that for complex commands, 81 where use of the flag field is required, such flags must be 82 described in detail. 84 Section 3 - Attribute Name and Attribute Code 86 Section 4 - Attribute Meanings 88 The meaning of each possible Enhanced RADIUS command relevant to 89 this command should be described. Note that for complex commands, 90 where use of the flag field is required, such flags must be 91 described in detail. 93 Section 5 - Motivation 95 A detailed explanation of the motivation for inventing a 96 particular command, or for choosing a particular form for the 97 command, is extremely helpful to those who are not faced (or don't 98 realize that they are faced) by the problem that the command is 99 designed to solve. 101 Section 6 - Description (or Implementation Rules) 103 Merely defining the command meanings and providing a statement of 104 motivation are not always sufficient to insure that two 105 implementations of an option will be able to communicate. 106 Therefore, a more complete description should be furnished in most 107 cases. This description might take the form of text, a sample 108 implementation, hints to implementers, etc.