idnits 2.17.1 draft-bradner-1240.his-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): ---------------------------------------------------------------------------- ** 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. ** 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. ** Bad filename characters: the document name given in the document, 'draft-bradner-1240.his-01', contains other characters than digits, lowercase letters and dash. == No 'Intended status' indicated for this document; assuming Proposed Standard 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == 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. -- The document date (January 1999) is 9232 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 11 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Scott Bradner 3 Internet-Draft Harvard University 4 January 1999 6 OSI connectionless transport services on top 7 of UDP Applicability Statement for Historic Status 9 11 1. Status of this Memo 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 view the entire list of current Internet-Drafts, please check the 24 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 25 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 26 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 27 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 29 This document will expire before June, 1999. Distribution of this 30 draft is unlimited. 32 2. Abstract 33 RFC 1240, "OSI connectionless transport services on top of UDP", was 34 published as a Proposed Standard in June 1991 but at this time there 35 do not seem to be any implementations which follow RFC 1240. In 36 addition there is a growing concern over using UDP-based transport 37 protocols in environments where congestion is a possibility. 39 3. Copyright Notice 40 Copyright (C) The Internet Society (1999). All Rights Reserved. 42 4. Use of RFC 1240 Technology 43 A message was sent to the IETF list in October 1998 seeking any 44 information on the actual use of the technology described in RFC 45 1240. A number of responses were received, including from the 46 International Organization for Standardization (ISO), the keeper of 47 the OSI protocols. None of these messages pointed to any current use 48 for this technology. Most of the messages which made any 49 recommendation did recommend that RFC 1240 be moved to historic. 51 5. Responsiveness to Congestion 52 Since 1991 there has been a great deal of experience with the 53 complexities of dealing with congestion in the Internet. Congestion 54 control algorithms have been improved but there is still work 55 underway to further understand the issues. In this environment any 56 UDP-based protocol is somewhat worrisome since quite frequently 57 people who use UDP-based protocols invent their own reliability and 58 congestion control functions which may not include the results of the 59 current state of the art. This leads to a danger of congestion 60 collapse with potentially quite serious consequences for the network 61 in which it is run. See RFC 896 for a discussion of congestion 62 collapse. 64 In the case of RFC 1240, the authors seemed to assume that if some 65 level of reliability was needed in an RFC 1240 environment that the 66 reliability algorithms and the congestion control algorithms which 67 would then be required would reside in the OSI protocols running over 68 the UDP transport. It is far from clear that any perceived 69 advantages of running over UDP would not be eclipsed by the 70 difficulties experienced in trying to create a reasonable congestion 71 control algorithm. Implementers would likely find that running over 72 TCP as RFC 2126 describes is the better choice. 74 6. Conclusion 75 Due to the lack of use of the technology described in RFC 1240 and 76 the issues surrounding congestion control in the Internet, RFC 1240 77 should be reclassified as Historic and its implementation actively 78 discouraged. 80 7. Security Considerations 81 This type of non-protocol document does not directly effect the 82 security of the Internet. 84 8. References 85 RFC 896: J. Nagle, "Congestion control in IP/TCP internetworks", 86 January 1984 87 RFC 1240: C. Shue, W. Haggerty, and K. Dobbins. - "OSI connectionless 88 transport services on top of UDP: Version 1.", June 1991 89 RFC 2126: Y. Pouffary, A. Young, "ISO Transport Service on top of TCP 90 (ITOT)", March 1997 92 9. Author's Address 93 Scott Bradner 94 Harvard University 95 1350 Mass Ave, rm 876 96 Cambridge, MA 97 02138 98 USA 100 phone: +1 617 495 3864 101 sob@harvard.edu 103 Full Copyright Statement 105 Copyright (C) The Internet Society (1999). All Rights Reserved. 107 This document and translations of it may be copied and furnished to 108 others, and derivative works that comment on or otherwise explain it 109 or assist in its implementation may be prepared, copied, published 110 and distributed, in whole or in part, without restriction of any 111 kind, provided that the above copyright notice and this paragraph are 112 included on all such copies and derivative works. However, this 113 document itself may not be modified in any way, such as by removing 114 the copyright notice or references to the Internet Society or other 115 Internet organizations, except as needed for the purpose of 116 developing Internet standards in which case the procedures for 117 copyrights defined in the Internet Standards process must be 118 followed, or as required to translate it into languages other than 119 English. 121 The limited permissions granted above are perpetual and will not be 122 revoked by the Internet Society or its successors or assigns. 124 This document and the information contained herein is provided on an 125 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 126 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 127 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 128 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 129 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.